Это мир не языка Си, а мир Стандарта, которого изначально не было и всё прекрасно компилировалось в соответствии с языковыми конструкциями. Комитет пошёл на поводу у каких-то хмырей далёких от программирования и превратил низкоуровневый Си в высокоуровневый Си-хрен-пойми-что, на котором нормально даже драйвер не написать, если следовать современным стандартам. Так что компилятор обязан, а иначе будет заменён на тот, который при виде УБ не будет вырезать кусками код, нарушая структурную целостность программы, да так, что программный счётчик попадает в функцию, которую не вызывали!
Ну в системе без накопителя для пользовательских данных и не будет следов. Перезагрузил и всё с нуля, ни вредоноса, ни его следов, ни вреда для системы.
Ха. Вы, надеюсь в курсе (выше вон уже был приведен параграф из стандарта), что в случае, если вы допустите UB в одном месте, то компилятор может сгенерировать сломанный код не только в этом месте, но в и абсолютно любом другом месте программы, и даже когда ваш код с UB вообще никогда не используется?
То есть вы серьёзно считаете такое неадекватное поведение компилятора приемлемым... Дожили...
Если язык мне разрешает делать такие базовые вещи, при этом стандарт компиляции берет кардбланш на дичь, то тут что-то не так со стандартом, т.к. с языком всё норм последние 50 лет.
Если завтра комитет объявит УБ вообще всё, то компилятор можно будет сократить до генератора случайного кода!
Вместо железа в памяти у вас значения в памяти... Какая разница в плане чтения из адреса? Можете через void* привести к float*. Страшно? Прочитали два двухбайтовых регистра, и теперь вам надо перевести их в float? Пихните прочитанные двухбайтовые значения в 4х байтовую переменную с учетом endianess (тут прям открывается свобода для программиста) и кастаните к float через reinterpret_cast. Фактически, вы говорите компилятору, что хотите работать с этими четырьмя байтами в памяти как с типом float. С чего вдруг УБ нарисуется?
Мне не стандарт надо знать до мелочей, а целевую платформу. Если уж Си компилятор будет упрямиться, то получит ассемблерную вставку и делов.
Регистры четырехбайтовые, то есть uint32_t, но конкретно в некоторых регистрах в памяти того внешнего устройства лежат float, и вам нужно работать с ним как с float.
Будем считать, что они у вас отображены на память и адрес вы знаете, например uint64_t addr = 0x0e55eeff8f4;
float* pf = (float*)addr; - вот указатель на ваш регистр как на float, даже memcpy не нужен.
компилятор имеет полное право сотворить в генерируемом бинарнике любую дичь даже там, где вы эти указатели не используете
вот не нужен мне такой компилятор, мне нужна предсказуемость, а не дичь.
Ну вот дичь же! Это же точно из серии "смотри как я могу". Можно еще через двойную косвенную адресацию провернуть финт. Но нафига?!
преобразование i = (long)y; разве не покатит чтобы разместить значение в переменной большей разрядности?
Я пишу платформозависимый код, знаю сколько байт мне надо и спокойно пользуюсь типами uint32_t, int64_t и иже с ними.
И зачем вообще заигрывать с адресацией *&var без причины? Байты в слове попереставлять красиво?
Если компилятор заменит проверку if ((X+n) > X) на if (true), то это конечно плохо, лучше бы подставил полный код, хотя я подсчет бы вынес в отдельное выражение и сравнивал уже результаты. Не люблю нагромождения в условиях ветвления.
UPD: хотя, постойте, i = (long)y; не покатит. Вы же хотите IEEE 754 float побайтово с мантиссой, экспонентой и всем знаками переместить в long. Но и тут вопрос, а что дальше то? Руками будете парсить, CRC считать? Тогда лучше читать память через memcpy и sizeof.
Ну так это если вы сами УБ запрограммировали, то и получаете неопределённое. Тут вообще без вопросов! А вот если программировать правильно, то никакого левого поведения не предполагается.
B&R любит С. Да и всякие PC-based тоже. Но при наличии культуры кода, руководств, правильных ограничений и отсутствия всяких "смотри как я могу", получается легко читаемый структурированный код.
Чтобы два кота в одну нору одновременно залезали очень маловероятно, не любят они такого. Но даже если и так, то два разных считывания засчитываются за отказ в обслуживании.
А можно просто током е*шить неправильного кота, чёуж тут...
Клетки для кормления! Клетка с предбанником, в котором кот только вдоль помещается и может выходить только задним ходом. Еда отделена механизмом с электроприводом. Кот в ошейникe с rfid. В предбаннике считыватель хоть размером с кота. Пока правильный кот не зайдёт, еда не откроется.
Это мир не языка Си, а мир Стандарта, которого изначально не было и всё прекрасно компилировалось в соответствии с языковыми конструкциями. Комитет пошёл на поводу у каких-то хмырей далёких от программирования и превратил низкоуровневый Си в высокоуровневый Си-хрен-пойми-что, на котором нормально даже драйвер не написать, если следовать современным стандартам. Так что компилятор обязан, а иначе будет заменён на тот, который при виде УБ не будет вырезать кусками код, нарушая структурную целостность программы, да так, что программный счётчик попадает в функцию, которую не вызывали!
Конечно! Просто в список изъятия попал комп, поврежденный скачанным вредоносом. А такое уже можно натянуть.
Ну в системе без накопителя для пользовательских данных и не будет следов. Перезагрузил и всё с нуля, ни вредоноса, ни его следов, ни вреда для системы.
ОЗУ? Да ну нафиг! Ну изъяли бы электронное вычислительное средство, вынули бы планки ОЗУ, отправили на экспертизу и... ничего бы не нашли!
Не, код там по ходу в консоли результат и вывел. Выглядит как консоль.
То есть вы серьёзно считаете такое неадекватное поведение компилятора приемлемым... Дожили...
Если язык мне разрешает делать такие базовые вещи, при этом стандарт компиляции берет кардбланш на дичь, то тут что-то не так со стандартом, т.к. с языком всё норм последние 50 лет.
Если завтра комитет объявит УБ вообще всё, то компилятор можно будет сократить до генератора случайного кода!
Вместо железа в памяти у вас значения в памяти... Какая разница в плане чтения из адреса? Можете через void* привести к float*. Страшно? Прочитали два двухбайтовых регистра, и теперь вам надо перевести их в float? Пихните прочитанные двухбайтовые значения в 4х байтовую переменную с учетом endianess (тут прям открывается свобода для программиста) и кастаните к float через reinterpret_cast. Фактически, вы говорите компилятору, что хотите работать с этими четырьмя байтами в памяти как с типом float. С чего вдруг УБ нарисуется?
Мне не стандарт надо знать до мелочей, а целевую платформу. Если уж Си компилятор будет упрямиться, то получит ассемблерную вставку и делов.
Будем считать, что они у вас отображены на память и адрес вы знаете, например uint64_t addr = 0x0e55eeff8f4;
float* pf = (float*)addr; - вот указатель на ваш регистр как на float, даже memcpy не нужен.
вот не нужен мне такой компилятор, мне нужна предсказуемость, а не дичь.
foreach (var i in array) Console.WriteLine(i ^ 0x02);
Ну вот дичь же! Это же точно из серии "смотри как я могу". Можно еще через двойную косвенную адресацию провернуть финт. Но нафига?!
преобразование i = (long)y; разве не покатит чтобы разместить значение в переменной большей разрядности?Я пишу платформозависимый код, знаю сколько байт мне надо и спокойно пользуюсь типами uint32_t, int64_t и иже с ними.
И зачем вообще заигрывать с адресацией *&var без причины? Байты в слове попереставлять красиво?
Если компилятор заменит проверку if ((X+n) > X) на if (true), то это конечно плохо, лучше бы подставил полный код, хотя я подсчет бы вынес в отдельное выражение и сравнивал уже результаты. Не люблю нагромождения в условиях ветвления.
UPD: хотя, постойте,
i = (long)y;не покатит. Вы же хотите IEEE 754 float побайтово с мантиссой, экспонентой и всем знаками переместить в long. Но и тут вопрос, а что дальше то? Руками будете парсить, CRC считать? Тогда лучше читать память через memcpy и sizeof.Например?
Конечно из-за оптимизаций! Программист пишет без указателей, мусор не создаёт, память выделяет при старте, границы проверяет.
Ну так это если вы сами УБ запрограммировали, то и получаете неопределённое. Тут вообще без вопросов! А вот если программировать правильно, то никакого левого поведения не предполагается.
А покажите параграф в стандарте где должно выполняться что-то иное в противовес к директивам программы?
B&R любит С. Да и всякие PC-based тоже. Но при наличии культуры кода, руководств, правильных ограничений и отсутствия всяких "смотри как я могу", получается легко читаемый структурированный код.
Ну вот я пишу без оптимизации на C89 для промавтоматики и мне важно чтобы выполнялось всё как написано в коде. Как раз и медленно и безопасно!
Всё УБ от оптимизаций на предположениях. С отключением оптимизации будет выполняться то, что написано.
Чтобы два кота в одну нору одновременно залезали очень маловероятно, не любят они такого. Но даже если и так, то два разных считывания засчитываются за отказ в обслуживании.
С этим к Куклачову...
Клетки для кормления! Клетка с предбанником, в котором кот только вдоль помещается и может выходить только задним ходом. Еда отделена механизмом с электроприводом. Кот в ошейникe с rfid. В предбаннике считыватель хоть размером с кота. Пока правильный кот не зайдёт, еда не откроется.
УПД. Кот вышел, метка потеряна, еда закрылась.