NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/tcl/1325

Text File | 1992-09-08 | 3.0 KB | 75 lines

Path: sparky!uunet!sun-barr!olivea!spool.mu.edu!agate!forney.berkeley.edu!jbuck
From: [e-mail] (Joe Buck)
Newsgroups: comp.lang.tcl
Subject: Re: Compiling tcl 6.3 with gcc 2.2.2
Message-ID: <[e-mail]>
Date: 8 Sep 92 23:50:57 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: U. C. Berkeley
Lines: 63
NNTP-Posting-Host: forney.berkeley.edu


In article <[e-mail]> [e-mail] (Joseph C Wang) writes:
>|> >I've also noticed bugs you mentioned (needing -fno-builtin and
>|> >redefining open) on all the platforms I have gcc2.2 on (decmips, vax,
>|> >and rt)
>|>

I wrote:
>|> This is a Tcl bug, as ANSI C and Posix have agreed on what the prototype
>|> for open and other functions is, and the Tcl prototypes don't agree with
>|> the standard.  gcc's builtin definitions and those it builds with the
>|> "fixincludes" script are correct; Tcl is wrong.

In article <[e-mail]> [e-mail] (John Ousterhout) writes:
>I don't understand this, since I believe that the prototypes for open
>and other ANSI functions are identical to what's specified in my ANSI C
>and POSIX manuals.  Can someone provide a bit more detail on exactly
>what the error is?

In compat/string.h, strcmp and a few other functions are declared to
return int.  ANSI says they return size_t.  But this header isn't
ordinarily used unless the configuration step thinks the system one is
invalid.  (Unfortunately, if you use gcc during configuration it will do
just this, so you'll then need to use -fno-builtin).  This problem
doesn't show up on Suns because Sun made size_t int, even though
it is supposed to be an unsigned type (objects cannot have negative sizes).

The problem with "open" turns out not to be that the prototype was invalid,
so I was in error.  The problem with "open" is that <sys/file.h> is
included before the prototype for open in tclUnix.h.  gcc is unhappy if
it first sees a prototype declaration that contains an ellipsis, and then
sees a declaration for the same function with no prototype.  That is,
it sees

extern int open();
...
extern int open(const char* path,int flags,...);

It will accept these two lines if they appear in the reverse order, but
not in this order.  If the full prototype does not have "...", gcc will
take any mixture of the non-prototype declaration and the prototype
version.

The gcc people claim that accepting both declaration forms for the
same function in the same compilation is actually an extension, so I
can't claim that rejecting this one is a bug.  Just the same, since the
input

extern int open(const char *path, int flags, ...);
...
extern int open();
...
extern int open(const char *path, int flags, ...);

also produces the error, it appears that at least in this case the
gcc trick to allow prototype- and non-prototype-declarations to be
mixed doesn't work as one would expect.




--
Joe Buck    [e-mail]