Hacker News Reader

Comment by pdw | Hacker News Reader

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.

View on HN

> 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.

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

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.

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

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.

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?

Correct. (Although, the pointers being defined that way seems to make it quite unlikely that the compiler could optimize this incorrectly…)

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.

That's what [u]intptr_t is for.

Reply on news.ycombinator.com