В первоисточнике — не слова о clang'е, и вряд ли есть хоть слово о платформах.
Если вы продолжите знакомиться с первоисточником, то вы возможно узнаете, что в нём всё-таки что-то сказано о платформах. В частности, что наличие или отсутствие trap value определяется реализацией(за некоторым исключением гарантий его отсутствия). Дальше, возможно, сможете это сложить с тем, как это относится к clang и наличию или отсутствию у него trap value для bool.
"If an indeterminate value is produced by an evaluation, the behavior is undefined".
В рассматриваемом коде нет получения indeterminate значения через evaluation
Не бывает условных эквивалентов первоисточника, и приведённое вами пережёвывание не исключение, тем более, что код С, а не С++, что бывает важно в ряде случаев.
Тем не менее, для данного случая и первоисточнике(черновике) указано не про unspecified value, как это мне запомнилось, а indeterminated value, то есть, unspecified or trap value. Только обращение к последнему и является неопределённым поведением. Однако clang для большинства платформ не определяет никакого trap value для целых, к каким относится и bool. Более того, само по себе обращение к неинициализированным переменным не детектируется при -fsanitize=undefined, что хотя бы и как-то, но говорит об отношении самих разработчиков компилятора к наличию trap value, а уж проверить его для bool было проще простого. Остаётся только unspecified value, которое не позволяет с ним вести себя как угодно.
С точки зрения определения языка здесь нет неопределённого поведения. В неинициализированной локальной переменной значение не специфицированно, что всего лишь означает, что в ней, пусть и неизвестное, но одно из легальных значений, что для bool это true или false. Если компилятор получил что-то ещё, да ещё и в своих же преобразованиях, то это полностью его проблема. В этом примере для правильного воплощения компилятора было допустимо выводить либо "true", либо "false" в любом варианте, но не вычислять длину строки как попало.
Возможно, Серёжа писал говнокод, а может и нет. Возможно, что остальные программисты писали правильный код, а может оказаться, что они тоже писали говнокод, просто по другому. Сомневаться приходится потому, что люди часто путают говнокод и то, что можно было бы назвать быстрокодом, и упускают из виду, что отборнейший говнокод как раз может быть очень тщательно спроектирован. Хорошим примером, в шутку доведённым до абсурда, является fizbuzz enterprise edition. Такие примеры, пусть и менее абсурдные встречаются в жизни довольно часто, и печально, что у многих складывается впечатление, что так и надо, и поэтому здесь "всё надо переписать", опять, потому что вот теперь всё точно будет масштабируемо без костылей.
Потому что у []что-то и []interface{} разные операции чтения и записи, а запись в приведённый []interface{}, если бы это приведение было возможно, приводила бы к записи элемента interface{} туда, где ожидается элемент что-то. Go это не Dart-2 с псевдо-статической типизацией, что и проявляется в таких нюансах
Какой смысл в Вашем рефакторинге, который не решает задач рефакторинга? Как в анекдоте — зато дёшево ж?
Вы говорите, что терминологический спор Вас не интересует, но, по факту, этот диалог в значительной степени вокруг этого и строится. Типичный парсер для многих языков требует для своей работы анализа объявлений и нет никакого смысла выкидывать эту часть для того, чтобы сделать это потом в отдельном семантическом анализаторе.
Если вы продолжите знакомиться с первоисточником, то вы возможно узнаете, что в нём всё-таки что-то сказано о платформах. В частности, что наличие или отсутствие trap value определяется реализацией(за некоторым исключением гарантий его отсутствия). Дальше, возможно, сможете это сложить с тем, как это относится к clang и наличию или отсутствию у него trap value для bool.
В рассматриваемом коде нет получения indeterminate значения через evaluation
Не бывает условных эквивалентов первоисточника, и приведённое вами пережёвывание не исключение, тем более, что код С, а не С++, что бывает важно в ряде случаев.
Тем не менее, для данного случая и первоисточнике(черновике) указано не про unspecified value, как это мне запомнилось, а indeterminated value, то есть, unspecified or trap value. Только обращение к последнему и является неопределённым поведением. Однако clang для большинства платформ не определяет никакого trap value для целых, к каким относится и bool. Более того, само по себе обращение к неинициализированным переменным не детектируется при -fsanitize=undefined, что хотя бы и как-то, но говорит об отношении самих разработчиков компилятора к наличию trap value, а уж проверить его для bool было проще простого. Остаётся только unspecified value, которое не позволяет с ним вести себя как угодно.
С точки зрения определения языка здесь нет неопределённого поведения. В неинициализированной локальной переменной значение не специфицированно, что всего лишь означает, что в ней, пусть и неизвестное, но одно из легальных значений, что для bool это true или false. Если компилятор получил что-то ещё, да ещё и в своих же преобразованиях, то это полностью его проблема. В этом примере для правильного воплощения компилятора было допустимо выводить либо "true", либо "false" в любом варианте, но не вычислять длину строки как попало.
По-хорошему бы
Возможно, Серёжа писал говнокод, а может и нет. Возможно, что остальные программисты писали правильный код, а может оказаться, что они тоже писали говнокод, просто по другому. Сомневаться приходится потому, что люди часто путают говнокод и то, что можно было бы назвать быстрокодом, и упускают из виду, что отборнейший говнокод как раз может быть очень тщательно спроектирован. Хорошим примером, в шутку доведённым до абсурда, является fizbuzz enterprise edition. Такие примеры, пусть и менее абсурдные встречаются в жизни довольно часто, и печально, что у многих складывается впечатление, что так и надо, и поэтому здесь "всё надо переписать", опять, потому что вот теперь всё точно будет масштабируемо без костылей.
Потому что у []что-то и []interface{} разные операции чтения и записи, а запись в приведённый []interface{}, если бы это приведение было возможно, приводила бы к записи элемента interface{} туда, где ожидается элемент что-то. Go это не Dart-2 с псевдо-статической типизацией, что и проявляется в таких нюансах
Крайне неудачный переводческий ляп - модальность. Ближе было бы режимность, если хотелось передать одним словом.
Подозреваю, что Вы уже нашли на чём, так как теперь работает сносно, а в первый раз ломалось почти на всём
Попробовал, но он ломается даже в зависимости от переводов строк. Толком ничего не могу получить. В лучшем случае выдаёт XML же, но испорченный
И «undexpected» — это ошибка в выводе ошибок :)
Какой смысл в Вашем рефакторинге, который не решает задач рефакторинга? Как в анекдоте — зато дёшево ж?
Вы говорите, что терминологический спор Вас не интересует, но, по факту, этот диалог в значительной степени вокруг этого и строится. Типичный парсер для многих языков требует для своей работы анализа объявлений и нет никакого смысла выкидывать эту часть для того, чтобы сделать это потом в отдельном семантическом анализаторе.
И судя по средней заплюсованности его статей, включая ту, на которую ссылался mwizard — нет, не достал :)