LLVM. Зачем он вообще нужен?

В этом месте использование sizeof, про который написано, что это implementation defined.

А про double: где-то в Стандарте есть указание, что 1,1 в нëм является точным числом?

В этом месте использование sizeof, про который написано, что это implementation defined.

И что? В стандарте нигде не запрещается использовать implementation defined операции и типы данных. В стандарте запрещается строить поведение программы в зависимости от разницы между ними на разных платформах:

It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior.

То есть вот эта программа:

#include <stddef.h>

int main(void)
{
    size_t sz = sizeof(size_t);
    if (sz > 4)
    {
        return 1;
    }
    else
    {
        return 0;
    }
}

Не будет строго соответствовать стандарту, так как её вывод зависит от implementation defined операций.

А про double

А про double мы уже всё разобрали выше

не запрещается использовать implementation defined операции и типы данных

В твоей же цитате «It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior». А программа, выводящая результат sizeof, определённо produce output dependent on implementation-defined behavior.

Не будет строго соответствовать стандарту, так как её вывод зависит от implementation defined операций.

Разумеется.

Не будет строго соответствовать стандарту, так как её вывод зависит от implementation defined операций.

Разумеется.

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

А программа, выводящая результат sizeof, определённо produce output dependent on implementation-defined behavior.

Давай уточним - ты утверждаешь, что сами выводимые диапазоны значения переменных являются implementation defined behavior?

ну растянули баян на 12 страниц. даешь другую тему!

на 12 страниц.

Число страниц - implementation defined и, таким образом, твой пост не является strictly conforming:

Наиболее обсуждаемые темы этого месяца:
LLVM. Зачем он вообще нужен? (556)
Astra Linux 1.8 (407)

Давай уточним - ты утверждаешь, что сами выводимые диапазоны значения переменных являются implementation defined behavior?

Почитай вот это:

Strictly conforming programs are intended to be maximally portable among conforming implementations. Conforming programs can depend upon nonportable features of a conforming implementation.

И вот это:

A strictly conforming program shall use only those features of the language and library specified in this document. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.

Понимаешь, посыл? Программа не должна полагаться на то, что sizeof() вернет тебе 8. Но программа может вести себя одним образом если sizeof() возвращает 8 и другим, если он возвращает 4.

Программа соответствует стандарту

Программа соответствует стандарту, но не строго соответствует стандарту (не strictly conforming program).

что сами выводимые диапазоны значения переменных являются implementation defined behavior?

Сами выводимые значения размеров, полученные через sizeof, являются результатом implementation defined behavior.

Но программа может вести себя одним образом если sizeof() возвращает 8 и другим, если он возвращает 4.

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

Сами выводимые значения размеров, полученные через sizeof, являются результатом implementation defined behavior.

М-м-м-м-м… Как сейчас будет вкусненько. Я тогда не только берусь доказать, что даже строго соответствующая Стандарту (strictly conforming) программа на Си может выдавать разные результаты в разных средах исполнения.

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

5.2.4.2.1 Sizes of integer types <limits.h>

1
The values given below … Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

И дальше для всех существующих в си типов. То есть буквально любой, существующий в си «встроенный» тип данных имеет implementation defined размерность.

В стандартной библиотеке си нет функций вывода единичных битов. Следовательно любой вывод в двоичном виде будет implementation defined, и программы строго соответсвующие стандарту ничего никуда выводить не должны. Даже return 0; в main имеет неизвестную битовую implementation defined разрядность.

И да, разумеется, всякие printf’ы сразу вылетают на свалку истории, потому что там ещё кодировки подскакивают кабанчиком.

С заявленным тобою уровнем формализма, ты вообще остался без языка программирования, с чем я тебя сердечно поздравляю!

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

но кажется это невозможно.

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

Именно что строго. То, что ты обрабатываешь кейсы, как раз и делает ее строгой. Если бы ты полагался на то, что sizeof() всегда 8 и выдавал бы неверный результат — это как раз было бы нестрогое.

Если твоя платформа не позволяет выделить тебе терабайт памяти, твоя программа должна об этом сообщить и выйти. И, еще раз — нельзя полагаться на implementation defined. У тебя не должно быть ожиданий, что реализовано оно будет вот так вот, или что long int это всегда 8 байт. Но если это проверил благославленным способом, ты не внес нестрогость.

У тебя не должно быть ожиданий, что реализовано оно будет вот так вот, или что long int это всегда 8 байт. Но если это проверил благославленным способом, ты не внес нестрогость.

Внёс, так как результат программы становится зависимым от длины long int. В строго соответствующей ты должен в long int хранить в диапазоне -2147483647…2147483647, а не смотреть на sizeof.

Использовать sizeof в строго соответствующей можно только при создании динамического массива через malloc (в предположении, что длина массива в байтах или сам массив в виде байтов никуда не выводится). В этом случае на вывод программы значение sizeof не влияет.

Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign

Всё так. Эти значения использовать нельзя. Остальные можно.

Например, для int нельзя использовать значения больше 32767.

И дальше для всех существующих в си типов. То есть буквально любой, существующий в си «встроенный» тип данных имеет implementation defined размерность.

Именно поэтому значение sizeof является implementation defined.

В стандартной библиотеке си нет функций вывода единичных битов. Следовательно любой вывод в двоичном виде будет implementation defined

Да. Можно только в виде чисел в явно заданном формате.

Даже return 0; в main имеет неизвестную битовую implementation defined разрядность.

Нет. Здесь число возвращается как число, а не набор битов. В любом окружение это будет именно число 0, как бы в этом окружении 0 ни изображался.

И да, разумеется, всякие printf’ы сразу вылетают на свалку истории, потому что там ещё кодировки подскакивают кабанчиком.

printf как раз даёт одинаковый вывод на любой системе. Кодировка для char[] тоже не важна. Это уже трактовка вывода программы, а не её вывод.

Внёс, так как результат программы становится зависимым от длины long int. В строго соответствующей ты должен в long int хранить в диапазоне -2147483647…2147483647, а не смотреть на sizeof.

Ты выдираешь из контекста. Там же написано о чем речь: строго соответствующая программа должна полагаться только на описанные механизмы и использовать минимально допустимые значения, чтобы программа была портируемой. Если для реализации алгоритма тебе нужно знать размер sizeof… сделай это. Это описанный в стандарте механизм. Если программа будет работать на 16 битном процессоре читая все с диска, а на 64 битном процессоре делая все в памяти, это не делает её менее портируемой.

Если программа будет работать на 16 битном процессоре читая все с диска, а на 64 битном процессоре делая все в памяти, это не делает её менее портируемой.

Да, я неверно понял. Если результат программы будет идентичен, а отличаться будут только особенности реализации, то да.

В принципе, сейчас так memcpy в glibc выглядит. Пачка implementation defined веток с идентичным действием.

Да. Можно только в виде чисел в явно заданном формате.

Каком «явно заданном формате»? Где это в стандарте?

Нет. Здесь число возвращается как число, а не набор битов

Это абсурдное утверждение. Согласно стандарту любое число представлено как набор битов и любые операции происходят над ним. У тебя нет числа без набора битов. Набор битов даёт тебе какой-либо тип, в рамках которого ты можешь выразить число в некотором диапазоне. Любая операция над числом == операция над набором битов.

В любом окружение это будет именно число 0
Кодировка для char[] тоже не важна. Это уже трактовка вывода программы, а не её вывод.

Не-не-не, дэвид. Соскочить не получится. Ты сам заявил:

суть strictly conforming program именно в том, что её вывод одинаков на всех компиляторах Си, соответствующих стандарту.

Что может подразумевать только одно - побитово идентичный вывод. Если хоть в одном бите разница - программа не удовлетворяет условию в твоём понимании.

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

для int нельзя использовать значения больше 32767

Найди доказательство этого тезиса в стандарте.

Подсказка - именно в этом месте в твоих рассуждениях логическая ошибка.

Единственный однозначно определённый тип данных в стандарте - это бит. Все остальные типы являются implementation defined

Для strictly conformant программ этого не требуется. В Annex E описаны минимальные размеры, ориентироваться нужно на них.

Найди доказательство этого тезиса в стандарте.

Вот:

5A strictly conforming program … and shall not exceed any minimum implementation limit

5.2.4.2.1 Sizes of integer types

программа не удовлетворяет условию в твоём понимании

Хорошо. Предлагаешь какое-то другое понимание или просто хочешь доказать, что переносимых программ на Си не существует?

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

Только это представление зависит от реализации. А равенство вывода трактуется именно как равенство объектов языка (символов при вводе/выводе) и чисел при передаче через аргументы и результат.

Предлагаешь какое-то другое понимание

Я предлагаю однозначно определится с пониманием "It shall not produce output dependent " либо как двоично идентичным для любой «strictly conforming program», либо же однозначно признать, что вывод «strictly conforming program» может быть не идентичным.

Вот: and shall not exceed any minimum implementation limit

Тебе осталось сделать последний логический шаг - осознать это высказывание и термин «implementation limit», где слово «implementation» имеет решающее значение.

Коан в помощь для медитации - является ли strictly conforming следующая program:

#include <stdio.h>
#include <limits.h>

int main(void)
{
    (void) printf("%d\n", INT_MAX);
    return 0;
}

Коан в помощь для медитации - является ли strictly conforming следующая program:

Нет. Потому что надо читать весь термин, а не последние два слова. Minimum implementation limit описан в Стандарте и INT_MAX не может быть меньше, но, очевидно, может быть больше.

А равенство вывода трактуется именно как равенство объектов языка

Или докажи это текстом из стандарта, или тебе придётся отказаться от этого (выдуманного тобой) тезиса.

Нет.

Почему?

INT_MAX не может быть меньше, но, очевидно, может быть больше.

Да, может. А где тут какое-либо нарушение стандарта-то?

Или докажи это текстом из стандарта, или тебе придётся отказаться от этого (выдуманного тобой) тезиса.

В тексте вообще понятия равенства нет. Есть понятие зависимости. return 0; не зависит от «any unspecified, undefined, or implementation-defined behavior» и 0 не превышает «minimum implementation limit» для int.

Стандарта — нет. Возможное implementation-defined превышение minimum implementation limit очевидно присутствует. Поэтому программа не strictly conforming.

Даже без превышения. Значение INT_MAX само по себе является результатом implementation-defined behavior. Поэтому его вывод не strictly conforming program.

Да, может. А где тут какое-либо нарушение стандарта-то?

Тут есть нарушение вот этого параграфа:

A strictly conforming program shall use only those features of the language and library specified in this document. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.

Minimum implementation limit для int это 16 бит (в Annex E). Если у тебя int 32 бит, ты превысил и твоя программа перестала быть strictly conforming.

В ту же степь с fopen: у тебя есть FOPEN_MAX, который объявлен stdio.h и чему-то равен. Однако, стандарт говорит что минимальное значение – 8. Если логика работы твоей программы подразумевает 12 открытых файлов, твоя программа уже не strictly conforming, даже если FOPEN_MAX на твоей платформе такое позволяет.

Тут есть нарушение вот этого параграфа:
shall not exceed any minimum implementation limit.
Minimum implementation limit для int это 16 бит (в Annex E).

Вернулся с каникул обратно в шкалку? Жаль, что учебный год начался с того, что ты обосрался не снимая штанов потому что не смог прочитать Annex E, на который ты же ссылаешься, где написано:

The minimum magnitudes shown shall be replaced by implementation-defined magnitudes with the same sign. … The components are described further in 5.2.4.2.1.

И именно implementation-defined magnitudes не должны быть exceed, а 5.2.4.2.1 говорит нам:

5.2.4.2.1 Sizes of integer types <limits.h>

The values given below shall be replaced by constant expressions … Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

Тебе пока рановато участвовать в таких срачах, лучше сделай домашку.

Возможное implementation-defined превышение minimum implementation limit очевидно присутствует.

Смотри ответ школьнику выше.

Вот тут ты близок

INT_MAX само по себе является результатом implementation-defined behavior.

Верно.

Поэтому его вывод не strictly conforming program.

Не верно. Помедитируй вот над этим коаном:

int main(void)
{
    int a = +32767;
    int b = a + 1;
    return 0;
}

Является ли эта программа strictly conforming?

Является ли эта программа strictly conforming?

Нет. В ней даже возможный UB.

The minimum magnitudes shown shall be replaced by implementation-defined magnitudes with the same sign

Эти значения являются minimum magnitudes. В программе они будут заменены implementation-defined magnitudes. Но эти implementation-defined magnitudes не становятся от этого minimum magnitudes. И там, где сравнение с minimum implementation limit сравнивается именно с minimum magnitudes, а не с implementation-defined magnitudes конкретной implementation.

P. S. Чем дальше, тем больше это напоминает философский спор с софистом. Надо отловить все попытки подмены смысла и явно их подчеркнуть.

Чем дальше, тем больше это напоминает философский спор с софистом

Со стороны это также выглядит. Вы тут ничего никому не докажите. Людям пофиг на истину, люди ищут самоутверждения.

Ты не ту часть предложения выделил:

The minimum magnitudes shown shall be replaced by implementation-defined magnitudes

Видишь слово minimum? Ингриш, мазафака, да ю спик ит?

А то, что дальше цитируешь, отношение к strict conformity не имеет. Это про то что лимиты должны быть больше минимальных значений.

Является ли эта программа strictly conforming?

Нет. В ней даже возможный UB.

Обоснуй это формально.

Завтра разберём детальнее, где ошибка в твоих рассуждениях.

Обоснуй это формально.

32767 + 1 выходит за INT_MAX на платформах с sizeof(int) == 2. У тебя потенциальный signed overflow в коде, чучело.

С ним так удобно писать фронт для Domain Specific Language, а back уже есть.

Можно «переносимый ассемблер» AKA C использовать как back.

Завтра разберём детальнее, где ошибка в твоих рассуждениях.

Нам всем очень-очень интересно!

Ждём.

Ждем чего? Я тебе уже обосновал это формально – на 16 битной платформе у тебя signed overflow и это UB. В программе на языке C UB быть не может. Так что твоя программа не то что strictly conforming, она вообще не программа на языке C.

И прежде чем ты начнешь клоунаду в духе «ололо это значение даже не используется», то вот тебе простой пример UB, которое произойдет: твоя программа тупо не соберется с -Werror :DDD

Более того, я даже могу придумать реальный пример как это поделие сломается в реальной жизни. Потому что у нас есть программа, которая всегда возвращает 0… и это true!

А теперь давай посмотрим что будет, с поправкой на размер типа для x86_64:

$ cat true.c
int main(void)
{
    int a = +2147483647;
    int b = a + 1;
    return 0;
}
$ gcc -ftrapv -o true true.c
$ ./true
IOT instruction (core dumped)  ./true
$ echo $?
134

Ты все-таки умудрился написать программу, которая выдает разные значения на разных платформах, не делая буквально ничего. Браво, йопт. Это как самый маленький рассказ Хемингуэя, только от мира неспособных осилить сишный стандарт.

Ждем чего?

У тебя не работает переход по ссылке на лоре? Не чего, а кого.