1. Forum
  2. Fidonet
  3. COMP.LANG.C

  • Re: NULL dereference in embedded [was: On Undefined Behavior]

    From Lawrence D?Oliveiro@3:633/10 to All on Tue Jan 6 21:59:56 2026
    On Tue, 6 Jan 2026 13:08:57 -0000 (UTC), Waldek Hebisch wrote:

    Putting volatile qualifier on p gives working code, but apparently
    disables optimization. Also, this looks fragile. So if I needed
    to access address 0 I probably would use assembly routine to do this.

    Seems to be a fundamental C language limitation, wouldn?t you say?

    --- PyGate Linux v1.5.2
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Andrey Tarasevich@3:633/10 to All on Wed Jan 7 20:48:03 2026
    On Tue 1/6/2026 5:08 AM, Waldek Hebisch wrote:

    I get the following assembly:

    00000000 <read_at0>:
    0: b108 cbz r0, 6 <read_at0+0x6>
    2: 2000 movs r0, #0
    4: 4770 bx lr
    6: 6803 ldr r3, [r0, #0]
    8: deff udf #255 @ 0xff
    a: bf00 nop

    So compiler generates actiual access, but then, instead of returning
    the value it executes undefined opcode. Without test for null
    pointer I get simple access to memory.


    When it comes to invalid (or missing, in C++) `return` statements, GCC
    tends to adhere to a "punitive" approach in optimized code - it injects instructions to deliberately cause a crash/segfault in such cases.

    Clang on the other hand tends to stick to the uniform approach based on
    the "UB cannot happen" methodology, i.e. your code sample would be
    translated under "p is never null" assumption, and the function will
    fold into a simple unconditional `return 0`.

    --
    Best regards,
    Andrey

    --- PyGate Linux v1.5.2
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lawrence D?Oliveiro@3:633/10 to All on Thu Jan 8 23:56:16 2026
    On Wed, 7 Jan 2026 20:48:03 -0800, Andrey Tarasevich wrote:

    When it comes to invalid (or missing, in C++) `return` statements,
    GCC tends to adhere to a "punitive" approach in optimized code - it
    injects instructions to deliberately cause a crash/segfault in such
    cases.

    Clang on the other hand tends to stick to the uniform approach based
    on the "UB cannot happen" methodology, i.e. your code sample would
    be translated under "p is never null" assumption, and the function
    will fold into a simple unconditional `return 0`.

    Which one is more likely to lead to unexpected, hard-to-debug results?

    --- PyGate Linux v1.5.2
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)