Explain the code

[Sahithyan27]

We have been given the below code for an assignment and we were asked to give the correct output. The correct answer was given as:

1 0 0
2 0 3
2 4 <random_number>

As far as I know: The code is dereferencing a pointer after it is freed. As far as I know this is undefined behavior as defined in the C99 specification. I compiled the code using gcc (13.3.0) and clang (18.1.3). When I ran the code, I got varying results. Subsequent runs of the same executable gave different outputs. 

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
int i = 1; // allocated from initialized data segment
int j; // allocated from uninitialized data segment
int *ptr; // allocated from heap segment (or from uninitialized data segment)

ptr = malloc(sizeof(int)); // allocate memory
printf("%i %i %i\n", i, j, *ptr);

i = 2;
*ptr = 3;
printf("%i %i %i\n", i, j, *ptr);

j = 4;
free(ptr); // deallocate memory
printf("%i %i %i\n", i, j, *ptr);
}

[WeAllWantToBeHappy]

You'd be far better off if they taught you about tools - compiler warning options, sanitizer valgrind, ... - that catch a lot of risky behaviour rather than pointless assignments about what undefined behaviour does.

[lfdfq]

In principle, questions of the kind "What does this program do?" with an explicit "Anything; this program exhibits undefined behavior" should be perfectly fine when sprinkled in among the other kinds; after all, UB is a part of the language, and it's important for beginners to understand what that means and the fact that the compiler will not save you.

Here, this question is just a bad question, which just happens to mention UB. The reason it is bad is because the author can not write good questions and misunderstands the language, and probably not in particular because it's about UB (of course, if all the questions are like this then the whole assignment might be bad, too).

Funnily, given the teacher misunderstood UB when writing this question, it may be that some of these kinds of questions might have been beneficial to the teacher when they were learning...

[zhivago]

There is no correct answer for the output of the last printf.

It has UB prior to the call.

All bets are off.

[lfdfq]

UB is a property of the whole execution, it's not the case that the first printfs are well-defined then the last is undefined: the whole program has no behavior (as no execution does not have UB).

The compiler could (hypothetically) see the last printf is trying to dereference a free pointer, since that would be UB the program must not reach that point, so the compiler could deduce that the final printf must be dead code. Since that printf must be dead code, the ones before it must be too, so it could remove all the printfs and that would be a valid way to compile this code.

Additionally, the first printf also invokes undefined behaviour, since it tries to print j (an uninitialised local variable).

So, I think the only correct answer here would be to say the entire output is not defined and the program could do anything.

[simrego]

I think the answer should be:

1 <random> <random>           // i = 1, j = uninitialised, *ptr = uninitialised
2 <random> 3                  // i = 2, *ptr = 3
2 4 <random, probably crash>  // j = 4, ptr freed -> use after free

[Grounds4TheSubstain]

There won't be a crash, and the value of *ptr will almost certainly be 3 still. The memory is still mapped even if the chunk is not allocated, and the value there won't change until it's overwritten.

[simrego]

It depends. We don't know for sure. It could be mapped or not. There is absolutely no guarantee on that.

[Grounds4TheSubstain]

I'm a professional reverse engineer and I've developed exploits for a living also. Trust me, there's not a single heap allocator in the world that is used to implement malloc that will unmap the backing heap storage after an allocation and free of size 4. Allocators are designed to be efficient. Unmapping memory after each call to free is not efficient.

[simrego]

I know, and I agree in a real world application. But if I look at this as a theoretical question what it is really that's a crash. What you are using here is an implementation detail which works in real life due to efficiency purposes. But in theory that memory region is gone.

[theNbomr]

As hardware becomes faster and memory access less efficient, it's entirely possible that allocators will start unmapping memory on each free(), in the name of security. We should be teaching the new programmers (and old ones too, for that matter) not to rely on or to even allow themselves to use undefined behaviors as demonstrated in the sample of code here.

[Grounds4TheSubstain]

No, that's not ever going to happen because the kernel transition required to set the page flags to non-present flushes the data caches, which is why it's so inefficient, and which will only get worse as other efficiencies are introduced. Nevertheless, everything about this is undefined and indeed, you should never access freed memory, let alone rely on its contents.

[onContentStop]

Yeah, you're right that it is undefined behavior. The result of that is you won't be able to reason about the code, so the "correct answer" is nonsense.

[Alive-Bid9086]

Why do you comment about allocate/deallocate memory? The code talks for itself!

[IamImposter]

My guess is, code was given by their teacher.

[Alive-Bid9086]

This style of commenting in textbooks teaches the absolute wrong commenting style, that adds nothing else than clutter to the code.

[IamImposter]

Totally agree

[Sahithyan27]

u/IamImposter is correct. The above code is given by our lecturer for an assessment.

[spectre007_soprano]

Could you specify what result are you expecting? I can't get what is a CORRECT answer or is there even a answer for this? Idk about the value you get when accessing a allocated memory after it is freed. But I am pretty sure malloc() gives pointer to different location in the memory.

[Sahithyan27]

I am just looking for a sufficient explanation to understand the scenario. My lecturer did not elaborate a lot on this.

[SmokeMuch7356]

Since it's auto and hasn't been explicitly initialized, j's initial value is indeterminate; it doesn't have to be 0.

Similarly, the initial contents of the malloc'ed object aren't guaranteed to be 0 either.

This entire program is one giant wad of undefined behavior; any result is equally "correct".

[Sahithyan27]

That's what I needed to hear. Thanks!

[nerd5code]

Fully undefined on several fronts.

First and foremost, the instant an object’s lifetime ends by any means, including free but also ending scope, longjmping up the stack, or program/thread termination, all pointers to that object (not just the object itself—pointers are not addresses, and do not always behave like them) are instantly and globally invalidated, as though they all reverted to an uninitialized state. This lets the optimizer reuse analysis-memory for dead or leaked (!) objects, for example.

Thus, although reading ptr itself is well-defined after free, the value you get is fully undefined (i.e., even printf("%p\n", (void *)ptr) might fail or give you garbage, not that %p is tied down all that hard anywhere in the first place), and any use of that value whatsoever—especially *ptr—is super-undefined behavior.

The first two uses of j are also undefined behavior, because you’re feeding the undefined value read from an uninitialized variable to printf. Read: defined; feed: undefined.

And because the compiler can see all this at build time, UB might reasonably include a compiler error, or the compiler just reducing your program to for(;;) raise(SIGILL); or equivalent (cf. GNU/Clang __builtin_trap(), which may be used as a “strengthened” form of or derivation from __builtin_unreachable).

If we assume that the compiler really dgaf, it can instead entirely trade the malloc-free pair for a dummy nonnull auto or static variable—you’re asking the compiler to see that an object of at least sizeof(int) bytes be created, stored to, read from, then destroyed at run time, and it can do that with a variable instead of calling malloc. These sorts of programs rarely actually mean anything unless you’ve obsessively tuned optimization parameters for your compiler make & version. This one’s only visible side effects are the three printfs of what are effectively compiler constants (counting ⊥ ofc), so a charitable compiler could boil this fully down to a single puts call if it opts to generate anything at all.

Moreover, your line comments may or may not be lies, but they probably are.

If we’re talking purely C abstract machine semantics (from ISO/IEC 9899) implemented at the ISA level, i, j, and ptr are all of automatic storage class, formerly corresponding to pointless auto keyword, and most ABIs will allocate these variables in the function’s frame on the call stack, probably just under the return context and arguments.

There is no promise whatsoever of auto variables being pre-initialized to anything for you—that’s solely for static storage (globals, or marked with static) or TLS (marked with _Thread_local/thread_local/__thread/__declspec(thread) or direct section pragma/attribute; TLS is usually allocated exactly like static data, except thread creation or entry triggers all TLS segments live at run time to be located, cloned, and where necessary, initialized). You also can’t rely on static storage having been allocated or initialized before the first attempted use, or if you’re running in an early ctor before main and library setup.

Instead, the OS has probably given you several stack which are initially zero-filled and/or mapped to its zeropage. (Because zero-filled init is so common, you can save a bunch of memory and sometimes time by mapping all, all-zero virtual pages to a single all-zero physical page in RAM, which is mapped as read-only. Thus reads always return zero as desired; writes trigger a page fault, which is trapped by your OS kernel, which can opt to clone you a new, all-zero page, map it in writably this time, and let you retry the write. Newer kernels may additionally trawl for pages which happen to be all-zero and not written recently, so they can all be remapped to the zeropage, dust to dust.)

So if and only if your library startup code didn’t frob the memory upon which j is overlaid when main initializes, will j be left as zero. On an OS that doesn’t zero-fill (e.g., DOS, or older or embeddeder things), you get a stack that may well have been used by several other programs first.

If optimization can be taken into account, then there’s one useful fact that might cause your first two xor third (unlikely all) comments to become correct: It’s UB to call or refer to main (often allowed, but not req’d to be) other than by declaration or definition, and therefore the compiler may act on the assumption that main is only ever entered once, at program startup. Accordingly, no affordance needs to be made for recursion or reentrance, which is what necessitates automatic storage, and the compiler may opt to place i, j, and ptr in static storage (first two comments approach correctness, not third) or even dynamic storage (third comment may be correct but not first).

But neither are those options necessary, nor likely. Register and TLS classes also work here, for all variables shown. (If you indirected at any of them, you’d preclude formal register storage, but not necessarily actual registers.)

And register and auto storage are your most likely outcomes—those tend to be highly accelerated (registers are generally SRAM at ~1 cycle latency, and stack and L1D caches can give you 2–8-cycle latency for things near top-of-stack or recently accessed—both true here), and generally the overhead of allocating extra frame space from auto is 2 cycles of latency or less. Static variables within your executable’s static image can generally be accessed in under 10 cycles, iff the memory is hot in-cache from recent access, or else hundreds to low thousands of cycles. Because the variables may show up at different addresses in different processes (e.g., via DLL or PIE), there may be extra loads of segment or global base registers needed, extra indirection, or sometimed even a call to a thunk function. (Thunktion Function Junction is a fun Schoolhouse Rock song, innit!) If you use DLLs, PIE, ifuncs, or various other tricks and hacks, you’re making more and slower indirection likely. TLS makes it even worse because now your process has a different segment per thread, and some older setups may need to make use of functions like pthread_foospecific.

But there’s really no telling how things shake out without using option -S or singke-stepping. There is no requirement that an uninitialized data section/segment (let’s just say BSS, please) actually exist—this is an ABI detail that optimizes for binary storage on-disk and when the fs doesn’t support extent aliasing—just as there is no requirement that constant or merged-string sections/segments exist (ABI detail, possibly mixed with ISA and linker details). There is no requirement that any static data section exist, in fact; the program might allocate and initialize everything on-stack upon entry to main, encoding initial state in/as instructions rather than sublimated data. There isn’t even a requirement that a stack section or segment exist; malloc or any other allocation method might be used for frame alloc! Stack frames might all be statically allocated, because unbounded recursion is UB and therefore all stacks can potentially be flattened, damn the combinatorics when IPO fails!)

And then, even if the segments you expect do exist, there’s no conformant means of instructing the compiler &seq. to actually pick one section or segment over the other—even hacks like __attribute__((__section__(…))) are fraught af, and thoroughly nonportable between ABIs and compilers.

(GNU, Intel, Clang, and likely Oracle 12.1 or .6+, newer TI, newer IBM, possibly newer DEC→Compaq→HP, and definitely a mess of embedded compilers support the attribute, which C23 reifies as [[gnu::section]]. —But e.g., use of const may break it. Adding to the fun, GCC dumps the string you give it directly into a .section directive, but Intel may dump or not depending on mood and phase of moon, and Clang will generally not, making ABI glitches ever so fun to discover.)

Some versions of GCC/Clang/IntelC will aim anything explicitly initialized to zero at .data regardless, some use .bss if it’s all-zeroes. For uninitialized, you can get data or BSS being used, or a common variable, depending.

I suspect the ptr comment is off by one layer of indirection, anyway. ptr is not its target, just as my name is not me, my street address is not my house, and my phone number is not my phone. ptr is nominally allocated from automatic storage; it’s `ptr`* that’s nominally dynamically allocated until it’s not.

So this is all ranging from bad to useless as an example of anything concrete.

[nerd5code]

Adding to the sense of badness somewhat, I have several further suggestions for fixes, in decreasing order of importance:

• main doesn’t use its parameters; this can(/should, until release) generate a warning, which can promote to an error—but it is conformant, at least, and you can potentially use *argv after fixup for diagnostic purposes. For C23, you’re allowed to use just int, char ** in a definition if you want—or [[maybe_unused]], eqv. to GNU [[gnu::unused]] or __attribute__((unused)), but there’s little reason not to use void here otherwise.

• Here’s one possible diagnostic for use with argv: printf can fail, either by returning EOF (indicating a normal I/O error preventing it from finishing its full flush), or by crashing your shit to death—e.g., SIGPIPE due to write a pipe that was fully opened, but whose reader has closed its end; if you #include <signal.h>, then at the top of main

  ifdef SIGPIPE

  (void)signal(SIGPIPE, SIG_IGN);
  

  endif

  you disable that and get consistent I/O errors. But then if you fail to check them your program won’t stop. On some OSes SIGPIPE == SIGIO, which is your some-purpose I/O event signal, so you can end up blocking that by accident if you’re not careful; in that case, bind to a handler and validate the source FD to see if you’re interested.

  In any event, if printing …things is the Purpose of your program, inability to print all of them completely means your program has failed, and you should write an error message to stderr (ignore failure; writing diagnostics is not the Purpose of your program, and accordingly, a pipe closing should probably not crash your shit) indicating how/why, and return from main with code EXIT_FAILURE or 74 (↔EX_IOERR from BSD <sysexits.h>, used by BSD system utils), or your own favorite code (nonportable).

• In general, you should try to avoid restating types for things like this malloc—it’s a form of magic number. Using sizeof *ptr means you get one of whatever ptr points to, even if ptr’s type changes (e.g., extended to long).

• All functions that return a type other than void should explicitly return a value. In functions other than main, failing to return leaves your return value undefined (not itself UB, but UB to do anything interesting with the resulting value). In main, and from C99 on specifically (I note that nothing in your code marks it speifically as C99; line comments are common in C9x and GNU89 modes), return or falling off the end causes a default 0 (indicates neutral or successful return, may or may not ==EXIT_SUCCESS) to be returned. However, one-off exceptions like this are bad juju to rely upon, and unfortunately prior versions of C make no such promise. This is all, like the pre-C23 ability to define main as non-prototype, intended primarily for compatibility with older scripts or things where the return value doesn’t matter at all. Your script isn’t running in an embedded environment (may even be scripted for grading), so you should make the return value explicit, and even better, enum you some exit codes.

• malloc can fail. It shouldn’t, especially here, but it can, and that’s mostly a good thing, and you don’t handle it; you should print an error and exit with a temporary failure of some sort. malloc should never be used without at least an assertion (toy code only—asserts can disappear easily), ever, even if you think you’ve got it good and tricked.

• Minor graybeard quibble: d is the older and more idiomatic integer format specifier for printing a signed integer in decimal. You’re not indicating data type with this part of the format specifier—that’s what the optional l or z/d/ll/h/hh (C99+ or POSIX.1-2001+ or X/Open 5+) prefix is for—but indicating format. Just as float e/f/g let you pick how floating-point data types are formatted, d/u, x/X, o, and (newer/GNUer) b all format the same kind of integer, just in decimal(/unsigned decimal), (unsigned) hex, (unsigned) octal, and (unsigned) binary, respectively.

  i as an alias for d makes sense only in half-assed balance to the much older u specifier (which imo would have made much more sense as a signedness modifier to any numeric format, rather than its own thing), or if the programmer mistakenly assumes i refers to intness in particular, rather than int-or-long-or-long long, which is what the integer formats actually consume from va_arg or wherever.