forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Выпуск GNU Wget 1.21, opennews (?), 01-Янв-21, (0) [смотреть все]

С НГ , Любитель патчей (?), 10:46 , 01-Янв-21, (1) +1 //

Серёга, не гони , A.Stahl (ok), 11:01 , 01-Янв-21, (2) //

Алкоголизм делает человека заторможенным , Аноним (-), 19:04 , 01-Янв-21, (35) –1 //

В смысле , Аноним (86), 11:03 , 06-Янв-21, (86)

Но лингвисты Опеннета почему-то до сих пор не выдвинули предположения о расшифро, rvs2016 (ok), 19:14 , 01-Янв-21, (38) –4

как сказал покойный Задорнов, эссен, по-немецки- кушать , cubit (?), 11:30 , 01-Янв-21, (5) –5 //

Евреи эту хохму про СНГ на идиш рассказывали задолго до Задорнова , еврей (?), 03:09 , 02-Янв-21, (60) +1

Скрыто модератором, Ноунейм (?), 11:30 , 01-Янв-21, (4) –1 //

Скрыто модератором, смузихлёб (?), 13:45 , 01-Янв-21, (7) //

Скрыто модератором, Дочь Офицера (?), 14:43 , 01-Янв-21, (13) //

Скрыто модератором, НяшМяш (ok), 23:36 , 01-Янв-21, (56) –1

Скрыто модератором, Led (ok), 01:04 , 02-Янв-21, (57) +12

Скрыто модератором, НяшМяш (ok), 18:51 , 02-Янв-21, (67) –4

Скрыто модератором, Аноним (63), 09:45 , 02-Янв-21, (63)

Скрыто модератором, rioko (?), 22:49 , 01-Янв-21, (53) –1

Скрыто модератором, Дегенератор (ok), 14:12 , 01-Янв-21, (10) –1 //

Скрыто модератором, Аноним (15), 15:51 , 01-Янв-21, (15) +1

Contributions byVyacheslavВячеслав ПетрищевMaintainer DarShit ShahLMAO b , Аноним (6), 12:38 , 01-Янв-21, (6) –4 //

WTF so funny you see , Аноним (9), 14:03 , 01-Янв-21, (9) +2

В новой версии скрипт configure перестал сам добавлять в CFLAGS опцию -std gnu99, Тот самый (?), 14:02 , 01-Янв-21, (8) +1 //

Тебе сюда https savannah gnu org bugs func additem group wget, Аноним (11), 14:29 , 01-Янв-21, (11) +1
Спокойно ждём 1 21 2, Аноним (25), 18:42 , 01-Янв-21, (25)

Вот реальная причина большинства ошибок А не то, что там говорят хрустанутые , uis (ok), 14:41 , 01-Янв-21, (12) +1 //

Я так понимаю, это библиотечная функция для выделения памяти Тогда не понял, чт, Аноним (-), 18:52 , 01-Янв-21, (27) –2 //

Видимо, где-то использовались буферы фиксированного размера, в которые принимали, sage (??), 19:02 , 01-Янв-21, (32) +1 //

В предыдущей сборке пакета был, например, такой патчик CODE --- wget-1 10 1 src, Michael Shigorin (ok), 19:52 , 01-Янв-21, (39)

Вот понимал же человек, который это писал, что может быть very long Ну как так , Аноним (64), 11:24 , 02-Янв-21, (64)
Выделение на стеке без ограничения длинны Хорошо-то как , uis (ok), 04:04 , 07-Янв-21, (87)

Да, библиотечная Но она выделяет на стеке А стек -- хрупкая штука Во многих п, Ordu (ok), 21:18 , 01-Янв-21, (49) +1 //

Причём бы здесь Unix way Да и вообще, причём здесь alloca В C99 можно с точно т, Аноним (11), 21:33 , 01-Янв-21, (51) –1

Новость не читай, сразу комментируй Проведена чистка кода от использования функ, Ordu (ok), 21:55 , 01-Янв-21, (52)

Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь 8230 Поп, Аноним (11), 16:16 , 02-Янв-21, (65)

Потому что это вообще очень по юниксовому -- верить в то, что всё пойдёт хорошо,, Ordu (ok), 16:33 , 02-Янв-21, (66)

Мдя Пяток примеров, специфичных именно для юниксов, тебе ведь не составит труда, Аноним (11), 19:38 , 02-Янв-21, (68)

alloca не канает Из мана к ней Если не канает, попробуй собрать пайпами цепочку, Ordu (ok), 19:52 , 02-Янв-21, (71)

Говорят, у золотых рыбок долговременная память всё ж таки работает А вот у тебя, Аноним (11), 23:39 , 02-Янв-21, (73) +1

Ты читать умеешь Изобретена alloca в unix vla изобрели резко позже по мотивам , Ordu (ok), 23:56 , 02-Янв-21, (74)

Умею, а что, есть сомнения Раз притащили в стандарт, значит не посчитали вредны, Аноним (11), 02:41 , 03-Янв-21, (76)
Наличие чего-либо в стандарте на C -- это не показатель безвредности Там гумна , Ordu (ok), 03:29 , 03-Янв-21, (77)
Это показатель неспецифичности для Unix третий раз повторяю, больше не буду А , Аноним (11), 13:56 , 03-Янв-21, (78)
Попробуй пописать на чём-нибудь кроме bash Я б рекоменовал функциональщину, тог, Ordu (ok), 19:01 , 03-Янв-21, (80)
Здрасьте, а чем Вам конвейер не функциональщина и, кстати, любимая грабелька с, Michael Shigorin (ok), 19:05 , 03-Янв-21, (81) –1
Функциональщина, да Но она ему не помогает понимать глобальное ридонли состояни, Ordu (ok), 19:17 , 03-Янв-21, (83)
Это последний мой ответ тебе, поскольку ты всё равно не утруждаешь себя их чтени, Аноним (11), 21:11 , 03-Янв-21, (84)
Чё серьёзно Продолжай и дальше заниматься этим буквоедством, я уверен люди к теб, Ordu (ok), 22:52 , 03-Янв-21, (85)

Нормальное ты себе определение придумал Только зачем эту дичь другим впаривать , Хулиган (?), 00:01 , 03-Янв-21, (75) +2

Ну вообще-то это не он придумал ---I remarked to Dennis that easily half the cod, Michael Shigorin (ok), 19:08 , 03-Янв-21, (82)

Явное выделение на стеке UB Временная переменная функции UB Сохранение регистр, uis (ok), 04:09 , 07-Янв-21, (88)

В целом да C он вообще такой Разные другие языки выделяют память под стек дина, Ordu (ok), 05:36 , 07-Янв-21, (91)

man mmapСм MAP_STACK Достаточно динамическиImplementation-specific В данном с, uis (ok), 20:58 , 12-Янв-21, (92)

Вот где годнота - https github com otavio rsget, Аноним (14), 15:30 , 01-Янв-21, (14) –4 //

Hey, buddy, I think you ve got the wrong door The Rust club is two blocks down , Chromium (ok), 16:02 , 01-Янв-21, (17) +4
Сам юзай этот хелловорлд , Аноним (11), 17:26 , 01-Янв-21, (20) –1
Годнота может быть написано только на Го https github com melbahja got, Аноним (22), 17:43 , 01-Янв-21, (22) //

Скрыто модератором, Аноним (25), 18:47 , 01-Янв-21, (26) +1 //

Скрыто модератором, Аноним (-), 19:02 , 01-Янв-21, (31)
Скрыто модератором, Аноним (34), 19:03 , 01-Янв-21, (34)

Скрыто модератором, Аноним (-), 19:08 , 01-Янв-21, (36) –2

Скрыто модератором, банан (?), 20:24 , 01-Янв-21, (43) –3

Вы что, совсем А как же безопасность , Аноним (-), 20:29 , 01-Янв-21, (44) –1 //

В Го безопасности сильно больше чем в Храсте Да даже побольше чем в node js , Аноним (46), 20:37 , 01-Янв-21, (46) –2

Кто-то успел уже пожаловаться автору программы и он изменил название свое програ, Аноним (-), 07:18 , 02-Янв-21, (62) +1
got Global Offset Table , uis (ok), 21:00 , 12-Янв-21, (93)

Растофаны никак не уймутся , Аноним (-), 18:55 , 01-Янв-21, (28)

Извините, но --diable-nls всегда и везде, никому это ненужно , Аноним (16), 15:53 , 01-Янв-21, (16) –4 //

Вот кстати да, приятно видеть адеквата в интернете Ну это до тех пор пока твоё , Аноним (18), 16:25 , 01-Янв-21, (18) –3 //

Первый раз вообще слышу что такое бывает, разве что предположу что такое ПО скор, Аноним (58), 01:40 , 02-Янв-21, (58)

wget2 еще не довели до ума , EPIC (?), 17:22 , 01-Янв-21, (19) //

Хз Есть ещё aria2, uis (ok), 04:17 , 07-Янв-21, (89)

Гораздо лучше чем curl от Васяна , Аноним (22), 17:39 , 01-Янв-21, (21) –5 //

Я, конечно, догадываюсь, что это был сарказм, но программы просто решают несколь, Аноним (18), 18:01 , 01-Янв-21, (23) //

Я догадываюсь, почему на неё забили, с такими то пользователями https github c, Аноним (18), 18:23 , 01-Янв-21, (24)
wget скачивалка сайтов Вот это поворот , Аноним (34), 19:03 , 01-Янв-21, (33) //

Я тоже удивился, когда узнал это на самом деле нет При этом, оно плохо справл, Аноним (18), 19:09 , 01-Янв-21, (37)

8230 httrack 8230 , чувак, ты из какой-то параллельной реальности wget у тебя, Аноним (46), 20:40 , 01-Янв-21, (47) –4

Прикинь, да CODE apropos wgetwget 1 - The non-interactive netwo, Аноним (11), 20:19 , 01-Янв-21, (41)

wget это просто curl здорового человека не надо тут грязи , Аноним (46), 20:43 , 01-Янв-21, (48) –1

Это wget 2 пытается им стать Как выйдет 8212 поглядим, насколько успешно , Аноним (11), 21:20 , 01-Янв-21, (50) –1
открой уже ман по вгету что ли ты и так уже тонну ереси написал, а все продолжа, Алеша (?), 22:59 , 01-Янв-21, (54) +1

Ну это-то, положим, и wget умеет, если оно POST-запросом делается Другое дело, , Аноним (11), 02:00 , 02-Янв-21, (59)

wget --mirror, uis (ok), 04:19 , 07-Янв-21, (90)

И что они даже поддержку FTP не удалили Как они это сумели Откуда финансирован, Аноним (42), 20:21 , 01-Янв-21, (42) +2 //

Free Software Foundation дало денег , Аноним (46), 20:34 , 01-Янв-21, (45)
lftp лучше , EPIC (?), 23:20 , 01-Янв-21, (55)

Как изменить имя ,передаваемое при соединении , Nika (??), 03:35 , 02-Янв-21, (61) //

-O, Michael Shigorin (ok), 19:51 , 02-Янв-21, (70) +1

Хм https packages debian org sid wget2 GNU Wget2 is the successor of GNU W, Аноним (72), 21:05 , 02-Янв-21, (72) //

Currently GNU Wget2 is being developed , Аноним (11), 14:23 , 03-Янв-21, (79)

Сообщения [Сортировка по времени | RSS]

49. "Выпуск GNU Wget 1.21" +1 +/–

Сообщение от Ordu (ok), 01-Янв-21, 21:18

> Я так понимаю, это библиотечная функция для выделения памяти.
Да, библиотечная. Но она выделяет на стеке. А стек -- хрупкая штука. Во многих проектах alloca вообще под запретом, и за её использование руки отрывают.
>        void *alloca(size_t size);
> DESCRIPTION
>       The  alloca()  function  allocates  size  bytes of space in the stack
>       frame of the caller.  This temporary  space  is  automatically  freed
>       when the function that called alloca() returns to its caller.
> RETURN VALUE
>       The alloca() function returns a pointer to the beginning of the allo‐
>       cated space.  If the allocation causes stack overflow, program behav‐
>       ior is undefined.
Чуешь? Тут документированный UB, и (что очень в стиле unix-way) этот UB невозможно гарантированно обойти. Вызывая alloca, ты никогда не знаешь, будет ли переполнение стека или нет. И узнать не можешь. Но alloca -- это очень быстрый способ выделить/освободить память, гораздо быстрее чем malloc. Поэтому возникает соблазн забить на потенциальные проблемы, и использовать alloca вместо malloc. И есть те, кто перед таким соблазном устоять не может.
Если выделять немного, то в принципе ничего плохого не должно случиться. Но что значит "немного"? И это ж надо проверить, так уж ли немного мы собираемся выделить? А если мы проверили, и оказалось много, то что делать?
То есть, "немного" ведь означает не больше N, где N -- известное на этапе компиляции целое число. А если мы можем написать:
char *buf = NULL;
if(size <= 256) {
    buf = alloca(size);
} else {
    die("Invalid size"); // в смысле die -- это no-return функция
}
то мы с тем же успехом можем написать и:
if(size > 256) {
    die("Invalid size");
}
char buf[256];
Тут выходит, что выделяется 256-size лишних байт, но... и чё с того? Это может иметь значение при рекурсивном вызове, но использовать alloca в рекурсивной функции может только полнейший отморозок.
То есть alloca оказывается не нужен в такой ситуации. А если size может исчисляться мегабайтами, и мы считаем что наша программа должна работать с такими size, то придётся пользовать malloc, потому как условно использовать alloca или malloc в зависимости от размера -- это то же самое, что открывать нараспашку все двери, вешая над ними транспаранты "MEMORY BUGS ARE WELCOME!". Причём, в такой ситуации, скорее всего и выигрыша по скорости не будет никакого существенного: если программа норм работает с мегабайтовыми буферами, выделенными при помощи malloc, она тем более будет норм работать с докилобайтовыми буферами, выделенными при помощи malloc.
Может можно придумать какой-нибудь use-case для alloca, когда это не будет хождениями по граблям переполнения стека AND даст прирост в скорости, но, во-первых, мне не удаётся придумать, во-вторых, это будет очень специальным случаем, и это будет раскладыванием граблей для будущих разработчиков.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

51. "Выпуск GNU Wget 1.21" –1 +/–

Сообщение от Аноним (11), 01-Янв-21, 21:33

> и (что очень в стиле unix-way) этот UB невозможно гарантированно обойти
Причём бы здесь Unix way?
Да и вообще, причём здесь alloca? В C99 можно с точно таким же результатом использовать VLA.

Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 01-Янв-21, 21:55

> Да и вообще, причём здесь alloca?
Новость не читай, сразу комментируй?
"Проведена чистка кода от использования функции alloca. В некоторых местах в функции указывался размер непроверенных внешних строк, передаваемых через командную строки или получаемых с внешнего хоста."
> В C99 можно с точно таким же результатом использовать VLA.
Можно. С тем же результатом, включая сюда и UB.

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск GNU Wget 1.21" +/–

Сообщение от Аноним (11), 02-Янв-21, 16:16

Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем ещё разик: Причём здесь unix way, да и вообще unix? Аргумент, что alloca есть только в этих ваших юниксах, не канает, потому что VLA есть в стандарте языка.

Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 02-Янв-21, 16:33

> Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем
> ещё разик: Причём здесь unix way, да и вообще unix?
Потому что это вообще очень по юниксовому -- верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать.

Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск GNU Wget 1.21" +/–

Сообщение от Аноним (11), 02-Янв-21, 19:38

Мдя? Пяток примеров, специфичных именно для юниксов, тебе ведь не составит труда накидать?

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 02-Янв-21, 19:52

> Мдя? Пяток примеров, специфичных именно для юниксов, тебе ведь не составит труда
> накидать?
alloca не канает? Из мана к ней:
> CONFORMING TO
>       This function is not in POSIX.1.
>       There is evidence that the alloca() function appeared  in  32V,  PWB,
>       PWB.2,  3BSD, and 4BSD.  There is a man page for it in 4.3BSD.  Linux
>       uses the GNU version.
Если не канает, попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка.
Или взять пути в файловой системе, которые позволяют любые символы, даже несмотря на то, что из тысяч софта, может быть единицы могут справится с любыми символами, при том что в подавляющем большинстве случаев нет никакого смысла совать в имя файла ^C или ^M. Смысла нет, но кого колышет? Надо обязательно разложить граблей, без граблей это будет не юникс.
Локали обсуждали недавно, с их черезжопностью.
Пятый пример... Мне не сообразить сходу. Я подумаю, позже отпишу.

Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск GNU Wget 1.21" +1 +/–

Сообщение от Аноним (11), 02-Янв-21, 23:39

> alloca не канает?
Говорят, у золотых рыбок долговременная память всё ж таки работает. А вот у тебя — не особо. Перечитай тред, что ли. Те же грабли есть в стандарте языка, только называются VLA, а посему — нет, не канает. Неспецифично.
> попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка.
На сишечке — запросто (ну ладно, не очень запросто, несколько десятков строк кода понадобится написать). В шелле сложнее, да. Но покажи, где подобное реализовано лучше. Да и нужно такое бывает крайне редко.
> Или взять пути в файловой системе, которые позволяют любые символы
Ну с натяжкой это можно назвать граблями, хотя, скорее, из-за засилья рукожопов, привыкших к ограничениям вынь-доса, чем по объективным причинам. Однако напомню твой тезис:
> верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать.
Где тут может вылезти ошибка, которую *невозможно обработать*? Я что-то такого не вижу.
> Локали обсуждали недавно, с их черезжопностью.
Если ты обсуждал их с голосами в своей голове, это не значит, что все анонимы тоже это слышали. Давай, рассказывай, где там возникают *ошибки, которые невозможно обработать*.

Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 02-Янв-21, 23:56

>> alloca не канает?
> Говорят, у золотых рыбок долговременная память всё ж таки работает. А вот
> у тебя — не особо. Перечитай тред, что ли. Те же
> грабли есть в стандарте языка, только называются VLA, а посему —
> нет, не канает. Неспецифично.
Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca.
>> попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка.
> На сишечке — запросто (ну ладно, не очень запросто, несколько десятков строк
> кода понадобится написать). В шелле сложнее, да. Но покажи, где подобное
> реализовано лучше.
Где-где, в rust'е вестимо. Когда я пишу file.lines().map(...).filter(...).fold(...).бла-бла-бла, я всегда могу отследить источник ошибки.
> Да и нужно такое бывает крайне редко.
Да, "зелен виноград". Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках.
>> Или взять пути в файловой системе, которые позволяют любые символы
> Ну с натяжкой это можно назвать граблями, хотя, скорее, из-за засилья рукожопов,
Хаха. Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов. Может после этого у тебя пропадёт желание говорить о жопах с руками.

>> верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать.
> Где тут может вылезти ошибка, которую *невозможно обработать*? Я что-то такого не
> вижу.
Попробуй из шелла поработать с путями. Где-то на просторах интернета был чувак, который исследовал способы работать с путями из шелла, и его вердикт был -- unix suxx.
>> Локали обсуждали недавно, с их черезжопностью.
> Если ты обсуждал их с голосами в своей голове, это не значит,
> что все анонимы тоже это слышали. Давай, рассказывай, где там возникают
> *ошибки, которые невозможно обработать*.
https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки. Знаешь, когда я 20 лет назад, ковыряясь в коде какого-то рогалика, напоролся на замечательный код, который модифицировал глобальную переменную хранящую уровень, с тем чтобы при использовании вещи, чьё действие зависит от уровня, эта вещь сработала согласно тому, на каком уровне она была подобрана, а не тому, на котором уровне она была использована, я подумал, что это бредовый способ справляться с проблемами. Я подумал, что единственная причина простить чувака, который написал этот бред -- это то, что тот чувак такой же безрукий студент, как и я.
Но когда общесистемная хрень -- локали -- проектируются таким же образом, причём без единой задней мысли предоставить клиентскому коду, допустим, стек локалей, куда можно сделать push(locale) а потом pop(). То есть вообще просто взяли, присобачили глобал-стейт к каждому процессу, и хрен с ними со всеми потенциальными проблемами -- это либо полнейшая отмороженность, либо просто отсутствие мозга.

Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск GNU Wget 1.21" +/–

Сообщение от Аноним (11), 03-Янв-21, 02:41

> Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca.
Умею, а что, есть сомнения? Раз притащили в стандарт, значит не посчитали вредным. Могли и не тащить.
> Где-где, в rust'е вестимо.
А rust разве в юниксах не работает?
> Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках.
Я не пишу bash-портянки. Я пишу скрипты на POSIX shell. И в них почему-то очень редко встречаются конвейеры более чем из двух-трёх команд, причём источником ошибки, как правило, может быть только одна из них. Смею предположить, это не потому что я пишу только хелловорлды, а потому что худо-бедно научился хорошему стилю скриптинга.
> Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов.
Да я уже немало лет этим занимаюсь (последний год меньше, но, вроде бы, навык пока не утратил).
> Где-то на просторах интернета был чувак, который исследовал способы работать с путями из шелла, и его вердикт был -- unix suxx.
Много я таких чуваков перевидал. Чего далеко ходить, тут половина анонимусов такие же. Не осилят чего-нибудь и начинают вопить про suxx.
> https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
wm4 в своём репертуаре. Чем писать эту хрень, мог бы чуть погуглить, узнать про существование C.UTF-8 и не позориться.
> Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки.
А за концепцию окружения не надо? То ж самое ведь. Подумали только на пяток ходов вперёд, а не на десять. Бывает. Но ты так и не объяснил, где тут *ошибка, которую невозможно обработать*.

Ответить | Правка | Наверх | Cообщить модератору

77. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 03-Янв-21, 03:29

>> Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca.
> Умею, а что, есть сомнения? Раз притащили в стандарт, значит не посчитали
> вредным. Могли и не тащить.
Наличие чего-либо в стандарте на C -- это не показатель безвредности. Там гумна выше крыши.
>> Где-где, в rust'е вестимо.
> А rust разве в юниксах не работает?
Если что-то работает в unix -- это не значит, что оно часть unix. MSO можно в linux запустить, и чо?
>> Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках.
> Я не пишу bash-портянки. Я пишу скрипты на POSIX shell.
Это разные названия для одного и того же.
> них почему-то очень редко встречаются конвейеры более чем из двух-трёх команд,
> причём источником ошибки, как правило, может быть только одна из них.
> Смею предположить, это не потому что я пишу только хелловорлды, а
> потому что худо-бедно научился хорошему стилю скриптинга.
Хахахахах. "хороший стиль скриптинга"! Лол. Ты сделал мой день. Да будет тебе известно, что хороший стиль скриптинга -- не писать скриптов.
>> Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов.
> Да я уже немало лет этим занимаюсь (последний год меньше, но, вроде
> бы, навык пока не утратил).
И если ты не знаешь проблем с путями, значит навыка и не было никогда.
>> Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки.
> А за концепцию окружения не надо?
Нет. Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет.
> То ж самое ведь. Подумали только на пяток ходов вперёд, а не на десять.
На фоне всего остального, я бы сказал, не "подумали", а повезло.
> Бывает. Но ты так и не объяснил, где тут *ошибка, которую невозможно обработать*.
Я выше дал ссылку. wm4 описывает ошибку, которую невозможно обработать. Весь его баттхёрт из этой ошибки.
> wm4 в своём репертуаре. Чем писать эту хрень, мог бы чуть погуглить, узнать про существование C.UTF-8 и не позориться.
И чем бы ему это помогло?

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск GNU Wget 1.21" +/–

Сообщение от Аноним (11), 03-Янв-21, 13:56

> Наличие чего-либо в стандарте на C -- это не показатель безвредности.
Это показатель неспецифичности для Unix (третий раз повторяю, больше не буду).
> Если что-то работает в unix -- это не значит, что оно часть unix. MSO можно в linux запустить, и чо?
А bash можно в винде запустить. И там будет такая же фигня с конвейерами. И чё?
Выбирай инструмент, которые подходит для твоих целей. В шелле сделано разумно: покрывает 99% потребностей без чрезмерного усложнения.
> Это разные названия для одного и того же.
Нет. Bash и POSIX shell — разные вещи. Портянка и скрипт — тоже разные вещи.
> хороший стиль скриптинга -- не писать скриптов.
Желаю тебе освоить хороший стиль комментирования.
> если ты не знаешь проблем с путями, значит навыка и не было никогда.
Я знаю проблемы, которые возникают у нубов. Как они решаются — тоже знаю. Мои навыки устраивают работодателей, а твоё мнение на сей счёт меня не волнует.
> Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет.
Не распарсил.
> wm4 описывает ошибку, которую невозможно обработать. Весь его баттхёрт из этой ошибки.
Там слишком много баттхёрта, чтобы найти собственно ошибку. Можно TL;DR?
> И чем бы ему это помогло?
Не стонал бы по поводу того, что локаль C не UTF-8, и что UTF-8 нет в POSIX, а понял бы, что эту проблему активно решают, и решение, глядишь, в обозримом будущем докатится и до POSIX. Я понимаю, что ты мне не ради этого ссылку давал, но там 90% — вот эти вот глупые страдашки.

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

80. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 03-Янв-21, 19:01

>> Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет.
> Не распарсил.
Попробуй пописать на чём-нибудь кроме bash. Я б рекоменовал функциональщину, тогда проблем парсить эти вещи не будет.
> эту проблему активно решают, и решение, глядишь, в обозримом будущем докатится и до POSIX
Хаха. Проблема с программой есть сейчас, а не через 20 лет.

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

81. "Выпуск GNU Wget 1.21" –1 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-21, 19:05

Здрасьте, а чем Вам конвейер не функциональщина? (и, кстати, любимая грабелька с ... | ...; var=val; ... и последующей потерей этой var, которая оказалась в другом экземпляре интерпретатора -- здесь как раз фича "readonly для процесса")

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

83. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 03-Янв-21, 19:17

Функциональщина, да. Но она ему не помогает понимать глобальное ридонли состояние. Поэтому лучше не элементы функциональщины использовать, а взять и освоить функциональное программирование в целом, научится думать в этих терминах.

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

84. "Выпуск GNU Wget 1.21" +/–

Сообщение от Аноним (11), 03-Янв-21, 21:11

> Попробуй пописать на чём-нибудь кроме bash.
Это последний мой ответ тебе, поскольку ты всё равно не утруждаешь себя их чтением. Я не пишу на bash.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

85. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 03-Янв-21, 22:52

>> Попробуй пописать на чём-нибудь кроме bash.
> Это последний мой ответ тебе, поскольку ты всё равно не утруждаешь себя
> их чтением.
Чё серьёзно?
> Я не пишу на bash.
Продолжай и дальше заниматься этим буквоедством, я уверен люди к тебе потянутся со временем.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

75. "Выпуск GNU Wget 1.21" +2 +/–

Сообщение от Хулиган (?), 03-Янв-21, 00:01

>> Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем
>> ещё разик: Причём здесь unix way, да и вообще unix?
> Потому что это вообще очень по юниксовому -- верить в то, что
> всё пойдёт хорошо, и не оставлять ни единого костылика на случай,
> если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно
> обработать.
Нормальное ты себе определение придумал. Только зачем эту дичь другим впаривать заправду?

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

82. "Выпуск GNU Wget 1.21" +/–

Сообщение от Michael Shigorin (ok), 03-Янв-21, 19:08

>>> ещё разик: Причём здесь unix way, да и вообще unix?
>> Потому что это вообще очень по юниксовому -- верить в то, что
>> всё пойдёт хорошо, и не оставлять ни единого костылика на случай,
>> если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно
>> обработать.
> Нормальное ты себе определение придумал.
Ну вообще-то это не он придумал.
---
I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out of Unix. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"
--- Tom Van Vleck
(здесь Dennis -- это Ritchie)

Ответить | Правка | Наверх | Cообщить модератору

88. "Выпуск GNU Wget 1.21" +/–

Сообщение от uis (ok), 07-Янв-21, 04:09

> Можно. С тем же результатом, включая сюда и UB.
Явное выделение на стеке? UB!
Временная переменная функции? UB!
Сохранение регистров и вызов функции? UB!!!11
Стек Шрёдингера

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

91. "Выпуск GNU Wget 1.21" +/–

Сообщение от Ordu (ok), 07-Янв-21, 05:36

>> Можно. С тем же результатом, включая сюда и UB.
> Явное выделение на стеке? UB!
> Временная переменная функции? UB!
> Сохранение регистров и вызов функции? UB!!!11
> Стек Шрёдингера
В целом да. C он вообще такой. Разные другие языки выделяют память под стек динамически, или на этапе компиляции вычисляют необходимый размер стека, или разделяют стек на два: control-stack и data-stack. В C же принято полагаться на "авось". Это даже работает в большинстве случаев. Но выделение памяти динамического размера на стеке -- это явно целенаправленная попытка выйти за границы применимости этого "авось".

Ответить | Правка | Наверх | Cообщить модератору

92. "Выпуск GNU Wget 1.21" +/–

Сообщение от uis (ok), 12-Янв-21, 20:58

> Разные другие языки выделяют память
> под стек динамически
man mmap
См. MAP_STACK. Достаточно динамически
>или на этапе компиляции вычисляют необходимый размер стека
Implementation-specific. В данном случае это к компилятору.
> или разделяют стек на два: control-stack и data-stack
Implementation-specific. Кстати, есть архитектуры двумя с "аппаратными" стеками. Эльбрусы, например.
> В C же
> принято полагаться на "авось".
В Си, если программа чего-то не делает, то считается, что программисту виднее.
> Но
> выделение памяти динамического размера на стеке -- это явно целенаправленная попытка
> выйти за границы применимости этого "авось".
Стек весь "авось". Везде.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	49. "Выпуск GNU Wget 1.21"	+1 +/–
	Сообщение от Ordu (ok), 01-Янв-21, 21:18
	> Я так понимаю, это библиотечная функция для выделения памяти. Да, библиотечная. Но она выделяет на стеке. А стек -- хрупкая штука. Во многих проектах alloca вообще под запретом, и за её использование руки отрывают. > void alloca(size_t size); > DESCRIPTION > The alloca() function allocates size bytes of space in the stack > frame of the caller. This temporary space is automatically freed > when the function that called alloca() returns to its caller. > RETURN VALUE > The alloca() function returns a pointer to the beginning of the allo‐ > cated space. If the allocation causes stack overflow, program behav‐ > ior is undefined. Чуешь? Тут документированный UB, и (что очень в стиле unix-way) этот UB невозможно гарантированно обойти. Вызывая alloca, ты никогда не знаешь, будет ли переполнение стека или нет. И узнать не можешь. Но alloca -- это очень быстрый способ выделить/освободить память, гораздо быстрее чем malloc. Поэтому возникает соблазн забить на потенциальные проблемы, и использовать alloca вместо malloc. И есть те, кто перед таким соблазном устоять не может. Если выделять немного, то в принципе ничего плохого не должно случиться. Но что значит "немного"? И это ж надо проверить, так уж ли немного мы собираемся выделить? А если мы проверили, и оказалось много, то что делать? То есть, "немного" ведь означает не больше N, где N -- известное на этапе компиляции целое число. А если мы можем написать: char buf = NULL; if(size <= 256) { buf = alloca(size); } else { die("Invalid size"); // в смысле die -- это no-return функция } то мы с тем же успехом можем написать и: if(size > 256) { die("Invalid size"); } char buf[256]; Тут выходит, что выделяется 256-size лишних байт, но... и чё с того? Это может иметь значение при рекурсивном вызове, но использовать alloca в рекурсивной функции может только полнейший отморозок. То есть alloca оказывается не нужен в такой ситуации. А если size может исчисляться мегабайтами, и мы считаем что наша программа должна работать с такими size, то придётся пользовать malloc, потому как условно использовать alloca или malloc в зависимости от размера -- это то же самое, что открывать нараспашку все двери, вешая над ними транспаранты "MEMORY BUGS ARE WELCOME!". Причём, в такой ситуации, скорее всего и выигрыша по скорости не будет никакого существенного: если программа норм работает с мегабайтовыми буферами, выделенными при помощи malloc, она тем более будет норм работать с докилобайтовыми буферами, выделенными при помощи malloc. Может можно придумать какой-нибудь use-case для alloca, когда это не будет хождениями по граблям переполнения стека AND даст прирост в скорости, но, во-первых, мне не удаётся придумать, во-вторых, это будет очень специальным случаем, и это будет раскладыванием граблей для будущих разработчиков.
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	51. "Выпуск GNU Wget 1.21"	–1 +/–
	Сообщение от Аноним (11), 01-Янв-21, 21:33
	> и (что очень в стиле unix-way) этот UB невозможно гарантированно обойти Причём бы здесь Unix way? Да и вообще, причём здесь alloca? В C99 можно с точно таким же результатом использовать VLA.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 01-Янв-21, 21:55
	> Да и вообще, причём здесь alloca? Новость не читай, сразу комментируй? "Проведена чистка кода от использования функции alloca. В некоторых местах в функции указывался размер непроверенных внешних строк, передаваемых через командную строки или получаемых с внешнего хоста." > В C99 можно с точно таким же результатом использовать VLA. Можно. С тем же результатом, включая сюда и UB.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	65. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Аноним (11), 02-Янв-21, 16:16
	Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем ещё разик: Причём здесь unix way, да и вообще unix? Аргумент, что alloca есть только в этих ваших юниксах, не канает, потому что VLA есть в стандарте языка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 02-Янв-21, 16:33
	> Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем > ещё разик: Причём здесь unix way, да и вообще unix? Потому что это вообще очень по юниксовому -- верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Аноним (11), 02-Янв-21, 19:38
	Мдя? Пяток примеров, специфичных именно для юниксов, тебе ведь не составит труда накидать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 02-Янв-21, 19:52
	> Мдя? Пяток примеров, специфичных именно для юниксов, тебе ведь не составит труда > накидать? alloca не канает? Из мана к ней: > CONFORMING TO > This function is not in POSIX.1. > There is evidence that the alloca() function appeared in 32V, PWB, > PWB.2, 3BSD, and 4BSD. There is a man page for it in 4.3BSD. Linux > uses the GNU version. Если не канает, попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка. Или взять пути в файловой системе, которые позволяют любые символы, даже несмотря на то, что из тысяч софта, может быть единицы могут справится с любыми символами, при том что в подавляющем большинстве случаев нет никакого смысла совать в имя файла ^C или ^M. Смысла нет, но кого колышет? Надо обязательно разложить граблей, без граблей это будет не юникс. Локали обсуждали недавно, с их черезжопностью. Пятый пример... Мне не сообразить сходу. Я подумаю, позже отпишу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Выпуск GNU Wget 1.21"	+1 +/–
	Сообщение от Аноним (11), 02-Янв-21, 23:39
	> alloca не канает? Говорят, у золотых рыбок долговременная память всё ж таки работает. А вот у тебя — не особо. Перечитай тред, что ли. Те же грабли есть в стандарте языка, только называются VLA, а посему — нет, не канает. Неспецифично. > попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка. На сишечке — запросто (ну ладно, не очень запросто, несколько десятков строк кода понадобится написать). В шелле сложнее, да. Но покажи, где подобное реализовано лучше. Да и нужно такое бывает крайне редко. > Или взять пути в файловой системе, которые позволяют любые символы Ну с натяжкой это можно назвать граблями, хотя, скорее, из-за засилья рукожопов, привыкших к ограничениям вынь-доса, чем по объективным причинам. Однако напомню твой тезис: > верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать. Где тут может вылезти ошибка, которую невозможно обработать? Я что-то такого не вижу. > Локали обсуждали недавно, с их черезжопностью. Если ты обсуждал их с голосами в своей голове, это не значит, что все анонимы тоже это слышали. Давай, рассказывай, где там возникают ошибки, которые невозможно обработать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 02-Янв-21, 23:56
	>> alloca не канает? > Говорят, у золотых рыбок долговременная память всё ж таки работает. А вот > у тебя — не особо. Перечитай тред, что ли. Те же > грабли есть в стандарте языка, только называются VLA, а посему — > нет, не канает. Неспецифично. Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca. >> попробуй собрать пайпами цепочку команд и когда она обвалится, выяснить где собственно произошла ошибка. > На сишечке — запросто (ну ладно, не очень запросто, несколько десятков строк > кода понадобится написать). В шелле сложнее, да. Но покажи, где подобное > реализовано лучше. Где-где, в rust'е вестимо. Когда я пишу file.lines().map(...).filter(...).fold(...).бла-бла-бла, я всегда могу отследить источник ошибки. > Да и нужно такое бывает крайне редко. Да, "зелен виноград". Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках. >> Или взять пути в файловой системе, которые позволяют любые символы > Ну с натяжкой это можно назвать граблями, хотя, скорее, из-за засилья рукожопов, Хаха. Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов. Может после этого у тебя пропадёт желание говорить о жопах с руками. >> верить в то, что всё пойдёт хорошо, и не оставлять ни единого костылика на случай, если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно обработать. > Где тут может вылезти ошибка, которую невозможно обработать? Я что-то такого не > вижу. Попробуй из шелла поработать с путями. Где-то на просторах интернета был чувак, который исследовал способы работать с путями из шелла, и его вердикт был -- unix suxx. >> Локали обсуждали недавно, с их черезжопностью. > Если ты обсуждал их с голосами в своей голове, это не значит, > что все анонимы тоже это слышали. Давай, рассказывай, где там возникают > ошибки, которые невозможно обработать. https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки. Знаешь, когда я 20 лет назад, ковыряясь в коде какого-то рогалика, напоролся на замечательный код, который модифицировал глобальную переменную хранящую уровень, с тем чтобы при использовании вещи, чьё действие зависит от уровня, эта вещь сработала согласно тому, на каком уровне она была подобрана, а не тому, на котором уровне она была использована, я подумал, что это бредовый способ справляться с проблемами. Я подумал, что единственная причина простить чувака, который написал этот бред -- это то, что тот чувак такой же безрукий студент, как и я. Но когда общесистемная хрень -- локали -- проектируются таким же образом, причём без единой задней мысли предоставить клиентскому коду, допустим, стек локалей, куда можно сделать push(locale) а потом pop(). То есть вообще просто взяли, присобачили глобал-стейт к каждому процессу, и хрен с ними со всеми потенциальными проблемами -- это либо полнейшая отмороженность, либо просто отсутствие мозга.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Аноним (11), 03-Янв-21, 02:41
	> Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca. Умею, а что, есть сомнения? Раз притащили в стандарт, значит не посчитали вредным. Могли и не тащить. > Где-где, в rust'е вестимо. А rust разве в юниксах не работает? > Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках. Я не пишу bash-портянки. Я пишу скрипты на POSIX shell. И в них почему-то очень редко встречаются конвейеры более чем из двух-трёх команд, причём источником ошибки, как правило, может быть только одна из них. Смею предположить, это не потому что я пишу только хелловорлды, а потому что худо-бедно научился хорошему стилю скриптинга. > Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов. Да я уже немало лет этим занимаюсь (последний год меньше, но, вроде бы, навык пока не утратил). > Где-то на просторах интернета был чувак, который исследовал способы работать с путями из шелла, и его вердикт был -- unix suxx. Много я таких чуваков перевидал. Чего далеко ходить, тут половина анонимусов такие же. Не осилят чего-нибудь и начинают вопить про suxx. > https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... wm4 в своём репертуаре. Чем писать эту хрень, мог бы чуть погуглить, узнать про существование C.UTF-8 и не позориться. > Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки. А за концепцию окружения не надо? То ж самое ведь. Подумали только на пяток ходов вперёд, а не на десять. Бывает. Но ты так и не объяснил, где тут ошибка, которую невозможно обработать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 03-Янв-21, 03:29
	>> Ты читать умеешь? Изобретена alloca в unix. vla изобрели резко позже по мотивам этой самой alloca. > Умею, а что, есть сомнения? Раз притащили в стандарт, значит не посчитали > вредным. Могли и не тащить. Наличие чего-либо в стандарте на C -- это не показатель безвредности. Там гумна выше крыши. >> Где-где, в rust'е вестимо. > А rust разве в юниксах не работает? Если что-то работает в unix -- это не значит, что оно часть unix. MSO можно в linux запустить, и чо? >> Это не нужно, пока ты не начинаешь писать bash-портянки, пытаясь выдавать осмысленные сообщения об ошибках. > Я не пишу bash-портянки. Я пишу скрипты на POSIX shell. Это разные названия для одного и того же. > них почему-то очень редко встречаются конвейеры более чем из двух-трёх команд, > причём источником ошибки, как правило, может быть только одна из них. > Смею предположить, это не потому что я пишу только хелловорлды, а > потому что худо-бедно научился хорошему стилю скриптинга. Хахахахах. "хороший стиль скриптинга"! Лол. Ты сделал мой день. Да будет тебе известно, что хороший стиль скриптинга -- не писать скриптов. >> Попробуй поработать с путями из шелла, попробуй пописать скрипты, которые будут работать с любыми именами файлов. > Да я уже немало лет этим занимаюсь (последний год меньше, но, вроде > бы, навык пока не утратил). И если ты не знаешь проблем с путями, значит навыка и не было никогда. >> Локаль как глобальное состояние -- это то, за что изобретателям её нужно оторвать руки. > А за концепцию окружения не надо? Нет. Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет. > То ж самое ведь. Подумали только на пяток ходов вперёд, а не на десять. На фоне всего остального, я бы сказал, не "подумали", а повезло. > Бывает. Но ты так и не объяснил, где тут ошибка, которую невозможно обработать. Я выше дал ссылку. wm4 описывает ошибку, которую невозможно обработать. Весь его баттхёрт из этой ошибки. > wm4 в своём репертуаре. Чем писать эту хрень, мог бы чуть погуглить, узнать про существование C.UTF-8 и не позориться. И чем бы ему это помогло?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Аноним (11), 03-Янв-21, 13:56
	> Наличие чего-либо в стандарте на C -- это не показатель безвредности. Это показатель неспецифичности для Unix (третий раз повторяю, больше не буду). > Если что-то работает в unix -- это не значит, что оно часть unix. MSO можно в linux запустить, и чо? А bash можно в винде запустить. И там будет такая же фигня с конвейерами. И чё? Выбирай инструмент, которые подходит для твоих целей. В шелле сделано разумно: покрывает 99% потребностей без чрезмерного усложнения. > Это разные названия для одного и того же. Нет. Bash и POSIX shell — разные вещи. Портянка и скрипт — тоже разные вещи. > хороший стиль скриптинга -- не писать скриптов. Желаю тебе освоить хороший стиль комментирования. > если ты не знаешь проблем с путями, значит навыка и не было никогда. Я знаю проблемы, которые возникают у нубов. Как они решаются — тоже знаю. Мои навыки устраивают работодателей, а твоё мнение на сей счёт меня не волнует. > Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет. Не распарсил. > wm4 описывает ошибку, которую невозможно обработать. Весь его баттхёрт из этой ошибки. Там слишком много баттхёрта, чтобы найти собственно ошибку. Можно TL;DR? > И чем бы ему это помогло? Не стонал бы по поводу того, что локаль C не UTF-8, и что UTF-8 нет в POSIX, а понял бы, что эту проблему активно решают, и решение, глядишь, в обозримом будущем докатится и до POSIX. Я понимаю, что ты мне не ради этого ссылку давал, но там 90% — вот эти вот глупые страдашки.
	Ответить \| Правка \| К родителю #77 \| Наверх \| Cообщить модератору


	80. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 03-Янв-21, 19:01
	>> Концепция окружения позволяет прокидывать в процессы данные, которые в целом read-only для процесса. Их глобальность для процесса не влияет. > Не распарсил. Попробуй пописать на чём-нибудь кроме bash. Я б рекоменовал функциональщину, тогда проблем парсить эти вещи не будет. > эту проблему активно решают, и решение, глядишь, в обозримом будущем докатится и до POSIX Хаха. Проблема с программой есть сейчас, а не через 20 лет.
	Ответить \| Правка \| К родителю #78 \| Наверх \| Cообщить модератору


	81. "Выпуск GNU Wget 1.21"	–1 +/–
	Сообщение от Michael Shigorin (ok), 03-Янв-21, 19:05
	Здрасьте, а чем Вам конвейер не функциональщина? (и, кстати, любимая грабелька с ... \| ...; var=val; ... и последующей потерей этой var, которая оказалась в другом экземпляре интерпретатора -- здесь как раз фича "readonly для процесса")
	Ответить \| Правка \| К родителю #80 \| Наверх \| Cообщить модератору


	83. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 03-Янв-21, 19:17
	Функциональщина, да. Но она ему не помогает понимать глобальное ридонли состояние. Поэтому лучше не элементы функциональщины использовать, а взять и освоить функциональное программирование в целом, научится думать в этих терминах.
	Ответить \| Правка \| К родителю #81 \| Наверх \| Cообщить модератору


	84. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Аноним (11), 03-Янв-21, 21:11
	> Попробуй пописать на чём-нибудь кроме bash. Это последний мой ответ тебе, поскольку ты всё равно не утруждаешь себя их чтением. Я не пишу на bash.
	Ответить \| Правка \| К родителю #80 \| Наверх \| Cообщить модератору


	85. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 03-Янв-21, 22:52
	>> Попробуй пописать на чём-нибудь кроме bash. > Это последний мой ответ тебе, поскольку ты всё равно не утруждаешь себя > их чтением. Чё серьёзно? > Я не пишу на bash. Продолжай и дальше заниматься этим буквоедством, я уверен люди к тебе потянутся со временем.
	Ответить \| Правка \| К родителю #84 \| Наверх \| Cообщить модератору


	75. "Выпуск GNU Wget 1.21"	+2 +/–
	Сообщение от Хулиган (?), 03-Янв-21, 00:01
	>> Я-то новость прочитал, ещё б ты прочитал вопрос, на который отвечаешь… Попрубуем >> ещё разик: Причём здесь unix way, да и вообще unix? > Потому что это вообще очень по юниксовому -- верить в то, что > всё пойдёт хорошо, и не оставлять ни единого костылика на случай, > если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно > обработать. Нормальное ты себе определение придумал. Только зачем эту дичь другим впаривать заправду?
	Ответить \| Правка \| К родителю #66 \| Наверх \| Cообщить модератору


	82. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Michael Shigorin (ok), 03-Янв-21, 19:08
	>>> ещё разик: Причём здесь unix way, да и вообще unix? >> Потому что это вообще очень по юниксовому -- верить в то, что >> всё пойдёт хорошо, и не оставлять ни единого костылика на случай, >> если всё пойдёт плохо, чтобы можно было бы ошибку как-нибудь осмысленно >> обработать. > Нормальное ты себе определение придумал. Ну вообще-то это не он придумал. --- I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out of Unix. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'" --- Tom Van Vleck (здесь Dennis -- это Ritchie)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	88. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от uis (ok), 07-Янв-21, 04:09
	> Можно. С тем же результатом, включая сюда и UB. Явное выделение на стеке? UB! Временная переменная функции? UB! Сохранение регистров и вызов функции? UB!!!11 Стек Шрёдингера
	Ответить \| Правка \| К родителю #52 \| Наверх \| Cообщить модератору


	91. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от Ordu (ok), 07-Янв-21, 05:36
	>> Можно. С тем же результатом, включая сюда и UB. > Явное выделение на стеке? UB! > Временная переменная функции? UB! > Сохранение регистров и вызов функции? UB!!!11 > Стек Шрёдингера В целом да. C он вообще такой. Разные другие языки выделяют память под стек динамически, или на этапе компиляции вычисляют необходимый размер стека, или разделяют стек на два: control-stack и data-stack. В C же принято полагаться на "авось". Это даже работает в большинстве случаев. Но выделение памяти динамического размера на стеке -- это явно целенаправленная попытка выйти за границы применимости этого "авось".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	92. "Выпуск GNU Wget 1.21"	+/–
	Сообщение от uis (ok), 12-Янв-21, 20:58
	> Разные другие языки выделяют память > под стек динамически man mmap См. MAP_STACK. Достаточно динамически >или на этапе компиляции вычисляют необходимый размер стека Implementation-specific. В данном случае это к компилятору. > или разделяют стек на два: control-stack и data-stack Implementation-specific. Кстати, есть архитектуры двумя с "аппаратными" стеками. Эльбрусы, например. > В C же > принято полагаться на "авось". В Си, если программа чего-то не делает, то считается, что программисту виднее. > Но > выделение памяти динамического размера на стеке -- это явно целенаправленная попытка > выйти за границы применимости этого "авось". Стек весь "авось". Везде.
	Ответить \| Правка \| Наверх \| Cообщить модератору