не литерал, а константа

В одной реализации NULL это 0L.

я почитал саму работу, и должен сказать, что вы правы. если обобщать, теперь стандарт делает вид, что по указателям, которые возвращаются из malloc и прочих, возвращаются объекты, для создания и уничтожения которых не нужно выполнять никакого кода

оно действительно выглядит как острый угол, но чтобы проверить поведение компиляторов, надо найти такой lifetime-implicit тип на такой платформе, чтобы nullptr не был нулем

Буквальное следование стандарту заставляет вместо программирования, придумывать почему что-то делать нельзя
хотя все делают

Это называется "написание кросс-платформенного/кросс-компиляторного кода". Раньше невежественные личности использовали volatile для атомарности, потому что в каком то компиляторе на какой то платформе это могло давать работающую программу. И таких реально много было (даже щас иногда залетают)

разве был когда volatile атомарным?
на популярных платформах не припомню

Если прибить гвоздями версию компилятора и таргет платформу, то конечно можно любую дичь творить

в msvc он вроде до сих пор какие то особые барьеры вставляет

нет там барьеров. Смысл вполне определенный: что между 2-мя обращениями переменная может измениться
это не гарантирует атомарность на x86

По дефолту вроде до сих пор atomic: https://docs.microsoft.com/en-us/cpp/cpp/volatile-cpp?view=vs-2019

Я про это:

When the /volatile:ms compiler option is used—by default when architectures other than ARM are targeted—the compiler generates extra code to maintain ordering among references to volatile objects in addition to maintaining ordering to references to other global objects. In particular:

A write to a volatile object (also known as volatile write) has Release semantics; that is, a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

A read of a volatile object (also known as volatile read) has Acquire semantics; that is, a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

This enables volatile objects to be used for memory locks and releases in multithreaded applications.

да барьеры есть на не-x86 архитектурах, (в x86 они аппратные)
но этого не достаточно для семантики atomic
другое дело что любой atomic Должен быть volatile

наоборот - по дефолту на x86 генерится доп код, который делает atomic семантику, а на ARM по дефолту используется ISO семантика volatile (то есть спец. память)

ну вот я только что проверил:

volatile int x;

void Foo() {
  ++x;
}

на Asm получилось:

  push  ebp
  mov  ebp, esp
; Line 4
  mov  eax, DWORD PTR ?x@@3HC      ; x
  add  eax, 1
  mov  DWORD PTR ?x@@3HC, eax      ; x
; Line 5
  pop  ebp
  ret  0

нету тут LOCK для atomic семантики

не видел ни одного компилятора где бы volatile были atomic

вы описали лишь частный случай. суть в другом

суть volatile в поддержке определенной семантики memory model

volatile int x;

void Foo() {
  ++x;
}

  push  ebp
  mov  ebp, esp
; Line 4
  mov  eax, DWORD PTR ?x@@3HC      ; x
  add  eax, 1
  mov  DWORD PTR ?x@@3HC, eax      ; x
; Line 5
  pop  ebp
  ret  0

Если компилить под ARM и выставить volatile:ms, то будут иснструкции
dmb         ish

В ARM не шарю, но гуглится это как memory барьер