Indexing into call stack - Undefined behaviour? - c

Question

So my friend had this rather, well, perverse idea on how to create a list inside of the call stack of a program. The idea being that if you can calculate the offset between the same stack variable within a recursive call, you can access an arbitrary element further up the call stack. It sounds confusing so I decided to implement it, and it works, but of course the alarm bells chime loudly:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
// Reads all of stdin and prints it in reverse order
void read(char* last)
{
char current;
if (last==NULL)
{
// null terminator
current = '\0';
read(&current);
}
else
{
int ip = getchar();
if (ip==EOF)
{
// end of stdin found, loop back over the stack to find all read characters
// Calculate offset between the stack frames
int offset = &current - last;
for (char* c = last; *c != '\0'; c -= offset)
{
printf("%c", *c);
}
}
else
{
current = (char) ip;
read(&current);
}
}
}
int main(int c, char* argv[])
{
read(NULL);
return 0;
}
The questions being:
Is this UB? If so, why?
Can something simular be used without UB?

Answer 1

Can something simular be used without UB?
Yes, you just need to build a linked list explicitly:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
struct chain {
struct chain *prev;
char ch;
}
// Reads all of stdin and prints it in reverse order
void read(struct chain *last)
{
int ip = getchar();
if (ip==EOF)
{
// end of stdin found, loop back over the stack to find all read characters
for (struct chain *p = last; p; p = p->prev) { {
printf("%c", p->ch);
}
}
else
{
struct chain current = { last, (char)ip };
read(&current);
}
}
int main(int c, char* argv[])
{
read(NULL);
return 0;
}
however, there is a good chance of a stack overflow...

Answer 2

Is this UB?
Yes.
If so, why?
Because it's accessing memory via unrelated handle. Generally, see pointer provenance n2263.
And because standard gives no guarantee that objects will be allocated adjacent to each other and consecutive in decreasing memory addresses. There is no guarantee that the value of c pointer is valid. Because there is no such guarantee, the behavior is not defined.
Can something simular be used without UB?
No.

Answer 3

Some implementations document in considerable detail how they will lay out stack frames, at least when invoked with certain options [which typically limit the kinds of optimizations the compiler would perform]. If such an implementation behaves in a manner consistent with its documentation, code which relies upon compilers behaving as documented will be non-portable, but may have correct defined behavior on compilers that behave as described. If the Standard doesn't require that an implementation document something, but the implementation does so anyway, the accuracy of such documentation would be a Quality of Implementation issue outside the Standard's jurisdiction. A conforming implementation would be free to document almost anything it likes, regardless of whether its behavior bears any relationship whatsoever to what it documents.
Note that the way the Standard is written, there are very few cases where anything an otherwise-conforming implementation could do with some particular non-contrived program would render it non-conforming. It would be literally impossible to write a program for which one could not contrive a low-quality-but-conforming implementation that would behave nonsensically when fed it [indeed, one could contrive a pair of such implementations such that no source text could be meaningfully processed by both of them].
I think it is reasonable to suggest that quality implementations should only specify that they will process certain constructs a certain way in cases where the Standard would impose no requirements if they will consistently process such constructs in that fashion even when the Standard wouldn't require them to do so. An implementation that documents that it will process something a certain way, but sometimes does something else, may be conforming but should nonetheless be recognized as being of inferior quality. While it may sometimes be useful or necessary for programmers to make concessions for poor-quality implementations, maintainers of such implementations should not regard such concessions as any kind of endorsement of their implementations' quality.
There are relatively few tasks that could be performed by exploiting detailed knowledge of stack frame layout that could not be done better in ways that don't rely upon such knowledge. Further, code which relies on stack frame layout is likely to run usefully only on a rather small fraction of implementations. Nonetheless, such constructs should be expected to work usefully on quality implementations that document their stack frame layouts in sufficient detail to specify everything the programmer needs.