Subject: Re: bin/23988: egcs: cc -traditional totally broken
To: Martin Husemann <>
From: VaX#n8 <>
List: netbsd-bugs
Date: 01/07/2004 00:33:55
Summary: It's not a compiler bug.  Not sure what to call it.

In message <>, Martin Husemann writes:
>Your test program does not show that.

I was pretty tired and frustrated, having spent all night on the problem.
Anyway, that's why I mentioned it.  I tried opening and lseeking by attaching
gdb to the (original, much more complex) process and using the "print"
command to execute those syscalls.

>You need to add the proper includes,
><unistd.h> and <netdb.h>, to have the right prototypes in scope. Especially
>since lseek takes a 64 bit int as it's second argument, so argument promotion
>does matter. Now you're probably calling it with a random third "whence"

I had those includes in my test program before I pared it down to a bare
minimum.  Hmm... since -traditional implies -U__STDC__, I wonder if that is
avoiding some prototypes necessary for proper function.  I know it causes
some compilation problems with __RENAME of stat to __stat13, etc.  Somehow
__RENAME gets turned into __asm__('x') or something like that.  Aha!

I added a call to lseek just to see what was going on.  Looking at the x86
assembly, here is the call to lseek:

        pushl $0
        pushl $0
        movl -4(%ebp),%eax
        pushl %eax
        call lseek

Adding this line to the source seemed to fix things:

        off_t lseek(int, off_t, int);

Note that #include <unistd.h> does *not* fix things, as __P() is defined
away and thus it sees this:

        off_t lseek();

So... this is not a compiler bug, but rather an interaction of -traditional
(specifically -U__STDC__), and the include files.  I don't know what to label
this, someone who understands this better than me will have to reclassify
this PR.  Is it a bug?  Design decision?  Tautology?  Hmm.

Incidentally, if anyone can tell me who the expert on rpcgen is, I'd like
to talk to them.  All this -traditional nonsense was an attempt to trick
our rpcgen into classic Sun rpcgen behavior (no _svc suffixes, etc) in
order to compile an old and unsupported application.  I really don't know
what I'm doing and can't seem to find sufficient documentation on rpcgen
and how it has evolved.