3 ms·

> To crash the application the code was accessing a NULL pointer. Alas, WebAssembly allowed read access to address Zero without problem. Good thing nothing in

by msla 6y ago

> To crash the application the code was accessing a NULL pointer. Alas, WebAssembly allowed read access to address Zero without problem. Good thing nothing in the C or C++ standards mandates NULL be address all-bits-zero regardless of how it's sometimes spelled. Any compiler which assumes that memory access to address all-bits-zero is access to NULL is not compliant.

PaulDavisThe1st 6y ago
Since C++11, the definition of NULL is: an integer literal with value zero, or a prvalue of type std::nullptr_t See https://wg21.cmeerw.net/cwg/issue903 https://wg21.cmeerw.net/cwg/issue903 for a case where NULL was did not evaluate to zero.
- AlotOfReading 6y ago
  The best part of C++ is how even the caveats get caveats. The fun never ends for rules lawyers.
- wolfgang42 6y ago
  I thought “integer literal zero (in pointer contexts)” was the definition of NULL in all versions of C. As I understand it the resulting pointer doesn’t necessarily have to have a value of 0 (even though that’s what it says in the source code) so long as it behaves appropriately nullish—i.e. the compiler can translate “int *foo = 0;” as “MOV foo 0xDEADCODE” so long as that value won’t be used for any legitimate pointer.
  - msla 6y ago
    The above-linked site about POSIX has this paragraph: https://www.austingroupbugs.net/view.php?id=940 https://www.austingroupbugs.net/view.php?id=940 > The C standard goes to great length to ensure that NULL (and for that matter, any representation of the null pointer, which is written in source code by converting a constant value 0 to a pointer) need not be represented in hardware by all 0 bits (that is, 'int p = 0;' or 'static int p;' is allowed to compile to assembly instructions that assign a non-zero bit pattern to the location named p). And in fact, there are historical machines where the most efficient null pointer in hardware was indeed a non-zero bit pattern: http://c-faq.com/null/machexamp.html http://c-faq.com/null/machexamp.html ... and the site it links to has this: > Q: Seriously, have any actual machines really used nonzero null pointers, or different representations for pointers to different types? > A: The Prime 50 series used segment 07777, offset 0 for the null pointer, at least for PL/I. Later models used segment 0, offset 0 for null pointers in C, necessitating new instructions such as TCNP (Test C Null Pointer), evidently as a sop to [footnote] all the extant poorly-written C code which made incorrect assumptions. Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char 's) than word pointers (int 's). [snip] > The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair <NIL, 0> (basically a nonexistent <object, offset> handle) as a C null pointer.
deleted 6y ago
[deleted]
cesarb 6y ago
AFAIK, the POSIX standard mandates that all-bits-zero be treated as NULL (https://www.austingroupbugs.net/view.php?id=940 https://www.austingroupbugs.net/view.php?id=940).

by msla 6y ago

PaulDavisThe1st 6y ago

Since C++11, the definition of NULL is: an integer literal with value zero, or a prvalue of type std::nullptr_t See https://wg21.cmeerw.net/cwg/issue903 https://wg21.cmeerw.net/cwg/issue903 for a case where NULL was did not evaluate to zero.

AlotOfReading 6y ago
The best part of C++ is how even the caveats get caveats. The fun never ends for rules lawyers.
wolfgang42 6y ago
I thought “integer literal zero (in pointer contexts)” was the definition of NULL in all versions of C. As I understand it the resulting pointer doesn’t necessarily have to have a value of 0 (even though that’s what it says in the source code) so long as it behaves appropriately nullish—i.e. the compiler can translate “int *foo = 0;” as “MOV foo 0xDEADCODE” so long as that value won’t be used for any legitimate pointer.
- msla 6y ago
  The above-linked site about POSIX has this paragraph: https://www.austingroupbugs.net/view.php?id=940 https://www.austingroupbugs.net/view.php?id=940 > The C standard goes to great length to ensure that NULL (and for that matter, any representation of the null pointer, which is written in source code by converting a constant value 0 to a pointer) need not be represented in hardware by all 0 bits (that is, 'int p = 0;' or 'static int p;' is allowed to compile to assembly instructions that assign a non-zero bit pattern to the location named p). And in fact, there are historical machines where the most efficient null pointer in hardware was indeed a non-zero bit pattern: http://c-faq.com/null/machexamp.html http://c-faq.com/null/machexamp.html ... and the site it links to has this: > Q: Seriously, have any actual machines really used nonzero null pointers, or different representations for pointers to different types? > A: The Prime 50 series used segment 07777, offset 0 for the null pointer, at least for PL/I. Later models used segment 0, offset 0 for null pointers in C, necessitating new instructions such as TCNP (Test C Null Pointer), evidently as a sop to [footnote] all the extant poorly-written C code which made incorrect assumptions. Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char 's) than word pointers (int 's). [snip] > The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair <NIL, 0> (basically a nonexistent <object, offset> handle) as a C null pointer.

deleted 6y ago

[deleted]

cesarb 6y ago

AFAIK, the POSIX standard mandates that all-bits-zero be treated as NULL (https://www.austingroupbugs.net/view.php?id=940 https://www.austingroupbugs.net/view.php?id=940).