В Си предложили добавить switch-case для строк

Ссылка лагает, но если какой-то компилятор вычисляет i=0,(void*)i как асбтрактный NULL то компилятор значит с багом.

Можешь писать сюда: https://github.com/llvm/llvm-project/issues

Но вообще, нет. У указателей есть provenance, и шланг его отслеживает. Поэтому да, записать что-то по нулевому указателю так, чтобы компилятор это не выкинул на мороз, это действительно не самая тривиальная задача в современном мире. Добро пожаловать, я не знаю.

Вроде, минусом было не отсутствие стандарта, а отсутствие альтернативных реализаций. И там сложно сказать, что из чего вытекает — нет альтернатив так как нет стандарта, или нет стандарта, так как нет необходимости приводить альтернативные реализации под более-менее один знаменатель.

А нужны ли эти альтернативы? Если они генерят абсолютно одинаковый код, то какой в них смысл? У си много компиляторов во многом по историческим причинам: отсутствие распространённых практик писать открытый код, написание отдельного компилятора под каждую платформу и тому подобное. Сейчас в этом всём нет никакого смысла, когда можно нужные штуки прямо в апстрим отправить.

И из этого вы сделали вывод, что нужно писать код в строго соответствии ISO стандарту, даже если полученый код не работает на данной версии компилятора/железа?

Твой штатный телепат тебе херню наговорил, уволь его от позора. Моё правило буравчика тут примерно такое:

1. В 99% случаев нужно писать код, соответствующий стандарту, а не просто «скомпилировалось, запустилось, значит окей». Потому что завтра может не скомпилироваться, или не запуститься, или не окей. В оставшемся 1% нужно обложить этот код тестами, документацией и вообще повесить большой знак «ОПАСНОСТЬ».
2. Если с новой версией компилятора ранее работавший точно соответствующий стандарту код сломался (что вообще очень редко бывает), то это 100% баг компилятора и эту версию лучше не трогать. Вместо этого нужно отправить информацию об ошибке разработчикам этого компилятора.
3. Если с новой версией компилятора не соответствующий стандарту код сломался (тот самый 1% выше), то тут ты сам виноват и должен страдать, раз пишешь на Си.
4. Сишников, которые орут про заговор комитетчиков и кривые компиляторы, портящие им код, лучше гнать взашей ссаными тряпками.

Помню, был у нас в прошлом веке один эникейшик-кодер-каратист.

естественно под MS DOS

Ты ещё про перфокарты вспомни.

Не совсем так, компилятор имеет право вычислить указатель как абстрактный NULL, но при этом по этому указателю не должно быть данных/кода, тогда будет соответствие стандарту.

Компилятор никак не может знать/гарантировать отсутствие данных по адресу 0. Поэтому баг.

код

Если этот листинг - содержимое примера от yorshka, то совершенно непонятно, зачем он его привёл. Из него совершенно непонятно, вычислилось ли ptr как абстрактный NULL или нет.

Не буду я им писать, шланг не нужен.

Если этот листинг - содержимое примера от yorshka, то совершенно непонятно, зачем он его привёл. Из него совершенно непонятно, вычислилось ли ptr как абстрактный NULL или нет.

Я вкину подсказку. Clang превращает этот код вот в такой ассемблерный листинг:

main:

Всё, больше ничего нет.

Компилятор никак не может знать/гарантировать отсутствие данных по адресу 0. Поэтому баг.

Это баг, только не компилятора. Это баг в ДНК тех, кто написал стандарт языка, причём с самого начала. Вообще идея выделять отдельное значение под невалидный указатель, и тем более делать его нулевым, ущербна донельзя. Даже (void*)-1 (т.е. все биты выставлены в 1) в качестве невалидного указателя было бы куда лучше. Компиляторщики тут уже вертятся как могут.

Поэтому я повторюсь ещё раз: Си – очень убогий язык. Если ты хочешь, чтобы вот таких выкрутасов с выкидыванием записи по нулевому адресу не было, тебе нужен другой язык, не Си.

Не буду я им писать, шланг не нужен.

Шланг является наиболее качественным компилятором для C и C++ сегодня. По крайней мере, из открытых и работающих под открытыми платформами. GCC – просто убогое недоразумение.

Про баг в головах стандартописателей я полностью согласен, однако в данном случае компилятор не только творить дичь на ровном месте, но ещё и нарушает тот самый стандарт, который авторы шланга так чтят. В стандарте не сказано, что тайпкаст нулевой переменной к указателю должен давать NULL, соответственно NULL-оптимизация тут даже стандарт нарушает. Может ещё сравнить с (char*)123456 на всякий случай, а то вдруг они просто «догадались» что если адрес взят записанным в исходник числом то это что-то там нарушает и надо испортить бинарник (вместо выдачи ошибки на там не нравящуюся им конструкцию). Но что-то я подозреваю, что даже с (char*)1 вывод будет другой, а значит это именно NULL-оптимизация вопреки стандарту.

Поэтому я повторюсь ещё раз: Си – очень убогий язык. Если ты хочешь, чтобы вот таких выкрутасов с выкидыванием записи по нулевому адресу не было, тебе нужен другой язык, не Си.

Нет, Си норм язык, но не в реализации шланга.

В смысле никогда не смогу писать тексты уровня «Грибок уйдёт навсегда, если выпить на ночь простой советский…»? Да, спасибо за комплимент.

Достаточно посмотреть как эти недоумки всунули неотключаемую фатальную ошибку компиляции на unsigned int argc (во имя ISO-графомании, разумеется) чтобы никогда этой чушью не пользоваться. GCC норм компилятор. А вообще скоро надеюсь свой сделаю и буду им пользоваться, вот это и будет «наиболее качественный компилятор для С» (С++ там не будет).

всунули неотключаемую фатальную ошибку компиляции на unsigned int argc

Мне об этом ничего не известно. Ссылку?

GCC норм компилятор

Достаточно хотя бы того, что под каждую целевую платформу (three tuple, ARCH-VENDOR-OS) нужно за каким-то хреном собирать отдельный компилятор. Для сравнения, в том же clang можно собрать один тулчейн, кросскомпилирующий вообще под всё подряд.

Одна из причин, почему кросскомпиляция в лялексе настолько дико сосёт и почему все линуксовые дистры собирают нативно даже под какой-нибудь дико тормозной RISC-V, это как раз вот этот вот самый лютый дебилизм гнутых дегенератов по части GCC и автолулзов. Никто в истории так не поднасрал в развитие открытого кода, как это сделали гнутые ублюдки со своим бородатым мессией во главе.

Писечкой на торте будет тот факт, что LLVM во многом получил развитие из-за бородатого ушлёпка после того, как тот упёрся членом в землю против стабилизации промежуточного языка в GCC и использования его как части API для сторонних проектов, потому что дескать «злые проприетарщики будут этим пользоваться». Нормального разделения на фронт и бэк в GCC вроде как до сих пор нет. Переход на GPLv3 только добавил масла в огонь в итоге. Короче, гнутые делают все из серии «назло маме^Wпроприетарщикам уши отморожу». Как минимум из-за этого GCC стоит выкинуть на помойку и никогда больше не трогать.

Нет, Си как он существует только в моей голове норм язык, но не в любой из существующих реализаций и не в стандарте

Починил.

Даже (void*)-1 (т.е. все биты выставлены в 1) в качестве невалидного указателя было бы куда лучше.

Чем?

В смысле никогда не смогу писать тексты уровня «Грибок уйдёт навсегда, если выпить на ночь простой советский…»? Да, спасибо за комплимент.

Извини, но для ЛОРа способность писать такие тексты – критерий профпригодности. Половина легендарных срачей из 2000х во многом на этом основывались. Без этого ЛОР – это просто синяя тема и сборище дедов-пердедов.

Половина легендарных срачей из 2000х во многом на этом основывались.

И ты, конечно же, сможешь предъявить хоть один?

Даже (void*)-1 (т.е. все биты выставлены в 1) в качестве невалидного указателя было бы куда лучше.

Чем?

Запись в самый последний байт на практике применяется куда реже, чем самый первый. Я навскидку не могу вспомнить ни одного случая, когда нужен был бы указатель именно на самый распоследний байт из всего адресного пространства. В нулевом указателе же необходимость всё же может возникнуть, выше про это писали.

Кстати, угадай чему равна константа MAP_FAILED, которую mmap возвращает при ошибке, и почему mmap не возвращает в этом случае NULL.

Да пожалуйста: Польский священник доказал существование Бога

По факту он, конечно, ничего не доказал.

Даже (void*)-1 (т.е. все биты выставлены в 1) в качестве невалидного указателя было бы куда лучше.

Дак это где-то было, в смысле что ((void*)0) компилятор превращал в 0xFFFF или что-то подобное. Но, почему-то, не взлетело. Вобще из обсуждений на форумах никто не может сказать, почему с самого начала, на PDP-11, когда NULL обозначался как ((char*)0) было выбрано именно значение 0x0000, хотя, вроде как, там лежит вектор какого-то прерывания. При том, что, ЕМНИП, памяти конкретно на той PDP-11 было не по максимуму, то есть был «пустые» адреса.

Во-первых, шланг не промышленный, а копроративный.

Во-вторых, компилятор который выкидывает написанный мной код - говно по определению.

никак не может знать/гарантировать отсутствие данных по адресу 0.

Более того, для всяких микроконтроллеров заранее известно, что там есть данные. Я, единственное, могу предположить, что так сделали, чтобы не было проблем с кодом, собираемым из разных объектников/библиотек. Если вам дают уж скомпиленый obj-файл, и компилятор там использовал NULL не равный 0x000000, то это никак не узнать. Все дружно забили на один пункт стандарта, так как «нюансы» в работе с нулевым адресом не так сложны, в отличии от случая, когда в main NULL будет 0x000000, а в библиотеке 0xFFFFFF.

Типа, в прикладных программах стараниями операционной системе по адресу 0x000000 ничего нет, а всякие ядра ОС, прошивки МК пишут опытные извращенцы Си-шники, и они справятся с совпадением NULL указателя и указателя на нулевой адрес :)

Дак это где-то было, в смысле что ((void*)0) компилятор превращал в 0xFFFF или что-то подобное. Но, почему-то, не взлетело.

Вот это ещё хуже. Прикинь, ты суёшь 0 в указатель, чтобы по нулевому адресу что-то записать, а компилятор делает код, который пишет куда-то в жопу. Нахрен так жить вообще!

Во-первых, шланг не промышленный, а копроративный.

Это одно и то же.

Во-вторых, компилятор который выкидывает написанный мной код - говно по определению.

Спешите видеть! Сишники против dead code elimination! Только сегодня, только на арене нашего цирка!

Кстати, gcc тоже так делает, просто не в этом случае.

Типа, в прикладных программах стараниями операционной системе по адресу 0x000000 ничего нет, а всякие ядра ОС, прошивки МК пишут опытные извращенцы Си-шники, и они справятся с совпадением NULL указателя и указателя на нулевой адрес :)

Это не так. То есть, в некоторых случаях программе в Linux может понадобиться доступ к нулевому адресу. Например, wine так делал чтобы запускать досовый и некоторый виндовый код нативно. Потом в Wine накостылили, конечно, и теперь этого вроде как не требуется, но в старых мануалах до сих пор можно найти совет сунуть mmap_min_addr=0 в sysctl.conf.

Типа, в прикладных программах стараниями операционной системе по адресу 0x000000 ничего нет, а всякие ядра ОС, прошивки МК пишут опытные извращенцы Си-шники, и они справятся с совпадением NULL указателя и указателя на нулевой адрес :)

Точно! Тем более, что в те времена решения про первую странцу, операционки, и стандарт С решали одни и те же люди, а в первую станицу всё-равно лезут на ассемблере, значит для Си всё безопасно!

Шутка юмора.

Ну уж wine то разрабатывали мега опытные :) Они же в 2003 году, из своего кода пачили исполнямый код libc, когда errno в GNU libc перестал быть int, а стал макросом/функцией. А им нужно было его менять/перехватывать. ЕМНИП, делали mprotect() и запись байт (опкодов jmp или call), уж не помню, а нагуглить не получается.

Мысли в слух

Ну, поглядел я на предложение, с первых же слов буквально, давайте сделаем вместо явного if-else с явным вызовом cmp_call явный switch cо скрытым cmp_call чтобы просто убрать один из вариантов бойлерплейта. То есть не привнести что-то новое решающее проблемы, а создать новую. Отмечается что явным образом написанная конструкция с strcmp синтаксически тяжёлая. Ой да ладно, это никогда не было проблемой в том и суть что явным образом прописываются действия зачастую ещё и по больше части на си описывается не просто ЧТО сделать, а КАК это сделать. Далее там вода не имеющая ценности.

Да, чисто механически совать в переключатель строки будет удобнее, но какой ценой, во первых, кто сказал что строки можно сравнивать только как массивы? Короткие строки могут быть сравнены просто как числа, более того сравнивать строки можно вообще без их участия если есть механизм дедупликации строк. Если они статик то можно вообще указателями и так далее есть куча вариантов оптимального в рамках задачи сравнения.

Ну ок, ну вот допустим завтра всё, в станларте после завтра в компиляторах, хорошо что там неявно вызывается, допустим системный strcmp который почти всегда ещё аппаратно ускорен и в просто сравнении строк молодец, но всё же есть другие способы сравнения, значит могут быть оптимизации значит будут доп ключи к компилятору для выбора той или иной, а если надо всё же что-то более специфичное через прагму или дефайн обработчик свой указывать? А обратная совместимость?

Стоит ли обычное, без спору удобное (но только для общих случаев сравнения строк неопределённой длинны) чисто синтаксическое упрощение, того что это рубит совместимость или заставляет через ifdef дублировать простой сам по себе синтаксический примитив, заставляет задумываться о том что там будет происходить вообще в одном компиляторе, а другом? В одном тая, в другом сяк.

Более того, сам автор приводит функцию как бы илюстрирующую работу свича со строками, но тут как по мне автор сам себя переиграл, сам тот факт что можно не просто где-то между описать свич, а с таким же успехом описать любой тип сравнения данных по указателю со статическими строковыми литералами через описание всего этого как функции, как по мне ставит крест на новой синтаксической конструкции, что она даст? Кроме как слегка, даже не значимо, а лишь слегка короткой записи сравнения строк в обмен на целую пачку побочных явлений?

У этой фичи слишком мало весомых преимуществ. Оно не привносит ничего нового, не решает никаких проблем, даёт добро на неявные рантайм вставки, которые сами по себе желательно бы ещё и разные нужны, если коли уж. Справедливости ради там упомянуто и про хеши и так далее, но тут тоже затык, ещё больше неявного стандартизировать хеширование строк на уровне языка или от балды имплементатион дефайнед? Допустим если так привет бенчи, надо больше бенчей, проверять оно там ок или вручную всё.

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

Фича из разряда перестановки стульев, приколюха и так далее. Вот когда ввели сахар в виде for это ещё ладно, ибо оно может быть использовано широко и разнообразно, даже без тела из за того что может явным образом делать сразу последовательность разных вещей, что пропишешь. for сахарок но явный, ничего не скрыто, глубокая семантика и так далее. Там было понятно, а это, прикольно, местами удобно + тележка побочек, неявностей, разночтения, разнореализаций и так далее. Фича тележку эту не перевешивает. И это скорее всего не примут, ну, а если примут. Ну допустим, в конце концов никто не мешает это не использовать. Где-то у утилитках, тяп там да ляп, нормально будет, удобно тут спору нет. Но в целом сомнительно.

В си на базовых его примитивах можно описать всё что угодно, выделять какой-то частный случай синтаксической комбинации if-else + call выглядит странно, так как так можно ой как далеко поехать, там не сахар а целое варенье уже можно финачить или сгущёнку, например, муторно каблеки писать где-то в стороне, давай просто прям в аргументе ну типа лямбда. А во ещё, раз мы теперь так делаем то хорошо бы смотрелось словечко await, ну а что чего зря добру пропадать пусть пока вызов не прошёл функция не стартует далее ещё десятки если не сотня другая «улучшений» языка можно привести, через внесение комплексных вещей, всё бы ладно, только это немножечко не про Си. Уже есть много других языков где всё кратко и каждое выражение обрадает большой семантической глубиной и малым синтаксическим размером, со сложным поведением и кучи всего происходящего неявно под капотом.

Ситуативное, даже лучше сказать местячковое синтаксическое улучшение не стоит того чтобы открывать ящик пандоры. А если и открывать, то лучше уже в рамках друго-го языка, я хз си на стероидах, хотя плюсы уже кажется есть.

Как эстету мне нравится, да чисто выглядит и красивенько, а как придирчивому зануде, нет оно просто не стоит того.

Ну уж wine то разрабатывали мега опытные :)

Тем не менее, благодаря этим чувакам в том числе лялекс сегодня становится весьма годной платформой для запуска вендовых игр. Ну и слава Габену, конечно же!

Они же в 2003 году, из своего кода пачили исполнямый код libc, когда errno в GNU libc перестал быть int, а стал макросом/функцией. А им нужно было его менять/перехватывать. ЕМНИП, делали mprotect() и запись байт (опкодов jmp или call), уж не помню, а нагуглить не получается.

Это ты ещё, видимо, не в курсе, что GCC делает с заголовочными файлами. Когда я узнал об этом, у меня волосы неделю на жопе дыбом стояли от ужаса.

Мне об этом ничего не известно. Ссылку?

А ты проверь, делов то. Я даже в исходнике шланга это место потом нашёл чтобы действительно убедиться, что там не какой-то варнинг с дефолтным -Werror, для которого я в мануалах не нашёл флага отключения, а именно безусловное падение компиляции при этом возмутительнейшем нарушении стандарта.

Достаточно хотя бы того, что под каждую целевую платформу (three tuple, ARCH-VENDOR-OS) нужно за каким-то хреном собирать отдельный компилятор.

Да, это конечно неудобно. Но шланг всё равно ненужен.

Нет, Си как он существует только в моей голове норм язык, но не в любой из существующих реализаций и не в стандарте

Даже если так, то со временем реализация появится и ты даже сможешь ей пользоваться. Никакой чуши, портящей бинарники, в ней не будет.

Поэтому в стандарте и прописано, что только ((void*)0), от константного выражения, нужно считать NULL-указателем. В целом, сувание чего-то в указатель противоречит идеям Си, где указатель мы получаем от malloc() или от операции взятия указателя (адреса) переменной. Если нужно что-то сувать в указатель, значит нужно каждую букву стандарта изучить.

А главное, что часто не ты суёшь что-то в указатель, а разработчики SDK или как назвать кучу #define идующую для работы с микроконтроллером. У тебя есть куча #define, и примеры/описание, что пиши сюда будет это, пиши туда будет то. А какой из этих макросов окажется указателем на адрес 0x000000 изучай сам.

Наверно есть ещё одна причина: сравнение с нулём часто (по крайней мере раньше было) по совокупности факторов эффективнее чем сравнение с другими числами.

Как бы то ни было, на мой взгляд следовало сделать NULL честным нулём, а правило «не совпадает ни с чем другим» выкинуть (вместе с NULL-оптимизациями). malloc-у и системному загрузчику бинарников запретить выделять память по этому адресу, а в остальных местах программист сам уж разберётся как ему интерпретировать данное значение.

Мне об этом ничего не известно. Ссылку?

А ты проверь, делов то. Я даже в исходнике шланга это место потом нашёл чтобы действительно убедиться, что там не какой-то варнинг с дефолтным -Werror, для которого я в мануалах не нашёл флага отключения, а именно безусловное падение компиляции при этом возмутительнейшем нарушении стандарта.

Ты про то, что int main(unsigned argc, char *argv[]) {} не собирается? Окей, в стандарте написано следующее (пункт 5.1.2.3.2). Допустимые варианты объявления main:

1. int main(void) { ... }
2. int main(int argc, char *argv[]) { ... }
3. Какие-либо другие, допускаемые реализацией («or in some other implementation-defined manner.»)

Поведение шланга тут ничего не нарушает. Зачем тебе нужно делать argc беззнаковым, кроме как чтобы поныть про плохой clang, я не знаю.

Да, это конечно неудобно. Но шланг всё равно ненужен.

Страдай. Я собираю всё шлангом, и я не один такой. Твоя любимая FreeBSD тоже шлангом собирается.

Даже если так, то со временем реализация появится и ты даже сможешь ей пользоваться. Никакой чуши, портящей бинарники, в ней не будет.

Когда появится, тогда и поговорим. Пока что она не появилась (хотя многообещающие попытки есть, см kefic и cproc).

Поэтому в стандарте и прописано, что только ((void*)0), от константного выражения, нужно считать NULL-указателем. В целом, сувание чего-то в указатель противоречит идеям Си, где указатель мы получаем от malloc() или от операции взятия указателя (адреса) переменной. Если нужно что-то сувать в указатель, значит нужно каждую букву стандарта изучить.

А главное, что часто не ты суёшь что-то в указатель, а разработчики SDK или как назвать кучу #define идующую для работы с микроконтроллером. У тебя есть куча #define, и примеры/описание, что пиши сюда будет это, пиши туда будет то. А какой из этих макросов окажется указателем на адрес 0x000000 изучай сам.

Я же уже писал, что сишечка – крайне убогий язык, авторы которого ненавидят разработчиков? Стоит повторить лишний раз: сишечка – крайне убогий язык, авторы которого люто ненавидят разработчиков на этом языке и хотят, чтобы те страдали. А те и рады!

Это одно и то же.

Мда. Не думал что настолько всё плохо. Корпоративный - это вообще-то антоним к промышленный во всех возможных смыслах.

Кстати, gcc тоже так делает, просто не в этом случае.

Да, gcc старательно пытаются изговнякать и превратить в такое же говно как шланг, но gcc пока ещё держится.

Мда. Не думал что настолько всё плохо. Корпоративный - это вообще-то антоним к промышленный во всех возможных смыслах.

В твоём манямирке – возможно. В реальной жизни это всё одни и те же люди.

Да, gcc старательно пытаются изговнякать и превратить в такое же говно как шланг, но gcc пока ещё держится.

Я просто приведу здесь цитату широко известного героя по имени Тео де Раадт, написанную им когда LLVM был ещё в зачаточном состоянии и не выходил за рамки исследовательского проекта:

List:       openbsd-misc
Subject:    Re: /etc/mk.conf
From:       Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date:       2005-04-07 1:24:51
Message-ID: 200504070124.j371Opsq031199 () cvs ! openbsd ! org

> > i am ussing current compiled with these options for some time now, and
> > everything is just OK,
> 
> and how much faster is it?  have many more widgets can you pump out in an 
> hour?
> 
> as a reference, the last time i played with said options, i wound up with 
> a gcc that couldn't compile anymore.

and the further you get from i386, the more bugs you run into.

as you crank up the options, all the other architectures, from vax (dig
in the tree for the ifdefs), to sparc, to sparc64 (a few more), to alpha
(even more), to mips64 (oh my), even up into arm (of course), even amd64,
and then as mickey just found out hppa64 spitting out garbage FP instructions
for integer only operations...

anyone who does this is not just mad, or crazy, or playing, they are
plain flat out stupid.

i count gcc as being, on the low end, 400,000 lines of code per architecture.

which will have bugs.  let's call it the 1 bug that matters per 10 lines of
code, naw, let's be kind.  let's call it 1 bug that matters per 25
lines of code.

that's 16,000 bugs.

99% of the user community finds their way through that swamp of bugs
by using the default.  that is what gets tested, and that is what gets
fixed.

some bugs relate to gcc crashing, others to gcc generating wrong code
(by the way, our experience is that it is WAY EASIER to get "gcc
to generate wrong code"....) 

now you wish to go fiddling with choices, and getting yourself into a
mess.

it is people like who who give a bad name to people with mental
deficiencies.

... perfectly well trained people, who can send email, who think they
can run a computer, even probably have a drivers license, but no, it
is people like you are DOWNRIGHT DANGEROUS, because you wouldn't know
a safe choice if it hit you flat in the face, and you will ALWAYS push
every button available to you because you have fooled yourself into
believing that is LEARNING, that is ADVANCEMENT

retards.

в стандарте написано

Я в курсе что там написано (и сразу ж уточнил: «во имя ISO-графомании»), но это никак не отменяет идиотизм ситуации. Конкретно с unsigned int там в лучшем случае должен быть варнинг, включаемый при -pedantic, а вообще даже main(char q, float x) надо компилировать, выдавая опять же варнинг, тут уже дефолтно-включённый имеет смысл. Кому надо поставят на него -Werror, а то шлангоавторы очевидно решили повоспитывать своих юзеров, за что шлю им клоуна.

Зачем тебе нужно делать argc беззнаковым, кроме как чтобы поныть про плохой clang, я не знаю.

Угадай, откуда я про это узнал вообще? Думаешь лазил по исходникам шланга, в поисках где бы его покритиковать? Вовсе нет, изучил этот вопрос я после того как эта чушь отказалась компилировать мою прогу. И, кстати, в freebsd до 9 версии тоже было много исходников с unsigned argc, они их ради мерзкого шланга исправляли :(. А unsigned там потому что argc по смыслу не бывает отрицательным, и я считаю правильным не использовать signed там, где знаковость не предполагается. В частности, можно писать так:

unsigned int j;
for(j=1; j<argc; j++) {
}

unsigned int j;
for(j=1; j<(unsigned)argc; j++) {
}

Твоя любимая FreeBSD тоже шлангом собирается.

Да, я был очень расстроен когда они это сделали. И с тех пор кстати у неё мир пересобирается раз в 10 дольше, т.к. 90% времени теперь тратится на компиляцию шланга. Но себе ставлю gcc из портов всегда и им пользуюсь для своих компиляций.

Мне кажется он авторов wine хвалил в обоих цитатах, а ты их наоборот воспринял.

Польский священник доказал существование Бога

Это какой-то тупняк и УГ, а не "легендарный срач". У тебя легендарность по числу постов измеряется, чтоле?

Запись в самый последний байт на практике применяется куда реже, чем самый первый.

Частотность обоих случаев настолько близка к нулю, что разницей можно пренебречь.

В нулевом указателе же необходимость всё же может возникнуть

Не оправдывает полученной экономии на проверку регистра нулю. Эта операция примерно всегда одна из самых быстрых и как правило быстрее проверки на любое отличное от нуля значение.

Польский священник доказал существование Бога

Это какой-то тупняк и УГ, а не «легендарный срач». У тебя легендарность по числу постов измеряется, чтоле?

Ну, да? И ещё в количестве забаненных участников, но эта инфа не публикуется.

Запись в самый последний байт на практике применяется куда реже, чем самый первый.

Частотность обоих случаев настолько близка к нулю, что разницей можно пренебречь.

Это ты расскажи участникам выше, у которых там таблицы прерываний и прочее.

Не оправдывает полученной экономии на проверку регистра нулю. Эта операция примерно всегда одна из самых быстрых и как правило быстрее проверки на любое отличное от нуля значение.

Не оправдывает для кого? Для тебя? Возможно. Для других может оправдывать. С другой стороны, процессоры сейчас чаще оптимизируют под софт (а не только наоборот), поэтому если бы в сишечке изначально тут вместо 0 было FFFF, то процессоры бы подогнали в пределах поколения. Зато теперь мы все страдаем.

Короче, вариант с FFFF чуть менее убог. Но лишь чуть.

Я в курсе что там написано (и сразу ж уточнил: «во имя ISO-графомании»)

Сорри, я криво прочитал тот твой коммент и подумал, что clang как-то нарушает стандарт. Mea culpa!

а вообще даже main(char q, float x) надо компилировать

Нахрена? Зачем это делать? Тебе просто скучно, что ли?

Вовсе нет, изучил этот вопрос я после того как эта чушь отказалась компилировать мою прогу. И, кстати, в freebsd до 9 версии тоже было много исходников с unsigned argc, они их ради мерзкого шланга исправляли :(. А unsigned там потому что argc по смыслу не бывает отрицательным, и я считаю правильным не использовать signed там, где знаковость не предполагается.

Ну то есть, везде был кривой код, а виноват clang. Тут вопрос ни к нему, а к сишному стандарту уже. Который, как мы оба уже согласились, писали криворукие наркоманы.

И с тех пор кстати у неё мир пересобирается раз в 10 дольше, т.к. 90% времени теперь тратится на компиляцию шланга.

Обожаю гентушников и им уподобляющихся! Сначала ставят систему, которая вынуждает их собирать софт из исходников, а потом ноют, что они теперь вынуждены собирать софт из исходников. Кто бы мог подумать, что так случится?

Нахрена? Зачем это делать? Тебе просто скучно, что ли?

А зачем вообще пишут функции с некими аргументами? Раз написали, значит надо. Совсем не дело компилятора задаваться философскими вопросами, его дело - генерить бинарник по заданному коду. Если функция, кажется, содержит что-то неправильное - можно программиста об этом предупредить варнингом, но ни в коем случае не надо ему что-то запрещать. Представь молоток с цифровым зондом от производителя, который откажется работать если увидит вместо гвоздя саморез? Да, забивать саморезы молотком обычно неразумно, но задаваться подобным вопросом должен работник или его руководитель/заказчик, а никак не инструмент.

Ну то есть, везде был кривой код, а виноват clang. Тут вопрос ни к нему, а к сишному стандарту уже. Который, как мы оба уже согласились, писали криворукие наркоманы.

Нет, код нормальный. Стандарт тут ни при чём. Авторы шланга - как дурак, который лоб расшибёт если его молиться заставят.

вынуждены

Фрибсд не вынуждает собирать из исходников. Однако, иногда по каким-то причинам это может захотеться, и трата 90% времени (и электричества) на сборку компилятораа вместо полезной деятельности - плохо.

Тео что-то сказал. И чо?

Лучше бы своей опенбздёй занимался, а то ведь подыхает же проект. Линукс сожрут копрорасты, а бздя сдохла. Нехорошо ведь получится.

Совсем не дело компилятора задаваться философскими вопросами, его дело - генерить бинарник по заданному коду

ни в коем случае не надо ему что-то запрещать

Представь молоток с цифровым зондом от производителя, который откажется работать если увидит вместо гвоздя саморез? Да, забивать саморезы молотком обычно неразумно, но задаваться подобным вопросом должен работник или его руководитель/заказчик, а никак не инструмент.

Мне кажется, ты ищешь и никак не можешь найти lisp. Lisp - это тот язык, который тебе нужен. Там настоящая свобода. Программист может творить как творец, а компилятор только послушно исполняет инструкции. Переходи на lisp!

А зачем вообще пишут функции с некими аргументами?

main – это часть системного API. Она будет вызвана с вполне определённым данным форматом данных на входе. Другого пути тут нет. Если не нравится, правь компилятор.

Нет, код нормальный

Нет, этот код содержал ошибки. Компилятор их нашёл и пожаловался на них. Ты почему-то страдаешь.

Фрибсд не вынуждает собирать из исходников. Однако, иногда по каким-то причинам это может захотеться, и трата 90% времени (и электричества) на сборку компилятораа вместо полезной деятельности - плохо.

Ну так не собирай компилятор. Тебя ж никто не заставляет это делать.

Тео что-то сказал. И чо?

GCC всегда был говном. Вот чо. Хуже с годами он точно не становится.

GCC всегда был говном.

Всё ещё бесконечно лучше конкурентов по соотношению цена / качество в ретроспективе.

И что? Мне совершенно насрать на то, что о gcc кто-то там думает. Он работает так, как мне нужно, а остальное меня не волнует вообще.

Системное апи - дело библиотек, линкера и лоадера, а никак не компилятора. Если компилятору говорят что main(char x, float y) - он должен сгенерить под меткой main именно код, использующий такие аргументы. Если эти аргументы окажутся несовместимыми со стартовым кодом libc - ну, программист сам виноват, но это его дело, а не компилятора.

Ну так не собирай компилятор. Тебя ж никто не заставляет это делать.

А ты попробуй собрать фрибсд без сборки шланга, да и потом быть уверенным что нигде ничего не повредилось незаметно. Мне тут уже подсказывали поотключать сборку шлангочастей для arm и прочих ненужных архитектур, это можно, и думаю это максимум что можно тут сделать если не хочешь потом мейнтейнить всю кодовую базу.

Он работает так, как мне нужно, а остальное меня не волнует вообще.

Типичное сишное УМВР от чувака, который не способен писать код без переполняющихся буферов.

@r--r--r--

Всё ещё бесконечно лучше конкурентов по соотношению цена / качество в ретроспективе.

Если говорить про 90е, когда под люнекс вообще нихрена не было, то может быть. Но это не столько чтобы заслуга авторов GCC, сколько тотальный провал юниксовых вендоров. Если говорить про сегодняшний день, то нет.

Если компилятору говорят что main(char x, float y) - он должен сгенерить под меткой main именно код, использующий такие аргументы. Если эти аргументы окажутся несовместимыми со стартовым кодом libc - ну, программист сам виноват, но это его дело, а не компилятора.

Вот за что я люблю ЛОР, так это вот за такое! Абсолютно неповторимый уровень бессмысленного и беспощадного технического безумия. Это как хирурги с горящими глазами из фильмов ужасов про нацистов, пересаживающие пациентам член на лоб – никто не знает, зачем они это делают, а результаты воистину ужасают, но это неотъемлемая часть сюжета, без которой такие произведения не производят нужного эффекта.

Если говорить про 90е, когда под люнекс вообще нихрена не было

Если говорить про 90е, то тогда и самого люнекс вообще нихрена не было в каком либо пользовательском виде до 97-ого года примерно, когда он начал догонять BSD по возможностям unix-ящика. А уж как десктоп выглядел до конца того тысячелетия - лучше и не знать:   1     2  

тотальный провал юниксовых вендоров

С чего бы? У юниксовых вендоров прекрасно работали их компиляторы на их системах.

Если говорить про 90е, то тогда и самого люнекс вообще нихрена не было в каком либо пользовательском виде до 97-ого года примерно, когда он начал догонять BSD по возможностям unix-ящика.

GCC появился до Linux и тогда уже был вполне зрелым проектом.

тотальный провал юниксовых вендоров

С чего бы? У юниксовых вендоров прекрасно работали их компиляторы на их системах.

И нам это известно откуда? Из рекламных брошюр? Я из этого зоопарка успел только солярку застать – мой универ на ней плотно сидел, и хочу сказать, что тот же suncc был дном даже на солярке.