defer в C быть!

Он будет по делу только и исключителько в том случае, если size реально может оказаться больше MAX_INT.

Во-первых, чтобы компилятору узнать о том каким может быть size, нужно проводить статический анализ исходника. Современные компиляторы в какой-то мере это умеют, но не идеально. И, даже если так, будет получаться неявное поведение, а это плохо. Во-вторых, сейчас в программе size=5000, потом её переделают так что size=5000000000 и скомпилят каким-то компиляторов который вообще варнинги не пишет, получится баг. А если могло бы и не быть, если бы первый компилятор сообщил в логе всё что полагается.

А это не его типы. Это типы которые возвращают или с которыми работают библиотечные функции. И типы абсолютно корректные.

Это плохие библиотеки. Значит надо перед/после обращения к ним делать тайпкасты, чтобы не тащить эту signed-заразу в свой код.

Там вообще, индекс отсчёта в буфере может сравниваться с кучей double полученных из каких-нибудь тригонометрических функций.

И что? Это не повод делать индекс знаковым. Компилятор кстати на сравнение unsigned int с double никаких варнингов тебе не напишет.

Ну так может надо использовать один и тот же тип и аккуратно кастовать всё?

Ээээ… Зачем что-то кастовать, если используется один и тот же тип?

А если кастовать все типы внезапно оказавшиеся «неправильными», то засирать код длиннющими (unsigned long)var_name - идиотизм.

Ты про JavaScript сейчас? Потому что JavaScript по количеству строк оставляет сишку позади.

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

Ну вот: https://godbolt.org/z/EY1bWPP6d, заодно видно что не важно стэк или не стэк. Благодаря УБ компилятор считает что указатель который вернул do_cast это какой-то другой указатель никак не связанный с &fl (и даже частично не пересекаются в памяти), поэтому пишет по постороннему указателю 1 и сразу вызывает ff(). Единственное чего добьёшся этим do_cast() - это заставишь компилятор гарантированно хранить где-то в памяти fl, что-бы утекший в do_cast() указатель был валидным. Константа вообще не обязана храниться где-то в рантайме, поэтому не важно чё там и как в железе происходит, совершенно абстрактное свойство типа( вместе с УБ)

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

А компиляторы и так его производят, причём уже давно.

Во-вторых, сейчас в программе size=5000, потом её переделают так что size=5000000000

Вот тут и должен появится варнинг.

и скомпилят каким-то компиляторов который вообще варнинги не пишет, получится баг.

А это уже ССЗБ. Или ты должен очень хорошо понимать что делаешь.

И что? Это не повод делать индекс знаковым.

И не повод в каждой строчке кастовать по несколько переменных.

Компилятор кстати на сравнение unsigned int с double никаких варнингов тебе не напишет.

Это просто не добрались ещё теоретики.

Ну вот: https://godbolt.org/z/EY1bWPP6d,

у меня build failed. не видит файла с do_cast.

И не повод в каждой строчке кастовать по несколько переменных.

А и не надо кастовать, надо нормально проектировать софт чтобы таких мест не возникало. У меня как-то получается. Да, есть противные места, как уже упомянутый argc и значения возврата всяких read() write() recv() send() и подобного, их иногда приходится кастовать и перезаписывать в переменную нормального unsigned типа, с которой уже и работать. По-хорошему это всё те же недоработки их 70-х 80-х, когда люди ещё не до конца осознавали необходимость охватывать кодом все сценарии его исполнения, а не только предположительно используемые. По-нормальному read() должен иметь прототип примерно такой

int read(int fd, void *buf, size_t bufsz, size_t *readsz);

Это просто не добрались ещё теоретики.

Нет, ты просто не понимаешь смысл того варнинга. Вот int64 и double варнинг уже может быть, но не из-за знака.

по ассемблеру видно, компилятор проверку fl выкинул и сразу вызывает ff(), т.е. считает что fl никогда не поменятся

и даже без линка - вот она прописывает по указателю, что вернулся из do_cast

 call   50 <tst+0x10>
    R_X86_64_PLT32 do_cast-0x4
 mov    BYTE PTR [rax],0x1

Единственное чего добьёшся этим do_cast() - это заставишь компилятор гарантированно хранить где-то в памяти fl, что-бы утекший в do_cast() указатель был валидным.

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

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

сделай принт була внешней функцией.

void print_bool(const bool* fb);

и значение возврата использовать исключительно для сигнализации об ошибке.

Соглашусь только если в сишечку добавят возможность написать что-то типа ret = read( fd, buf, size, &(size_t readsz) );

Нет, ты просто не понимаешь смысл того варнинга.

Да где уж мне. Но какой-нибудь любитель поговорить о «хороших и недопустимых практиках программирования» когда-нибудь обязательно получит от меня в рыло.

&(size_t readsz)

Ужас какой. Это ещё хуже чем for(int i=

Ужас какой.

Загляни в сырцы любой программы под win32. Вот где ужас, когда вызов функции превращается в портянку из объявлений переменных, адреса которых надо передавать в вендофункции. Особенно бесит, когда ничего из того, что в этих структурах и переменных передаётся и возвращается тебе нахрен не нужно.

Там где не нужно - передаёшь NULL. Но это вообще другая история. Тут число очевидно нужное, и всего одно.

Там где не нужно - передаёшь NULL

И получаешь сегфолт.

Тут число очевидно нужное, и всего одно.

Где одно, там и пара структур с тремя переменными.

Ээээ… Зачем что-то кастовать, если используется один и тот же тип?

Если один и тот же тип, откуда предупреждение компилятора? Что-то ты тут гонишь, дружок!

А если кастовать все типы внезапно оказавшиеся «неправильными», то засирать код длиннющими (unsigned long)var_name - идиотизм.

Зато просрать очередное переполнение – это прямо топчик! У каждого настоящего сишника должна быть хотя бы одна запись в CVE на счету. Иначе посоны засмеют.

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

Да она и в случае с сишкой равна нулю, что тут скрывать-то.

«опять эта чёртова неопределённость»

скорее

если Си(ну бывают экстра ситуации) ваще использовать то только системным(down) программистам после ими же внимательного вывода что более high семантико-синтаксисы не подходят по индустриальным причинам

Что не мешает им быть абсолютно ублюдочными языками

Для тебя есть хоть один нормальный язык программирования?

Не колесо ли изобрели (речь о feder)?

В синтаксис Си добавили feder. Разве в коде Си нельзя просто использовать

goto Feder;

…
…
…

Feder:

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

Любой, любой процессор исполняет код из одного, единого адресного пространства.

Нет. ARM умеют выполнять код прямо с флешки, например.

Так флешка находится в том же адресном пространстве. Там еще и ОЗУ и периферия. Так что утверждение, что Си близок к процессору, верное. По поводу defer мое мнение неизменно, не зависимо от того, встроено оно в компилятор или нет.

Дело вовсе не моём или вашем мнении, а в том как профессионально писать код на Си.

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

PS. Не переживайте, меня обидеть невозможно, я взрослый.

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

PS. Не переживайте, меня обидеть невозможно, я взрослый.

Пошучу - «Богатые тоже плачут».
Мы не роботы …

Честно говоря мне много проще писать писать код, так как использую
свою подсистему управления динамическими переменными и объектами. То что в комитете предлагают лишь малая часть из того что потребно
для разработки алгоритмов.
Например у меня переменным можно задать неограниченной сложности свойства …

В чём проблема многих программистов?

Разрабатывают проекты по «понятиям компиляторов».
Такой подход к разработке весьма схож с МАСАХИЗМОМ.
Конечно никаких rfc писать не буду.
Мне ближе разработка, а не борьба с ветряными мельницами.
Профит от разработки много больше …

Немного пошучу.
Тута шамана на молекулы разбирают.
Вот мужики антиресуются - «Шаман за белых али за красных?».

true было из-за оптимизатора, который активен даже при -O0. Вот поправленный пример, преодолевающий работу оптимизатора с помощью функции flvalue(), проверяющей значение bool переменной. Теперь, как и положено, возвращает true. Остальной код, компилятор и его Флаги не изменял.

https://godbolt.org/z/41GGnefjh

Эх, люди, люди …
Живут «по понятиям» и программируют «по понятиям».
Беда в том, что «понятия» весьма некудышние.
И обижаться на них не могу.
Просто жаль их.

Так что утверждение, что Си близок к процессору, верное.

По такой логике, вообще любой язык программирования близок к некоторым процессорам.

Тот факт, что Си вообще никак не работает на GPU, ты предпочёл проигнонировать.

По поводу defer мое мнение неизменно, не зависимо от того, встроено оно в компилятор или нет.

Твоё мнение здесь не играет роли. В Си есть defer. Тебе придётся с этим жить.

опублихаваться харам?

типо если грасрутнится твоё - тебе почкот и уважука

а то что люди предкомпилируют - ну это беда малосознательных :(

типо если грасрутнится твоё - тебе почкот и уважука

Работы много.
Ныне вот начинаю разработку core подсистемы управления знаниями.
И всё что ныне разработано никому не понадобится за ненадобностью.

Ведь от чего ныне столь много проблем при использовании ЯП, …?

Да потому что людям говоришь «правильно говорить класть», а они всвечно говорят «полож».

Проще говоря не хочу попусту время тратить.
Да и с «продвинутыми» спорить никакого желания нет.

Это основная причина почему не публикую - не нужно.

Ага, про адресное пространство уже в стадии принятия, это хорошо.

По такой логике, вообще любой язык программирования близок к некоторым процессорам.

Нет, не любой. Пример с C# я тебе приводил. Могу привести пример с языком 1С. Но Си не единственный язык, который близок к процессорам, есть и другие.

Тот факт, что Си вообще никак не работает на GPU, ты предпочёл проигнонировать.

Не представляю, почему ты так решил. У тебя есть исходники внутреннего кода, который заливается во флешку GPU процессоров?

Если ты имеешь в виду программирование специализированных процессоров, типа CUDA, то это ближе всего к фреймворку. Т.к. отдельно CUDA процессоры программировать не дают, а заставляют пользоваться компилятором nvcc, который генерирует некий код, который потом будет понятен GPU и будет загружен драйвером персоналки в GPU (опять же, без подробностей). Исходник для шейдеров, файлы *.cu, имеют синтаксис языка С++ с расширением для мультипотокового описания алгоритмов. Т.е. программирование шейдеров ведется сразу для множества спец. процессоров. Как полученный бинарный код реально попадает и выполняется внутри GPU, большой вопрос (тайна разработчиков, но есть энтузиасты, которые копают в этом направлении https://github.com/laanwj/decuda ).

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

Если вернуться к Си и обычным процессорам, то для создания многопоточных/многопроцессорных программ на Си есть расширение OpenMP, встроенное в компилятор gcc. https://ru.wikipedia.org/wiki/OpenMP

Еще есть OpenACC, но с ним я дело не имел. https://ru.wikipedia.org/wiki/OpenACC

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

Твоё мнение здесь не играет роли. В Си есть defer. Тебе придётся с этим жить.

Но высказать его здесь, на сайте, имею право. Мое мнение строго негативное. Так-то в Си и в gcc (который старается придерживаться старндарта ISO https://en.cppreference.com/w/c/compiler_support/23 ) много чего есть, и ничего же, живу спокойно. Или ты думал, что я побегу на другой язык/компилятор, или что мне начнет нравиться defer, или ты просто хочешь, чтобы я больше не писал про свое отношение к defer, или что?

Вот аналог

https://godbolt.org/z/3EebYcMWG

Да потому что людям говоришь «правильно говорить класть», а они всвечно говорят «полож».

Это в каком положении (нормативном акте) эти правила написаны?

Любой, любой процессор исполняет код из одного, единого адресного пространства. Единое, потому что адресное пространство, для команд исполняющейся программы, одно (не путайте с виртуальной памятью).

Это называется Гарвардская архитектура и таких процессоров полно. У них два разных адресных пространства с разными командами для доступа и тд. Самый известный пример это, наверное, процессор в Arduino (AVR ATmega328P).

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

Но высказать его здесь, на сайте, имею право.

Безусловно.
Всё же желательно не просто высказывать мнение, а краткое
объснение почему оно таково.

Если бы в других постах не сказал о том, что использую свою
подсистему управления динаическими переменными и объектами, а
просто сказал, что defer не нужен в Си, то какая польза была бы
от моего некоего мнения без его обоснования?

В любом ЯП мы вольны использовать лиь то, что нам нравится.

Например class в C++ не использую не просто потому, что он
«какой-то не такой», а потому что разработал свою подсистему управления объектами и она много более функциональна и удобна
для разработки чем class.
Да и функциональность посистемы не зависит от мнения «дяди» из
какого-то там комитета.

Всё же желательно не просто высказывать мнение, а краткое объснение почему оно таково.

Резонно, исправляюсь.

defer мне не нравится тем, что его положение в коде не соответствует порядку выполнения алгоритма. Т.е. defer вставляет свой код не явно.

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

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

ИМХО, try cathc выглядит более логичным, чем defer, хотя он тоже ведет к неявно НЕвыполненной части кода, и его я тоже по возможности избегаю.

По такой логике, вообще любой язык программирования близок к некоторым процессорам.

Нет, не любой. Пример с C# я тебе приводил.

C# вполне работает поверх голого железа.

https://wiki.osdev.org/C_Sharp_Bare_Bones

Тот факт, что Си вообще никак не работает на GPU, ты предпочёл проигнонировать.

Не представляю, почему ты так решил. У тебя есть исходники внутреннего кода, который заливается во флешку GPU процессоров?

Потому что я не могу написать программу на Си и запустить её на GPU. А на Haskell могу, например.

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

Это потому что сишка – достаточно дерьмовый и нерасширяемый говноязычок, только и всего. Иначе из него можно было бы генерить код на VHDL, как это можно делать, опять же, на том же Haskell.

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

Конечно не будешь. Из двух спорящих один – подлец, второй – дурак. Вот в этом споре я – подлец.

Потому что я не могу написать программу на Си и запустить её на GPU.

Иначе из него можно было бы генерить код на VHDL, как это можно делать, опять же, на том же Haskell.

Это подлость или дурость?

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

Карча просто супер!
Спасибо разработчикам форума.
Капча спрашивает - «Выбери картинку на которой объект меньше собачки».
Выбираю паровоз, а капча говорит - «Правильно!».
Просьба не менять алгоритм капчи.

Потому что я не могу написать программу на Си и запустить её на GPU.

просто надо стараться.

https://docs.nvidia.com/cuda/

The toolkit includes GPU-accelerated libraries, debugging and optimization tools, a C/C++ compiler, and a runtime library to deploy your application.

что мешает? все канпиляторы там есть.

Спасибо, но в моём регионе ссылка переход по ссылке возвращает;

Access Denied
You don’t have permission to access «http://docs.nvidia.com/cuda/»
on this server.
Reference #18.8d03d717.1748363766.d4ca8cfc

https://errors.edgesuite.net/18.8d03d717.1748363766.d4ca8cfc

это сайт документации cuda. в москве открывается, хотя многие другие - нет. в силу всяких санкций с обоих сторон.

просто там написано прям первым параграфом то, что я процитировал.

Года три поисковик гугла не работал, а недавно опять стал работать.
Но никаких неудобств без поисковика гугла небыло.

А вот за то что youtube не работает, спасибо!
Гораздо меньше стал время попусту тратить.

А вот за то что youtube не работает, спасибо!

да пожалуйста!

Потому что я не могу написать программу на Си и запустить её на GPU.

просто надо стараться.

https://docs.nvidia.com/cuda/

The toolkit includes GPU-accelerated libraries, debugging and optimization tools, a C/C++ compiler, and a runtime library to deploy your application.

что мешает? все канпиляторы там есть.

То, что это не Си:

// Kernel definition
__global__ void VecAdd(float* A, float* B, float* C)
{
    int i = threadIdx.x;
    C[i] = A[i] + B[i];
}

int main()
{
    ...
    // Kernel invocation with N threads
    VecAdd<<<1, N>>>(A, B, C);
    ...
}

Там язык, похожий на Си, но не Си.

Ну это си с нужными им мелкими расширениями.

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

Счас многие плохо стараются. ленятся.

А на хаскеле не хаскель, а DSL на хаскеле, который компилируется посредством llvm.

Дурость, а не подлость.

ну и выведет он тебе этот auto как signed тип с этим же предупреждением

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