Это с cpprefference паста. Получается, что по стандарту UB, но

многие реализации позволяют использовать std::less для сравнения указателей?

Даже лучше. Как уже написал, для встроенных операторов в отношении указателей сравнения гарантируют только partial-order, однако имплементации обязаны поддерживать некоторый согласованный с таким порядком неуточняемый total-order, который используется для библиотечных компараторов. Нужно для надежной ассоциативности в ситуациях, где указатели являются ключами ordered-контейнеров.

Да и если без формальностей вдуматься в суть того, что предлагает сделать автор кода, сразу видно, что это какая-то ересь: взять два объекта в памяти и стереть память между ними. Во первых не понятно для чего? Можно же просто нужные переменные инитить нулями или чем надо, Во-вторых, где гарантия что нужные переменные в памяти расположатся именно так, а не иначе?

Стикер

Почему ересь? Если это внешние символы линковщика все там правильно. вопрос что и как он их разместил, и выровнял. линковщик вам дает символ (не переменную) взяв адрес которого вы получите адрес расположения этого символа.

Писать между объектами это UB. То есть, ересь.

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

Тоже нельзя. Тоже UB.

Это означает, что вам нужен memset с О0, например, в отдельном файле. Или асм, как это сделано во многих embedded startup-файлах

Норм компиляторы типа gcc это разрешают. вот взять 12.3 прекрасно можно занулить секцию bss: /* Uninitialized data section */ .bss : { . = ALIGN(4); __bss_start = .; *(.bss*) *(COMMON) . = ALIGN(4); __bss_end = .; } > RAM_D2 extern uint32_t __bss_start, __bss_end, inline void __init_bss(uint32_t *bss_start, uint32_t *bss_stop) { while(bss_start != bss_stop) *bss_start++ = 0; } __init_bss(&__bss_start, &__bss_end); //zero fill bss section(zero vars) __libc_init_array(); //call static constructors

реализация компилятора и стандарт 2 разные вещи

Важнее вопрос наличия (или отсутствия) гарантий, на которые можно было бы положиться - хоть стандартных, хоть имплементационных. Либо да, post-build верификаторами какими-то пользоваться на те участки, по которым гарантий не было (при условии, что их вообще можно локализовать).

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

Стикер

Пишите ld файл правильно, а не как хочет левая нога.

Ага, ну то есть мы уже выходим за рамки C++. Сам по себе напрашивается вопрос, почему бы не написать этот код на ассемблере

Зачем вам ++, пишите весь код на асме, ломает меня писать даже мемкопи на асме, от слов совсем

Вы сейчас передёргиваете. Язык предоставляет абстракции, и порой они не вписываются в устройство конкретного исполнителя. Такова уж цена