Re: odd compiler behaviour?
[BTW, your Mail-Followup-To: is broken. I guess you need to tell your
mailer what your real address is rather than just "floris".]
On Sat, Mar 15, 2003 at 08:06:33PM +0000, Bruynooghe Floris wrote:
> On Fri, Mar 14, 2003 at 06:12:28PM +0000, Pigeon wrote:
> > #include <stdlib.h> // need this to use malloc()
>
> Well I thought so to, but it _did_ work without to my surprise
> (discovered after I stupidly forgot it)
For largely historical reasons, C lets you get away with unprototyped
functions, to some extent: they default to int(). However, if you're
working on a system such as IA-64, you'll find that int is 32 bits while
void * (malloc()'s return type) is 64 bits. The result of this is that
pointers returned from malloc() will be truncated, usually leading to a
segfault almost immediately afterwards. Thus, unprototyped use of
malloc() is not portable.
Using the -Wall flag (you should) will warn you about such things.
> But using `//' is also a C++ism no?
Certainly traditionally yes, although I don't remember right now whether
C99 allows them (even so, don't use // in portable code). gcc allows it
unless you use the -ansi or -traditional flags, the latter of which you
probably don't want to use the latter unless you're compiling really old
code.
> BTW; thanks to all of you for the replies, I couldn't find this in any
> book (not even K&R).
You should find plenty of stuff about prototyping, and certainly about
declaration order, in the second or later editions of K&R. It may be
slightly cryptic though.
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: