4 ms·

Unfortunately, this technique is a bit problematic with modern C compilers. Because the `start` and `end` symbols are unrelated objects, as far as the compiler

by pdw 6y ago

Unfortunately, this technique is a bit problematic with modern C compilers. Because the `start` and `end` symbols are unrelated objects, as far as the compiler is concerned, the subtraction `&end - &start` to get the length of the data invokes undefined behavior. Just for that reason, I feel the include file with a hex dump is the better method.

ghostpepper 6y ago
Can you elaborate on this? Does "unrelated" have any special meaning in this context? Why is this operation undefined?
- saagarjha 6y ago
  In C, accessing data outside the bounds of an object is undefined (like, you can’t legally “go past the end” of an array and end up in some other object). The “start” and “end” pointers, as far as the compiler is concerned, are totally different objects, so it may optimize a loop from one pointer to the other out since it’s impossible to increment an address so it’ll go from pounding at one thing to another.
  - ghostpepper 6y ago
    So is the idea that just because the two objects happen to appear sequentially in memory under a certain implementation, the compiler (or linker in this case?) has no obligation to ensure that assumption holds?
    - saagarjha 6y ago
      Correct. (Although, the pointers being defined that way seems to make it quite unlikely that the compiler could optimize this incorrectly…)
  - 08-15 6y ago
    Where is data outside any object accessed? Note that forming a pointer just past the end of an object is well-defined; only dereferencing it isn't.
xurukefi 6y ago
To get the size you would use the `_binary_FILENAME_size` symbol that the linker puts into the object file.
RealityVoid 6y ago
Last time I checked in the Green Hills compiler I'm using you also have the option of using a symbol that contains the size.
08-15 6y ago
> Because the `start` and `end` symbols are unrelated objects That's irrelevant. What matters is whether they point to (or just past the end of) the same object, which they do.
ndesaulniers 6y ago
That's what [u]intptr_t is for.

by pdw 6y ago

ghostpepper 6y ago

Can you elaborate on this? Does "unrelated" have any special meaning in this context? Why is this operation undefined?

saagarjha 6y ago
In C, accessing data outside the bounds of an object is undefined (like, you can’t legally “go past the end” of an array and end up in some other object). The “start” and “end” pointers, as far as the compiler is concerned, are totally different objects, so it may optimize a loop from one pointer to the other out since it’s impossible to increment an address so it’ll go from pounding at one thing to another.
- ghostpepper 6y ago
  So is the idea that just because the two objects happen to appear sequentially in memory under a certain implementation, the compiler (or linker in this case?) has no obligation to ensure that assumption holds?
  - saagarjha 6y ago
    Correct. (Although, the pointers being defined that way seems to make it quite unlikely that the compiler could optimize this incorrectly…)
- 08-15 6y ago
  Where is data outside any object accessed? Note that forming a pointer just past the end of an object is well-defined; only dereferencing it isn't.

xurukefi 6y ago

To get the size you would use the `_binary_FILENAME_size` symbol that the linker puts into the object file.

RealityVoid 6y ago

Last time I checked in the Green Hills compiler I'm using you also have the option of using a symbol that contains the size.

08-15 6y ago

> Because the `start` and `end` symbols are unrelated objects That's irrelevant. What matters is whether they point to (or just past the end of) the same object, which they do.

ndesaulniers 6y ago

That's what [u]intptr_t is for.