> After reading through this, I'm not sure if it's a list of jokes or real information?
The whole point is pulling peoples legs, the joke being on the person who doesn't know the language well enough and takes it serious.
The answers in the list are the equivalent of telling an apprentice to go get a can of blinker fluid (or Siemens Lufthacken, etc...), which they dutifully do and end up getting laughed at.
E.g. just before the one you quoted was this gem:
> 1.8: What's the auto keyword good for?
>
> Declaring vehicles.
Regarding your question:
> How is this a good example of hexadecimal input?
It isn't. In C, a leading zero in an integer literal means octal. It compiles and works out, because `7`, `07` and `0x07` happen to have the same value.
Most of them are inside jokes that aren't very funny.
Most of them are indeed frequently asked, but by people who are a bit obstinate or otherwise don't fit the mold that old timers thought newbies should fit.
As a result, the responses are often intentionally dismissive and unhelpful.
EDIT: It occurs to me that comp.lang.c was the 80s-90s version of Stack Overflow. So at least they're comparatively funnier than the SO responses they'd elicit today.
It was better than StackOverflow in a lot of ways.
Sure, it wasn't useful as a searchable database of questions, but the FAQ was very useful if you could spend time to wade through it, and any zero-effort posters were either flamed to oblivion or simply ignored.
I remember asking a couple stupid questions and directed to the documentation. To this day, at work I will suggest "let's see what the manual says", while troubleshooting and get a funny look and eve pushback after I find the answer.
On SO, any of these answers would be downvoted to death by people not recognising them as jokes at all. Language lawyer types would cite the part of the standard that classifies this as UB in the blink of an eye. It’s a different world we’re living in.
They also go me for a while (and I have C in my education but with C/C++ you never know for sure) but when Microsoft invented C I knew something was wrong.
Are the "[a]" footnotes also meant to be "subtly wrong" for shits and giggles?
Footnote 1.5 for instance sounds completely wrong, as if the author is mixing up definition for declaration, and initialisation for definition:
declaration: lets the compiler know the existence of a symbol and its type, without allocating memory for it yet or assign a value. Either of those can happen in a different compilation unit and linked after after the compilation stage. e.g.
extern int bar;
definition: arguably a poor choice of name, but this is the point at which a definitive space in memory is reserved for this variable. If no previous declaration for this symbol has taken place, the symbol is also declared as above too. The value in the newly allocated memory is effectively garbage, since it has not been initialised at yhis step. E.g.
int bar;
initialisation: the assigning of contents into the memory portion that has been allocated for that symbol.
bar = 5;
simultaneous declaration, definition, and initialisation in a single step:
Some great in-jokes there (hands up who gets the EBCDIC one).
More seriously, a lot of the discussions about "undefined behaviour" seem to be aimed at the kind of code that no experienced engineer would write anyway. Until there's a language that's proved formally correct, every language is going to have "undefined" behaviour (though some languages - especially more modern ones - cover more cases/make it harder for less experienced users to blow their foot [or worse, someone elses] off).
Half of it is code no engineer would write and the other half of it occupies 30% of any sufficiently old C codebase. And usually the only way you find out that your clever new optimization is going to break the latter is to write a lot of the former.
I don't want to be toxic but why make a function to cast a char to an int? I was astounded when I briefly skimmed through the list. I hope this is not curriculum in education.
I don't see the one you're talking to on a brief skim, but there are several functions that deal with processing a file character by character. They generally use ints because they need a way to signal end of file and you can't do that with any value of a byte.
> 1.6: I finally figured out the syntax for declaring pointers to functions, but now how do I initialize one?
> With the assignment operator
Well what did you expect right?!