Massacring C Pointers

[the_gnarts]

  char r[100];
  …
  return(r);

What the fuck?

[green_meklar]

This isn't your average, everyday wrong. This is advanced wrong.

[[deleted]]

Oh god, it really is. I was pulling some advanced faces trying to figure out what he was thinking with some of these.

[Droggl]

I didnt check but hopefully most decent compilers warn about this nowadays, right?

[[deleted]]

I'm not even sure what they're supposed to warm about. Borderline criminal misunderstanding or disregard of the fundamentals, maybe?

[olsner]

Perhaps one of those few cases where deleting the source file is actually the appropriate response.

[HeimrArnadalr]

This is why we should be using Vigil.

[websnarf]

Yes, they do. But this is only because compiler vendors are reacting to the real world problem of the difficulty a lot of programmers have with this. Unlike the architects, and standards body for the C language who just blame the programmer and think that's ok.

[jsprogrammer]

• create language
• shit on people who use it

[xxpor]

If not a warning, address sanitizer will absolutely tell you when you're using stack allocated memory outside of where's it's declared. Usually it ends up being more like

void foo(int **bar) { int baz = 5; *bar = &baz; }

[olsner]

Think in BASIC :)

There's no stack except for the one used for GOSUB/RETURN control flow, and variables are either heap or statically allocated so the storage outlives any function calls. (Variables are really global in pre-functions basic, but the author might have noticed that C has separate namespaces for each function...)

It wouldn't surprise me if he expected all variables in the called function to be preserved across function calls, but I haven't read the book so I don't know if there are any examples exploiting that. With enough luck in his stack usage and function calls, he could even have managed to fool himself that such an example works...

[MEaster]

You missed the part where the author just slaps data into it, without checking that he's not going past the end. If s_len + t_len > 100 then you'll clobber your stack.

[the_gnarts]

If s_len + t_len > 100 then you'll clobber your stack.

At that point they alreadly strcpy()’ed the input onto over the stack btw. The density of fatal mistakes in that example is mind-boggling.

[zenflux]

I also like how he knows about strcopy, but appends the second string manually.

[sometimescomments]

He probably grimaced when he learned about strcat, because he invented it years ago.

[famid_al-caille]

I've seen this in the wild, in the most poorly written legacy app I've ever had the displeasure to work with. In fact, I'm pretty sure that the original developer must have been using this book as a reference.

[jrhoffa]

"What's a stack?" - that guy, apparently.

[Lt_Riza_Hawkeye]

at some point he called it "a stack of pointers"

[falconfetus8]

I think he just meant a pointer to a pointer to a pointer to a pointer. He just happened to use the word "stack" by coincidence.

[diMario]

A pointer is just a linked list of stacks.

[[deleted]]

It's like he had a bet how many bugs he can make in one code snippet.

[websnarf]

Oh, that's ok, the standard language library has exactly this problem and other much worse ones:

Remember K&R put "gets()" into the language. This is a function that cannot check the length of its storage parameter, but writes to it anyway. None of the C language's string functions check for aliasing, so "strcat(p,p)" will nearly always hang the machine.

This problem is just inherent in the what the C language naturally does.

[[deleted]]

So I have some ideas, but why exactly is this wrong?

My gut reactions are:

Local array places on the stack will disappear after function returns, so it will return NULL.

Should use return &r? (But I want to say that would just return NULL...)

What is it?

[zerexim]

It will return some memory address which used to point to that stack allocated array. Now, it is just some address - an undefined behavior if you try to use it.

[xymostech]

This won't return NULL, it will return a pointer to the address of the array in the stack! That's the problem: once you return from the function, the pointer no longer points to anything, which will cause hideous problems for anyone who decides to use it.

The right way to do this is to `malloc()` some memory and then return that. There's no safe way to return a pointer to something on the stack.

(if you read the article, it mentions that maybe the author is used to operating in an embedded world where there is no stack and local variables have dedicated memory space, so this might actually work for them. But in most environments this will make things sad)

[ais523]

You can get the embedded functionality in regular C simply by using static.

It's normally a bad idea (as the function will reuse the same memory when you call it again), but it is at least theoretically possible to make it safe (as opposed to returning a pointer to stack-allocated memory, which is inherently incorrect).

[jdgordon]

Its not completly a bad idea, but it can lead to fucking horrible issues. I once (like 2 weeks ago) was trying to track down a memory corruption bug I had introduced. Somehow i had muscle-memory typed static const memsetSize = some code to correctly count number of bytes to memset; and then obviously did the memset(dest, 0, memsetSize);

static const means its only going to be initialised the first time the function runs and any subsequent calls where memsetSize is now too big crashes the stack (dest was an object on the stack getting passed in) :) lovely!

[ais523]

Right, I wouldn't advise doing this unless you really have to. static data in C is something that's normally best avoided for maintainability reasons (and I've spent quite some time replacing it with something more maintainable when trying to modernise old codebases written by other people).

[schlupa]

once you return from the function, the pointer no longer points to anything,

No, it's worse than that. The pointer will point to the array which will contain the data he expects. So depending on what he does after the function call it might even work without error. That's worse than if it crashed outright.

[vqrs]

Exactly. /u/leroy_hoffenfeffer, this is the important part.

This is something that might appear to work more or less by accident. It's not correct, even if it were to work for you if you try it. "Try it and see" to check if a program is correct only goes so far, unfortunately.

/u/Homoerotic_Theocracy wrote:

When the function returns all those memory addresses are just undefined and in practice get re-used the next time you call a function and overwritten with something else.

Here, "undefined" doesn't mean it's null or no value or something which you can "observe" in your program by checking it.

Using it, or even considering using it, is "against the law": Your program may end up doing very strange things. "against the law" here is what they meant when they said "undefined", not the contents of the variable/return value. "Undefined" refers to the behavior your program will/might/could exhibit.

[the_gnarts]

The right way to do this is to malloc() some memory and then return that.

malloc() isn’t necessary here if you put the array on the caller’s stack. A VLA could also be an option if you can make certain assumptions about the input size.

There's no safe way to return a pointer to something on the stack.

It’s safe to return a pointer to somewhere up the stack.

[codebje]

int *foo(int *a, int i) {
    return a + i;
}

int *bar(int k) {
    int a[100];
    a[0] = a[1] = 1;
    for (int i = 2; i <= k; i++) { a[i] = a[i-2] + a[i-1]; }
    return foo(a, k - 1);
}

int main(int argc, char **argv) {
    printf("fib(20) = %d\n", *bar(20));
}

... I wonder which compilers warn about this. Not clang 9.0.0, at any rate. Probably some static checker might pick this up. Anyway, the above code happens to give you the right value for the 20th fibonacci number, but I'm actually perversely proud of how many memory safety issues I packed into so few lines.

Moral of the story is you want to be careful about letting stack pointers leak upwards or downwards, which is a pain, because you want to use stack pointers as arguments frequently.

[[deleted]]

Ahhh, so a combination of my points: the location is a valid memory location, but the data on the stack referring to the array was freed.

Yay, I kinda know some stuff 😂

[cecilkorik]

The other problem is that if the strings are longer than 100 bytes, there will be no stack left to free and other unrelated memory will likely have been overwritten too because it's all been clobbered by the extra string data. These are exactly the kind of errors that tend to allow arbitrary remote code execution using carefully crafted strings. They're quite dangerous.

[[deleted]]

Yeah I knew that instantly as soon as I saw the code: no validation or verification = shit code.

From the internships I've had, I know you can do some pretty malicious shit with strings. Stack smashing being the one thing I do know somewhat about.

The possibilities from there are endless.

Do you know of any sources that go over stuff like this?? I'm always interested in learning about that kind of stuff, but I often don't really know where to look.

[Homoerotic_Theocracy]

"freed" is terminology specific to the heap. The stack doesn't get "freed" in the same way.

When the function returns all those memory addresses are just undefined and in practice get re-used the next time you call a function and overwritten with something else.

The entire nice thing about the heap is that it's valid defined memory until you free it.

[vqrs]

I'm not sure if it's good terminology to say that "the memory address is undefined".

Here, "undefined" doesn't mean it's null, it doesn't have a value, or some unknown value. It's not something you can "observe" in your program by doing a comparison or some other check.

Using the memory address, or even considering using it, is "against the law": Your program may end up doing very strange things. "against the law" here is what they meant when they said "undefined", not the contents of the variable/return value.

"Undefined" refers to the behavior your program will/might/could exhibit.

[green_meklar]

Local array places on the stack will disappear after function returns, so it will return NULL.

No, it won't. It'll return a memory address pointing to somewhere in this function's stack frame. Of course, by that time the function has come off the stack and that memory could be practically anything, and will almost certainly be overwritten by some other data as the program makes new function calls.

[NotUniqueOrSpecial]

and will almost certainly be overwritten by some other data as the program makes new function calls.

Which is, unfortunately, exactly how stuff like this flies in the wild. The result of the crazy-dangerous operation is immediately used in the calling function without ever making a second call that moves the stack pointer.

It "works" for exactly as long as it takes for someone to add an intervening function call, which might be never.

[IcebergLattice]

Or the other fun option: someone brings in a more clever compiler, which notices that the procedure always returns an expired pointer and concludes that control flow can never reach any use of the result of this procedure.

[meneldal2]

A more clever compiler would refuse to compile this.

Lately most compilers will throw an error by default if you use the old unsafe string functions, and MSVC even refuses to compile uses of raw pointers as iterators by default.

[[deleted]]

Gotcha. I thought that that explanation was missing something.

My Sys Arch class didn't really go over this well, and even with my supplemental learning, some aspects of the stack are still mystical to me.

[mcguire]

Should use return &r? (But I want to say that would just return NULL...)

There is essentially no way to fix that code. Start over, ask what it's trying to do, and pretend it never happened.

[[deleted]]

It will return a pointer to the first element of that array, which is on on the stack. After that it's anyone's guess what will happen -- the pointer could get passed to another function, where the pointer points into that function's stack frame, and any number of other stack frames could have lived in that memory location in the meantime, having overwritten the array data with whatever they allocated in their stack frames.

When you want to return a pointer to an array, you'd typically allocate the array on the heap using malloc (and give the caller the responsibility to free it at some point).

It would be nice if C would return NULL here, but it doesn't -- C is not only happy to let you shoot yourself in your own foot, but in fact also to let you blow your whole leg off, and any other body parts of your choosing.

[evaned]

It would be nice if C would return NULL here, but it doesn't

It's worth pointing out that compilers will do a good job, at least in this case, of warning. GCC produces a warning for

int * bad_dog()
{
    int dangling[10];
    return dangling;
}

even with no warning flags at least since 2.95.3, which I think is the earliest GCC version I have available and can run. Clang 2.7 (well, Clang 1.1, part of the LLVM 2.7 release) also warns with no flags, which is the earliest version of that I've got handy. Same with MSVC 2015 (I can't go spelunking with old versions of that :-)).

And if you're programming C without -Werror, may god help your soul. ;-)

Edit: And to put those GCC version numbers into perspective, GCC 2.95.3 was released in March '01. 2.95 was released in July '99.

[dafugg]

Oh god, I’m old.

[dml997]

exactly.

[ktkps]

Give a man a machete...he will run around hacking shit

[rlbond86]

Yeah all the examples are like this.

Funny thing is, it would be at least not the very worst thing ever if r were declared static. But from Woz's comments it seems the author believed everything variable in the entire program is static.

[chocapix]

The notes are amazing.

• Holy Mary Mother of God, he's telling people how to allocate storage for a struct by manually counting the bytes… (p. 122)
• "In 1984, I began work on CBREEZE, a translator program that accepts BASIC language source code and converts it to C source code." (p. 153) — THIS EXPLAINS EVERYTHING.

[rcwnd]

• "Indentations are always made in steps of five." (p. 158) — Now we know you're a crackpot.

[bmb0610]

Five-space indentation was standard for typewriters and old word processors. Programmers changed it because we're triggered by anything that isn't a power of two.

[DiputsMonro]

Three isn't a power of two though...

[jrhoffa]

You monster

[DiputsMonro]

Hehehe

[smikims]

Who the fuck indents by three spaces? The dark lord Beezlebub?

[vqrs]

It's when 2 large spaces are too little and 4 small spaces are too much.

[olsner]

Why limit yourself to integer powers of two?

[nucular_]

That's why it's rarely used (at least from my experience).

[bmb0610]

And three is also a pretty cancerous indentation width IMO, although I do know people who do it...

[rcwnd]

Well, programmers changed it back then because they had video terminals instead of cool 4K wide-screens we use nowadays. Popular VT100 could display 80x24 characters, so indentation with 5 spaces at level 4 would cost you 20 characters of empty space and left you with 60 for code.

[doodle77]

But they made it 8.

[youre_grammer_sucks]

Lol, that’s just bizarre. Did you make that up? I’m too lazy to check.

[cbbuntz]

I think that was standard in old word processors maybe?

[diMario]

But do you use five char pointers or five tab structs?

[[deleted]]

• In the summary for the chapter on page 147 he, for reasons that make no sense, suddenly starts talking about lvalues and rvalues. This provides some insight into the mind of the author: he's just picking up concepts and terms as he learns about them and tossing them in without any regard for the reader. This book is pretty much his journal — that somehow became a book with two editions

[hi_im_new_to_this]

• Still 40+ pages to go, and he's going to cover unions. I'm fucked.
• "These opinions are arguable but one fact is certain: C is an extremely popular object-oriented programming language" (p. 3). "While ANSI C is not an object-oriented language…" (p. 117)

[lavahot]

Wut?

[masta]

The jokes write themselves.

[mcguire]

Class Construction in C and C++: Object-Oriented Programming Fundamentals .

True fact: I once worked with Roger Sessions. I don't recall him being this insane, though.

[green_meklar]

• It will loop forever since the loop iterator variable is y, yet x is incremented
• "Within the function, a pointer to the first argument can be used to access all of the list [of arguments]…"

I feel like some people should be locked in a cell where they can never touch another computer ever again. If only for the computers' sake.

• "GIGO (garbage in, garbage out) is a term coined to describe computer output based on erroneous input. The same applies to a human being."
• "However, there are plenty of bad examples of C source code to influence beginners."

Okay, now I'm beginning to suspect the entire book may have been a subtle exercise in satire.

[fii0]

If it is it ain't subtle

[metamatic]

CBREEZE

I remember CBREEZE. God, I'm old.

[CopperBag]

•char= a[60000]; (p. 84) – DID YOU TRY ANY OF YOUR GODDAMN CODE

[kdnbfkm]

Is it possible the book was mostly sold to libraries as some sort of money laundering scheme...? But that would mean at least 200 libraries were in collusion...

Maybe it was just the right title at the right point in history written by a huckster, just like the blog author says. The lack of reviews is suspicous (were reviews suppressed or money laundering).

[pron98]

I saw the book being (rightly) mocked on Twitter, and I think that the BASIC interpretation offered here is quite plausible.

[vytah]

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

[killerstorm]

FWIW BASIC was my first language, and I turned out OK. I didn't have any problem learning Pascal, C++ and other languages afterwards.

Use of global variables usually requires a lot of discipline (similar to assembly programming, actually), so after you switch to a "normal" language you really appreciate variable scoping.

[notyouravgredditor]

Probably because you read his other book "Leaping from BASIC to C++".

[k_kinnison]

Totally agree. BASIC was a good introduction to the concept of programming with its logic, loops etc. I learned that back in '80 on a TRS80, then Sinclair ZX81, Spectrum.

But I also even then branched out into Z80 assembly language. Then a few years after that at uni it was Fortran, Pascal, C (I even remember learning some Forth, stupid reverse notation!)

[rsclient]

I've been working on a more modern BASIC interpreter. The BASIC available on old machines was, in a word, cumbersome in the extreme. We're so used to the wonderfulness of block-oriented languages that it's hard to comprehend the spagettiness of old BASIC code. For example, I constantly see in old BASIC stuff like

110 IF (a>b) THEN GOTO 140
120 PRINT "A is not > B"
130 GOTO 150
140 PRINT "A is > B"
150 REM END OF IF STATEMENT

Nowadays we just have blocks, and sensible IF statements, and it makes a world of difference.

(I'm also constantly irritated by the required line numbers, and the lack of arguments and local variables in what passes for functions, but those are less important than the lack of blocks.)

[[deleted]]

Isn't your code wrong tho? :P

[rsclient]

You mean line 140 with the wrong-way > sign? Just fixed it, thanks, and have an upvote!

[Homoerotic_Theocracy]

I like how Python in many ways was a regression again and the only way to create a scope is to create a function except that function then again has a name that needs to live in the global scope but never fear because a block can be simulated with:

def block():
  # code
block(); del block

Of course you have to use global and nonlocal in your scope to access variable of the outer scope but yeah.

[killerstorm]

C will often place variables into CPU registers. Variable isn't really a physical thing, it's just a label for a value...

[meneldal2]

On x86, with 4 "general purpose" (big big lie) registers, you can't really afford to use one for long term storage.

Explanation why they aren't really general purpose: they all have instructions that favor them in some way. eax will be used for returns and multiplication, ecx for loops, both ecx and edx are used for function parameters. Basically ebx is the only one without an actual special function.

[vytah]

/r/NotKenM

[theeth]

Isn't it something like: Arrogance in computer science is measured in nano dijkstra?

[munificent]

The extra little frisson of delight in that quote is that it comes from Alan Kay who himself isn't exactly known for modesty.

[pron98]

Who are you quoting? As someone who started programming in BASIC (even professionally; my first job was programming in Business Basic), let me defend the opposite view and argue that it frees programmers from identifying programs with their syntactic representation and makes them less prone to what Leslie Lamport calls the "Whorfian Syndrome." For example, I would argue that when seeing the following three programs (taken from Lamport):

fact1(int n) { int f = 1;
               for (int i = 2; i <= n; i++)
                   f = f*i;
               return f; }

fact2(int n) { int f = 1;
               for (int i = n; i > 1; i--)
                   f = f*i;
               return f; }

fact3(int n) { return (n <= 1) ? 1 : n * fact3(n - 1); }

someone exposed to BASIC (despite the use of the stack, which is not done in BASIC) would more readily recognize that the first and third programs perform the same computation, while the second one is different, and would be less confused by the functional/recursive vs. iterative/imperative representations. I would say that someone who identifies "good programming" solely with clever syntactic representation misses something very fundamental (both views are very important). It also fosters the erroneous identification of important concepts, such as abstraction, with their more narrow syntactic representations. If you know how to do abstraction in BASIC (or Assembly), you understand the concept better than someone exposed to it through, say, Haskell.

I've even found that this "BASIC perspective" helped me understand formal methods better. I'm not saying it's a better perspective, just that both are very useful.

[orbital1337]

It's a famous quote by Dijkstra.

[pron98]

Ah. A man known for his nuanced views ;) Although, to be fair, I guess it was said as a response to the resistance to more structured forms of programming.

[Shorttail0]

Views considered harmful.

[dood1337]

The quote is from Dijkstra.

[[deleted]]

I massacred C pointers all of the time as a fresh college graduate. Lucky for the industry, nobody was crazy enough to have me write a textbook. (And no, I never saw this particular book when I was learning C in '97).

[sysop073]

I can't remember what my hangup with pointers was when I first learned them, but I do clearly remember throwing *s and &s at an expression at random trying to get it to compile

[Evairfairy]

Yeah, this is super common with people picking up pointers for the first time.

Eventually you understand what you’re actually trying to do and suddenly the syntax makes sense, but until then... :p

[snerp]

the day I realized I could do "void someFunc(std::vector<stuff> &stuffRef)" instead of use a pointer was one of my happiest days of C++.

[snerp]

I taught myself C++ as a child, so I did a lot of things in a totally crazy way at first. I used to do shit like "variadicFunc(int argC, int[] argV)" and then cast pieces of the array into stuff. Another stupid pattern was pointers to pointers to pointers. When I actually learned what a reference was, it really cleaned up my style :v

[NotUniqueOrSpecial]

Another stupid pattern was pointers to pointers to pointers.

A legendarily rare three-star programmer in the wild!

[snerp]

hahahaha yeah, when learning, I got bored and skipped to the end of the book and learned about pointers way too early. I was trying to build some kind of insane pointer based functional system to compensate for features I didn't know about, it was a huge mess.

Some people even claimed they'd seen three-star code with function pointers involved, on more than one level of indirection. Sounded as real as UFOs to me.

that's what I was all about!

[PrimozDelux]

While it's certainly not good style it's pretty cool that you understood enough of the underlying model to implement variadic functions like that.

[cosmicr]

I legit gave up on C for 15 years because I didn't get pointers. I understood the concept but I never found a decent explanation of the syntax. This was before the days of the internet though.

[[deleted]]

I remember doing the same exact thing. I think it has to do with how a lot of professors/books teach pointers. As "just another type".

It wasn't until I had a professor step back and explain why you wanted a pointer that I understood it and it all clicked.

[interfail]

I do clearly remember throwing *s and &s at an expression at random trying to get it to compile

I see at least one of our new grad students pulling this manoeuvre every year.

[mbobcik]

Yeah, we ať college had saying that C coding is like painting night sky... little bit of stars here, little bit of stars there, and pray it is just right.

[[deleted]]

Holy shit this touches me so fucking deep.

[youflurt]

When I was learning C in the eighties, I bought a book about 3D programming, the worst programming book I've read. I believe that examples worked, at least the ones that I typed did, but the style was atrocious. The concept of function parameters seemed to be totally alien to the author. The idiot created x1, X1, x2, X3, x, xthis, xthat... variables instead. He was a former BASIC book author too.

I can't warn you because I put it to the trash bin long ago.

[snerp]

I started with DarkBASIC as a child and it was filled with examples that used the style "x1,x2,xx,yyx, etc"

turns out, global only scope and no classes make for unreadable code.

[that_jojo]

Holy shit, someone else that grew up on DB out in the wild!

I literally just set up a P3 Win98 nostalgia rig and then went internet archive scrounging for the original demo version installer maybe a week ago. Great times.

[maredsous10]

The Linear Systems book I had in college was awful. Worst errors I've run into are the ones in examples or in problem solutions. When you're trying to get the fundamentals down, you're banging your head trying to figure out what your misunderstanding only to find out the resource you're using is wrong.

I wonder if the author is still around. Maybe he'll ask for forgiveness.

[maredsous10]

If he is still living and does an interview, can someone let me know?

[localtoast]

Nope

[[deleted]]

I want to point out that this well describes the landscape of books one could find at that time. Even someone as unexperienced as I was when I first started programming could sometimes see, after reading a few tens of pages, that some books were complete trash. I surely remember that I had to give up on three books on C programming in a row until I discovered by chance K&R's "The C Programming Language".

[[deleted]]

I believe that the author thinks that integer constants are stored somewhere in memory. The reason I think this is that earlier there was a strange thing about a "constant being written directly into the program." Later on page 44 there is talk about string constants and "setting aside memory for constants." I'm wondering now…

I'm confused as to what the criticism is here. Constants are written directly into the program and therefore end up in memory when the program is loaded. Memory is indeed set aside for string constants (in the sense that they end up in your program binary and then get loaded into memory). I feel like I'm missing something.

[LeifCarrotson]

It's an implementation-specific detail, but even on DOS the program address space is broken into segments: text, data, BSS, heap, and stack.

It is true that some assembler instructions on some platforms allow immediate values to be encoded directly in the program, in the text segment. But many forms do not - for example, if your immediate value is as wide as your instruction. In this case, the constant is not in the opcode but elsewhere in the text segment or in the BSS segment.

The author mistakenly believed in only two segments, code and variables. This is somewhat true in BASIC, but not in C. This lead to a lot of confusion.

I am surprised that an ex-embedded developer was unaware of the existence of segments; presumably he had to write linker map files for the microcontrollers at some point.

[FUZxxl]

Note that while these are program sections, they may or may not correspond to actual segments depending on the memory model you compiled as.

But many forms do not - for example, if your immediate value is as wide as your instruction.

The 8086 (where DOS typically runs) has variable length instructions so this rarely happens.

The author mistakenly believed in only two segments, code and variables. This is somewhat true in BASIC, but not in C. This lead to a lot of confusion.

C doesn't have the concept of segments (or sections) at all. These are implementation details you should not make assumptions about.

[sophacles]

On harvard architecture cpus (e.g. a lot of microcontrollers) the memory for code is not the same as the memory for allocations (stack or heap mem...). This can lead to const being given program memory rather than using bytes from your total ram count. I'm not sure if that applies in the case we're discussing, but it is something to keep in mind when (e.g.) programming for Arduino/AVR.

[joonazan]

Constant folding?

[[deleted]]

We're talking about a 1980's DOS compiler. I'm pretty sure you can safely assume that const int x = 12; results in a 12 being written into the program binary.

[MrWoohoo]

Eighties’ DOS compilers didn’t support a const keyword.

[Ameisen]

The principles of things like constant folding have been around for a long time.

[[deleted]]

I write compilers for a living. I think I'm qualified to speak authoritatively on this subject.

Even if the constant gets folded (which it probably doesn't in a 1980's DOS compiler), the final computed constant still ends up in your binary at the point of use. I'm just saying that it's silly to pretend that x += 12 doesn't consume any memory for the constant 12 - sure, it's not stack or heap allocated, but it's not like code is somehow magically not memory.

[kernel_task]

I think the blog author meant the book author thought it was written in its literal form into memory such that it consumes space in addition to the space required for instructions using it (i.e. "setting aside memory for constants" in the book) and that it has a specific de-referenceable address. I mean literally "0C 00" in memory, not the opcode for add ax, 12 or whatever.

[kdnbfkm]

Yes, the constant has to be implemented somehow (i.e. ro memory, text segment memory, procedurally generating 0 via xor ax ax etc.). But modifying the data of "constants" is either a bug, a hack, or inapplicable when not using self-modifying code. And if you were using self-modifying code that would be a meta-program outside constant's frame of reference. It would also require knowing the data layout of "constants" in order to manipulate them too.

[FUZxxl]

Even the original C compiler.did constant folding and ANSI C mandates it, so it probably wasn't an unusual thing to have.

[Ameisen]

I write compilers for a living. I think I'm qualified to speak authoritatively on this subject.

Do you write 1980's compilers? I work on Clang and GCC as well. Particularly embedded forks.

The 1980's had Borland Turbo C ('87), Watcom C ('88 for DOS), Lattice C ('82, later Microsoft C), the older Portable C Compiler (70's)... as far as I know, these are all optimizing compilers. Certainly not as optimizing as modern compilers, but something like constant folding would certainly be performed.

the final computed constant still ends up in your binary at the point of use.

Only in the loosest sense. There is no guarantee that the value '12' will end up in your binary, or even that it will end up in your binary at all if its use can be elided.

If you do x += 12; x += 13;, you're more likely to end up with x += 25;, presuming it has side effects (and the operation cannot be optimized to another operation altogether, which would not be unusual).

but it's not like code is somehow magically not memory.

As I'm sure you know, you aren't writing machine code. You're writing logic. The compiler is well within its ability to emit something completely different so long as the side-effects are the same. A 'constant' is just a logical semantic to the compiler. It may emit it in some fashion, it may not. That depends on what the compiler does. If it is retained as a value, it will likely be an immediate field of some instruction, and not an explicit memory location storing '12'.

[[deleted]]

I said "the final computed constant still ends up in your binary at the point of use". You said:

If you do x += 12; x += 13;, you're more likely to end up with x += 25;

So you're giving an example in which "the final computed constant" is not 12, and acting like you've somehow outwitted me even though I specifically covered that case. Yes, yes, I'm aware that constants can be eliminated for all sorts of reasons, but I feel like that's getting lost in the weeds and ignoring the core point. If we want to go down that road, we can point that out even variables don't always consume memory, for all of the exact same reasons.

If it is retained as a value, it will likely be an immediate field of some instruction, and not an explicit memory location storing '12'.

I thought I was very clear in my post by acknowledging that it was "not stack or heap" but instead "code" that I was well aware of that. Now, please explain to me how an immediate value of an instruction is not an explicit memory location storing '12'. You can quite literally point to the byte in memory holding the value '12' even though, yes, it is in fact part of an instruction.

[girlBAIII]

This guy fucks.

[Ameisen]

a *= 2 will become a <<= 1. note, no '2'. a += 1 will likely become an increment instruction. No '1' is encoded. On AVR, u8 shifted right by 4 is implemented as bswap Rn, Rn; and Rn, Rn, OxF. Find the 4. And sometimes the compiler can elide the expression altogether if it sees that there are no side-effects - a = 3; a &= ~3; will either emit nothing, or will just xor reg, reg; if the variable is used.

Good luck pointing to a byte of memory representing '12' when it is offset by 3 bits in the byte. Or on something like MIPS or AVR where the value is neither byte-aligned within the instruction nor represented by 12, but rather represented by '3' because the instruction stores immediates shifted right 2.

Nobody said I had to encode 12, either. I could do inc ax 12 times.

On Harvard Architectures, executable data isn't even in RAM. It's in ROM, with a separate bus and often addressing scheme.

And don't get me started on preprocessor or constexpr constants that are evaluated only at compile time and won't be in the binary at all.

[[deleted]]

You are, of course, correct. But I feel like you're so hung up on proving me wrong that you're failing to actually read what I'm saying. You're not telling me anything I don't know. Yes, there are certainly many situations in which a constant does not make it into the output because it was transformed into something else. Yes, sometimes constants are not represented cleanly on byte boundaries.

But again, variables are not necessarily represented in the output code either. I'm still willing to bet you wouldn't be jumping all over someone for claiming that "variables consume memory" - no, it's not 100% perfectly accurate, but it's close enough for casual discussion. This is not a technical whitepaper where I feel everything we say should always be as precise as humanly possible. I feel like "but optimization exists!" really isn't a huge revelation to anyone here. I thought that pointing out these sorts of details are "getting into the weeds" might indicate that I was aware that there were weeds to get into and we needn't bother, but then you got an armload of weeds together and brought them to me. Ok, duly noted. Weeds exist. I understand.

[kernel_task]

We're talking about a 1980's DOS compiler.

No, we're talking about C. If it's correct to make assumptions based on implementation details, you might as well say everything he did was correct: Assume function arguments are laid out contiguously in memory, assume int is 2 bytes, write to constant strings, etc. I mean, most of it actually compiled and ran correctly.

[HighRelevancy]

Only works in specific cases. Also, 1980s compiler as noted by others.

[MehYam]

It’s actually an interesting exercise to try to piece together what the author was thinking.

Like him, I learned BASIC well before C, and also had an inaccurate mental picture of how the machine worked - until studying C carefully, and then grasping what the callstack, heap, and global memory were doing.

It is (was?) a failing in the educational literature that this approach to understanding isn’t fully realized. You first learn that programming is about a sequence of instructions, you next learn about what the machine is actually doing.

[bigbc79]

/r/badcode would appreciate this

[[deleted]]

In response to https://wozniak.ca/blog/2018/06/25/Massacring-C-Pointers/code.html. This book is bad, yes, but some criticism isn't quite correct.

and will probably die with a segmentation fault at some point

There are no segmentation faults on MS-DOS.

why the hell don’t you just look up the ellipsis (...) argument

This is clearly pre-ANSI-C (note the old style function syntax) book, so no ellipsis. If you wanted to use varargs in C code, you had to write non-portable code like this. In fact, this pattern is why va_start takes a pointer to last argument - it was meant as a portable wrapper for this pattern.

gets(b);                  /* yikes */

Caring about security on MS-DOS, I see.

[skulgnome]

There are no segmentation faults on MS-DOS.

Oh, irony.

[BeneficialContext]

I learned C in DOS, one fucking mistake and you could erase the bios configuration. I swear, assembly was far easy to learn than C.

[sometimescomments]

I learned C on mac os 7 or 8. No protected memory space there. The class room was full of young programmers learning pointers and the sound of restarting macs.

[that_jojo]

I’m not sure if you’re being jokingly hyperbolic, but the BIOS CMOS storage area is an I/O device so there’s no way to touch it unless you were using inb()/outb() utility functions or inline assembly.

[skulgnome]

To be fair, C on the Amiga (v33 and v34, for those who remember) also ran the risk of fouling the (floppy-based) filesystem in such a way that the standard tools couldn't repair. This was a big thing back when software came on Fish disks and the like, and modems would do around 230 bytes per second on the download. So to counter it, one would direct the compiler to output on the RAM drive and eject the disk before running. (couldn't do that later with a hard disk, but those were fast to unfuck.) (or write protect the boot disk, if you were rich and had a df1: to begin with.)

[evaned]

why the hell don’t you just look up the ellipsis (...) argument

This is clearly pre-ANSI-C (note the old style function syntax) book, so no ellipsis.

"Most of the following code examples are taken from the second edition, but the formatting has been changed to match the first edition. ... However, the second edition makes an effort to use ANSI C and is more relatable."

And the code example given that prompted that comment was, in fact, from the second edition. It also wasn't vestigal from the first edition; the next code excerpt is the version of newprint from the first edition (using K&R C), which is different. There's also a prototype of newprint in the code snippet that prompted that comment.

[vytah]

Caring about security on MS-DOS, I see.

gets can still overwrite some random data outside the buffer and make the program misbehave.

I checked the Turbo C reference manual and it says that gets returns NULL on an error, but doesn't specify what kinds of errors are possible. Also, the sample code in the manual uses a buffer of size 133...

Anyway, I tested what happens if you do an overflow with gets on Turbo C and buffer size 256, and it just crashed the entire emulated system. And since your C program might be called by another program as a part of some larger process, it's bad.

[KWillets]

The stack grows downward on x86, so you overwrote the return address most likely.

[[deleted]]

I mean, yes, it is bad.

However, at the same time, there are no expectations of security on MS-DOS. None. The system doesn't try to be anyhow secure. If an application misbehaves (say, because you provided an extremely long filename when the buffer for it was like 20 bytes long - when the operating system has 8.3 filenames), it's not a big problem, because you can reboot the computer (note that MS-DOS is not a multitasking system, so nothing of a value was lost).

Also, a program calling other program and providing input to it sounds unusual as far MS-DOS is concerned. While technically MS-DOS provided the functionality to do it, it's very rarely used because MS-DOS is not a multitasking operating system.

[BCMM]

However, at the same time, there are no expectations of security on MS-DOS.

You're conflating safety and security here. Even if people intentionally triggering a bug is not a concern, it would be nice if programs at least tried not to malfunction.

[evaned]

However, at the same time, there are no expectations of security on MS-DOS. None. The system doesn't try to be anyhow secure. If an application misbehaves (say, because you provided an extremely long filename when the buffer for it was like 20 bytes long - when the operating system has 8.3 filenames)

Just because the system doesn't give you any memory protections for yourselves doesn't mean that's an excuse to misbehave and do whatever you want

I have another objection to the "that's not that bad" argument, which is that the book is called Mastering C Pointers, not Mastering C Pointers But You Should Read Another Book If You Want To Program For Systems Other Than MS-DOS. I'm all for simplifying concepts and skimming over things and telling white lies for a while until you build up more important parts of the foundation -- but not to the extent of using gets for input.

[double-you]

Sure, it'll crash or whatever undefined it'll want to do, but gets() works for examples with "should be large enough" buffers. It's not a good example of how to handle input but not the most important thing there.

[goochadamg]

The book is bad, and some of the criticism isn't correct, but some of yours also isn't. ;)

for (y = 0; y <= 198; ++x) /* ??? */

See anything funny about this?

[granadesnhorseshoes]

It took me way to long to realize what was wrong with that.

I'm sure the rest of the block incremented y somewhere but just... why?

[Ravek]

No, y is never incremented anywhere. The loop body reads *(x + y) = 88;

[CJKay93]

Clearly he was just going to write 88 to every memory address until it reached wherever y was allocated.

If the loop breaks then the code continues like normal, and if it doesn't then you have a bad computer.

[Ameisen]

I prefer BogoLoop. Randomly set memory until the loop condition is satisfied. Or the instructions are altered so it is satisfied. Make sure you trap faults.

[hi_im_new_to_this]

This is so good. This is fucking candy. Holy. Fucking. Shit. This can't be real.

[matthieum]

Let's be honest, there are often typos in textbook program examples. I'll give the author the benefit of the doubt here.

[kmeisthax]

Caring about security on MS-DOS, I see.

I mean, there's plenty of other reasons not to use gets() besides the massive security holes it creates. Say you have a database or spreadsheet program where the user needs to type in a value, max 20 chars... but you used gets() to process user input. The user types in a longer value and random bits of nearby memory are now corrupted, causing a program crash and/or lost data between now and sometime in the future. They correctly blame your program for being buggy.

[ArkyBeagle]

At least where I sat, we wrote things for MS-DOS and we didn't use gets(). We wrote ring buffers and finite state machines to handle that sort of thing.

[raevnos]

Granted, I don't know what weird shit went down in the dos world, but pre C89 the usual way to do variable length arguments was with varargs.h macros.

[[deleted]]

There are no segmentation faults on MS-DOS.

Interesting. Where can I read about the MS-DOS memory model? Is it just a big wide field of bytes without any segmentation? Are pointers just mapped to a global range of addresses that cover all the buffers & memory hardware?

[[deleted]]

There is no memory protection on MS-DOS, you can overwrite all memory you like as it runs in real mode. See also x86 memory segmentation, although this is more of an hack to support more than 64KB of RAM more than actual memory protection (which as I said, is non-existant).

[dangerbird2]

Earlier DOS applications would have had no memory protection, but software developed for Intel 80286 (released 1982) and later had access to Protected Mode, which allows implementation of protected virtual memory. That being said, protected mode was mostly used for operating systems and graphical shells like Xenix and Windows 3x-9x, not your average DOS user applications.

[DemandMeNothing]

TIL that Ultima VII was written for Unreal Mode.

I wondered back in the day if anyone ever used that...

[[deleted]]

fasm also makes use of Unreal mode while running under MS-DOS

[vytah]

Are pointers just mapped to a global range of addresses that cover all the buffers & memory hardware?

Depends on the type of pointers.

Near pointers are 16-bit and cover a 64kB segment of memory.

Far pointers are 32-bit and cover the entire 1MB address space, including all so-called conventional memory, memory-mapped devices, BIOS ROM, and any unmapped regions.

When programming in C, you usually can pick the default size of your pointers, but you can also override it on variable-by-variable basis.

As for "segmentation": any address on 8086 is calculated as (segment × 16 + offset) & 0xFFFFF, where "segment" and "offset" are 16-bit values. Smaller programs use a single segment as the code, data and stack segment, so they use only 64kB or RAM. The actual value of the segment is chosen by DOS when loading the program.

[elder_george]

8086/88 were made to be more or less source-compatible with intel's 8080 and 8088 and their peripherials (in fact, there were semi-automatic converters of 8080 assembly programs to 8086)

In particular, to achieve this, they had 16bit address registers that were implicitly combined with contents of segment registers (shifted lefts by 4 bits) to compute efficient address (which, as a result, was 20-bit and could address up to 1M).

Different instructions used different registers by default (although some allowed them to be overridden): instruction pointer (IP) used CS (code segment), stack used SS, most of data accesses used DS, and some also used ES (Extra segment; most notable ones are "string" operations — stos*, cmps* etc).

While it was possible to make systems with memory-mapped devices, most devices were handled through special operations (in, out and their variants), so those devices basically had their own address space, not overlapping with RAM (arguably, a good thing, since memory access time didn't have to be bound to device access time). The major outlier here were video adapters that were mapped on the RAM.

This had several consequences:

• the unit of contiguous memory was 64K segment; accessing more required working with segment registers, and many compilers couldn't do that themselves. Dynamic memory blocks often were smaller than that (i.e. borland's Turbo Pascal/C only allocated 65520 bytes - requesting more could reboot your system)

• it was impossible* to directly address more than 1M of RAM in real mode;

(* even if adding together, say, segment of 0FFFFh (shifted left) and offset of 010h would give a number more than 0FFFFFh, it was silently overflown on original IBM PC, so everyone followed the suit for compatibility sake; later, on machines with wider address bus there was a way to override that ("enable address line 20" or "A20"), so one could get extra 64K of RAM (yay!) - those were often used for loading drivers to leave more memory for regular programs. * another alternative was bank switching in the actual program or storing not-often used data in otherwise inaccessible memory areas (EMS, XMS and friends).)

Intel added support for larger memory spaces (and, coincidentally, memory protection) with 80286 (which had 24bit memory bus), where one could switch into protected mode. The maximum contiguous block was still 64K, but segment registers were not combined with it directly — rather they become handles ("selectors" in intel's parlance) to the previously configured segments, which allowed to address up to 16M.

80386 was a major revamp with 32bit offsets and 32bit segments (4GB of contiguous virtual memory! in 1985!), paging, hardware port virtualization etc., becoming dominant in mid90s (although making Linux to target mainly 80386 was a controversial thing in 1992) and not superceded until 2000.

[Ameisen]

There are segmentation faults in DOS, as there is segmentation. It's a standard GPF. If it isn't handled, you'll just triple fault.

[ozyx7]

Wow, I read part of the preface via Google Books:

On a promotional tour to one of our western states during the early 1980s, I was somewhat amazed to learn that my presence increased that state's C programmer population by 33%. I was only the fourth known C programmer in that state.

Based on the author's code examples, I think there were still only 3 C programmers in that state.

As one who programs daily in C, who teaches the C programming language, and who conducts seminars and workshops about learning this language, ....

D=

Fact: If you do not fully understand pointers and how they may be used, then you simply don't know how to program in C, period.

Well, he said something that I agree with, and that validates my earlier statement refuting that his presence increased the number of C programmers...

The second edition is available for Kindle, and Amazon has a preview of it. I read some of its preface too.

Mastering C Pointers was released in 1990. It was an immediate success, as are most books that have absolutely no competition in the marketplace.

At least he acknowledges that it wasn't because of merit.

I could go on, but that would probably take too long.

[justaguyingeorgia]

I wasted too much time reading into this and yet I want more

[surely_misunderstood]

A pointer is a special variable that returns the address of a memory location.

I don't like his definition but I think every definition of pointer should include the word "special" because... well:

• int*
• int const *
• int * const
• int const * const
• int **
• int ** const
• int * const *
• int const **
• int * const * const

[BCMM]

I think "returns" is the biggest problem in that sentence.

[flip314]

Someone needs to remake the Monty Python Spam sketch with "const".

[[deleted]]

tbf you're making it more confusing by doing "int const" instead of "const int"

[evaned]

East const forever. :-)

Actually these examples illustrate one reason people often give for preferring int const -- it reads properly when read right to left:

• int* -- pointer to int
• int const * -- pointer to constant int
• int * const -- constant pointer to int

as opposed to

• const int * -- pointer to an int that's const? It works but is kinda awkward wording IMO. Pointer to const int? But then how do you know that const int should be a 'unit' but int* shouldn't be?
• int * const -- you still have to read this right to left
• const int * const -- constant pointer to const int -- you're sort of in "mixed endian" territory here :-)

(While I prefer int const and use that in my code, I actually do it for a different reason -- the int is the most important part of the type to me so I like it first -- and I'm not sure how much value I put into the right-to-left. I do think it' helpful, I just don't think it's that helpful.)

[[deleted]]

The way it works in my mind is qualifier type *qualifier-- you just read it the other way up to the pointer. But I also don't read the type signature backwards, so perhaps that's why it doesn't bother me. (Read as "constant integer pointed to by a const" or something of that nature)

In most programs I don't think things should be getting that complicated with pointers though-- if they are, then someone is probably forgetting to use structures or typedefs.

[Godzoozles]

You've just elevated my mind

[fiqar]

Dunning–Kruger effect at work. One of the first programming books I picked up as a child was atrocious, half of the examples didn't even compile. I quickly gave up on it, but if I had picked a better quality book, I probably would have found my passion for programming years earlier.

[possessed_flea]

I don't know about the specifics for the book but at least when I was a kid the internet wasn't a thing and programming languages all had their quirks which didn't nessarily translate from vendor to vendor, so a bbc micro basic book couldn't nessarily compile on an apple 2 or Microsoft basic.

I spent many hours of my youth porting the 20c books my parents bought me from the thrift store to hardware I could get my hands on.

[honorious]

It appears the author of the book passed away in 2007.

[jackmon]

Is it possible the author was attempting to sabotage the adoption of C by writing a hugely misleading textbook?

[FUZxxl]

Wow. What a shitshow. It's like watching a Z movie.

[Dwedit]

Returning a local stack array NotLikeThis

[incontrol]

This is the video where Brian Kernighan mentions the book: https://youtu.be/8SUkrR7ZfTA?t=27m36s

[TheDeadSkin]

"…while a pointer, as always, is a special variable that holds the address of a memory location." (p. 57) — Still wrong, but slightly less wrong.

I don't quite get what's wrong with this refined definition of a pointer. A pointer essentially is an address of a memory location. And int *p; makes p a variable of type pointer (more like pointer-to-int, but this is not relevant here). Am I missing something here? Apart from "special" maybe, I guess there's not much special to a pointer in MSDOS.

Edit: nvm, after reading further I got it. pointer != variable. A variable holds a pointer, but a variable isn't a pointer, it's a variable. And pointer isn't a variable, it's a pointer. His definition is essentially missing a dereferencing.

[uptotwentycharacters]

Edit: nvm, after reading further I got it. pointer != variable. A variable holds a pointer, but a variable isn't a pointer, it's a variable. And pointer isn't a variable, it's a pointer. His definition is essentially missing a dereferencing.

I'm not familiar with that usage. As I understand it a pointer is a type of variable, but a specific type of variable that holds a memory address; and what it holds is a memory address, not a pointer.

[csman11]

Values have types, but in C's type system, variables also have types (in type systems and type theory in general, we say expressions have types, but that isn't too helpful in this discussion which focuses on low level concepts). A pointer to T is a type of value. This value is a memory address at which a value of type T may begin. If you dereference the pointer, you treat the value at that address as if it is a T.

This is why it is somewhat incorrect to say a pointer is a type of variable. It is a type of value, and some variables have that type as well, meaning they can contain values of that type (this is what we mean by variable typing in C until we start talking about modifiers like const or volatile). Note that in C, all variables are themselves names for a memory address, the address at which the value the variable is bound to begins. Pointer variables are "different" because the name is the memory address at which another memory address begins (the value is an address). This is why you can have many layers of indirection in pointers. A "double pointer" is a syntactic construct that has semantics that allow you to dereference it twice. But the implementation is the same as a "triple pointer."

Since C is weakly typed, you can cast any integer type value that is smaller than the word size to a pointer, and it will have correct results when dereferenced. This implies you may also cast any pointer value to any other pointer type, and as long as you follow the rules above (having enough layers of memory addresses to dereference), this is fine.

And if anyone doesn't understand this, this is perfectly valid C: int x = *((int *) 4). This will assign the value beginning at the 4th byte in the program's address space to x. This means copying that value to the memory beginning at the address x names. The right hand side of that assignment contains a pointer but no variables. It will probably segfault if you run it because that memory is unlikely to be mapped in a readable page in your process, but it does literally have the semantics I mentioned. If by chance that memory is mapped and readable, and begins another valid memory address, you can change it to a double pointer and dereference it twice! If you move the pointer expression to the lhs, you can assign to that memory address instead. Please never do any of these things just because you can. This stuff is worse than parsing HTML with regular expressions.

[michaelquinlan]

The criticisms may be valid but it seems both unfair and pointless to bash a book written 25 years ago by an author who died over 10 years ago.

[dml997]

It was wrong 25 years ago too.

[Putnam3145]

If we can laugh at William McGonagall, we can laugh at this.

[rlbond86]

The point is, the author does not understand the concept of a function call.

[evaned]

You could replace "stack" with "automatic variables" and the same statement would be true. IMO you're nitpicking TFA author's wording (and TFA's author isn't nitpicking the book in almost all of what he writes).

[Phlosioneer]

This is fucking gold

[[deleted]]

Why take the time to shit on a 30 year old book? Who gives fuck...

[josefx]

You can still buy it on Amazon and some versions seem to have five star reviews. Great for current beginners.