Есть ли “тайные” (странные), но совместимые стандартами компиляторы C или время выполнения?

[115402]Hewlett Packard's HP-UX - это самое близкое, что я могу придумать.

stty -echo; ssh myUser@REMOTE_SERVER "sudo -v"; stty echo  
rsync -avze ssh --rsync-path='sudo rsync' myUser@REMOTE_SERVER:/REMOTE_PATH/ LOCAL_PATH 

Компилятор C разрешит разыменование NULL-интерфейса, хотя там был флаг, чтобы изменить это. Стек рос "вверх" (в сторону больших адресов), а куча - вниз (в сторону меньших адресов) на PA-RISC hardware

У PA-RISC hardware тоже были некоторые странности за пределами разворота стека/кучи. Оно имело сегментный регистр (работал не так, как x86 сегментов), так что различные библиотеки на самом деле жили в разных сегментах, а указатели на функции не были единичным 64-битным указателем. Однако я не помню, был ли PA-RISC настолько строг к выравниванию указателей, как SPARC.

На несколько более доступном уровне можно использовать компиляторы Си, такие как [115776]Clang[115777], [115778]Pcc[115779] или даже [115780]Tcc[115781], хотя у Tcc есть некоторые проблемы с компоновщиками и загрузчиками GNU из-за "слабых символов", как я понимаю. По крайней мере, вы получите различные предупреждения от этих альтернативных компиляторов, что всегда стоит того.

MultipleInvokePromptMinimum

Вы также можете попробовать альтернативные библиотеки C, такие как [115782]Diet Libc[115783] или [115784]Musl[115785]. В программах, скомпилированных против Musl, я делал разные вещи, в отличие от GNU Libc. Обе эти библиотеки поддерживают статическое связывание, которое GNU Libc делает трудным или невозможным. Musl даже имеет совершенно другую систему динамического компоновки, которая может выявить скрытые ошибки в вашем коде.[115411].

[115448] IBM Z Series работает под Linux, и это довольно странное чудовище. Не знаю, используют ли они до сих пор EBCDIC.[12135]The Crays имели [115822]все [115823] типы данных 32 бита (включая 'char').[12136]Вокруг есть компиляторы C для примерно 16-ти битных процессоров (я с удовольствием вспоминаю, например, Turbo C на ПК). Размер слова - одно из отличий, которое ждет вас в байтах...[12137]В своем блоге Джон Регер [115824]обсуждает[115825] инструменты для проверки того, что компиляторы не делают фанки. Он пишет несколько постов о неопределённом поведении и о том, как это позволяет (иногда удивительно) оптимизировать код. Также обсуждается неопределенное поведение "в дикой природе"...[115455].

[12138] Итак, существует ли вариант Unix или платформа, вдохновленная unix (или компилятор, если это в основном зависит от компилятора?), который является стандартным, но намеренно странным, чтобы создавать ошибки и указывать на неопределенное поведение и непредсказуемость?[12139]Нет[115829], потому что...[12140]Это вообще разумная вещь, чтобы попытаться и реализовать?[12141]... нет, если разумная вещь означает "инструмент, который кто-либо разумно хотел бы использовать". Но [115832]да[115833] в том смысле, что это то, чем уже является обычный компилятор Си. Они неизбежно позволяют потакать неопределенному поведению определенным (предсказуемым) способом. Например:[12142]не определено, потому что вы модифицировали [115834]i[115835] несколько раз между точками следования. Однако, почти наверняка данный компилятор будет каждый раз выдавать один и тот же результат. Конечно, это не будет документировано, потому что не стоит делать этого в первую очередь, но компилятор может знать и сказать, если вы спросите об этом.[12143]Положите это в файл и скомпилируйте его, [115836]gcc undefined.c[115837]. Никаких проблем. Теперь попробуйте с включенными предупреждениями, [115838]gcc -Wall -pendantic undefined.c[115839]:[12144]Вот так. Теперь, имея в виду, что компилятор будет выдавать здесь каждый раз один и тот же результат, вы можете решить использовать это для любых целей. Это значит, что компилятор не может "намеренно... выдавать ошибки", когда вы делаете что-то не так, если мы определяем "ошибку" как что-то, чего вы не хотели. Он не знает, что вы хотите, чтобы случилось, и не может. Следовательно, она не может намеренно выдавать результат, который вы не можете предсказать.[12145]Она, очевидно, может, однако, "указывать на неопределённое поведение".[12146]Если вы хотите что-то, что может пойти дальше компилятора в обнаружении ошибок, обратите внимание на [12147]valgrind[12148]. Есть и другие (возможно, очень дорогие) вещи, но это единственное, что я использовал.[12149]Приняв что-то, что вы разработали исключительно на 64-битной машине и скомпилировав и запустив его 32-битным способом, вы также можете обнаружить много фасептима -- но очевидно, что [115842]а не[115843] идеальный способ исправления ошибок. [12150] Наконец: дефакто способ проверить программное обеспечение - это проверить его. [115845] Вы пишете конкретные тесты [115846] по ходу, [115847] и прогоняете их снова и снова: в конце дня, всякий раз, когда вы добавляете новый кусочек, и т.д. [115848] Этому нет замены.[12151]