> 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?!
> long ints can be entered using hexadecimal notation; for instance,
> long int foo = 07;
How is this a good example of hexadecimal input?
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.
That is a hilariously beautiful and simple example to communicate that.
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.
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.
Why do i find your anwer very funny ?
The answers are more informal than a proper one because they make you think and challenge the answer.
You shouldn't take every sentence as truth.
main() { int foo = 08; }
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: int bar = 5;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).
> Comes to a website that's very well known to be mostly frequented by programmers
> Complains about the content that tries to appeal to programmers
sigh