3 ms·
None of these are especially interesting C questions... Most rely on assumptions about the x86 architecture and GCC (stack grows downwards, ordering of stack va
by throwaway54-762 14y ago
None of these are especially interesting C questions... Most rely on assumptions about the x86 architecture and GCC (stack grows downwards, ordering of stack variables in memory (not registers), ...).
#3 notes a warning for main not returning int, but doesn't point out that without stdlib.h, malloc() and free() will be declared implicitly with incorrect types. (Edit: this produces a warning on 4.7 GCC and Clang 3.0.)
Almost all of these questions have something wrong with them other than what the author is pointing out. I question the author's familiarity with C.
- peteri 14y agoAlso the casts to (char *) from malloc suggest that the author is a C++ programmer.
- eswangren 14y agoI left the same comment before I saw yours. Whoever wrote this does not know C, they think they do because the use C++.
- pfedor 14y agoThere's a discussion in "The Practice of Programming" of which is a better style when programming in straight C. The argument for casting was that could make porting to C++ easier. The argument against it went like that (hope I'm not botching it): if the appropriate header file was not included and consequently malloc() was implicitly assumed to return an int, then without a cast assigning the return value of malloc to say char* would likely trigger a warning, but the cast will silence the warning. This could be a real bug if the convention for returning an int was different from returning a pointer (say if one was returned via a register and the other wasn't.)
- peteri 14y agoOr if you were programming on an 8086 in large memory model where int is 16 bit and a pointer is 32 bit (16 bit segment, 16 bit offset) This makes me wonder if anyone ever did a compiler where malloc returned a segment + offset (I think that gives a 48 bit pointer) for a 386 class machine.