tchrist@convex.com (Tom Christiansen) (04/25/91)
Has not been a particularly pleasant time...
First compiler switches: There's -pcc for old pcc stuff, and -ext for
ANSI C + POSIX + Convex extensions. I opted for -ext, because otherwise
I couldn't get things like waitpid(), since a corporate decision was made
not to extend functionality into pcc mode.
Note that one of the disadvantages of POSIX mode is that your old familiar
system calls won't restart anymore, like read from a slow device or wait.
On the other hand, this saves some complex eval/die stuff when you want to
have a timed out read.
Here are the problems I experienced. I think what most annoys me is that
almost everyone of these is a bogus typing error that the compiler is just
too @!#$$@#%!@ picky about, because if it would just shut up, it would be
fine. Sigh.
1. /lib/libc.a is only for -pcc mode. -ext uses /usr/lib/libc.a;
I fixed this by editing convex.sh and setting libc='/usr/lib/libc.a'.
Would be nice to have a way to select the right libc.
2. System functions get redeclared if __STDC__ isn't defined.
For example, sprintf() is wrongly redeclared in perl.h if
this is so. Sadly, Convex only defines __stdc__ except in strictly
conforming mode. This is fixed by adding a -D__STDC__.
Actually, the right thing is
#if defined(__STDC__) || defined(__stdc__)
3. In doio.c, the socket calls (accept, bind, connect) get called
with middle params of type (char *) instead of (struct sockaddr *)
as their prototypes demand. This can be fixed with casts.
4. Also in doio.c, there are redeclarations of the getpw*() and
getgr*() functions without prototypes. (I'm really getting
to gate these @#$^@#$!@ prototypes.) I fixed this by protecting
them all with #ifndef __STDC__.
5. In eval.c, there is a call to getpgrp(anum). However, in
POSIX, getpgrp() takes no arg, so it doesn't match the prototype
and blows up. This I fixed by an #ifdef __STDC__ in which
the call had no arg, with the #else being what was there before.
(My POSIX guru says this should be #ifdef _POSIX_SOURCE to use
getpgid() instead.)
6. malloc.c declares its own malloc, but the type needs to be
void * so as not to conflict with the system definition.
I changed MALLOCPTRTYPE in config.h to be void.
7. Also in malloc.c, free is declared to be
void free(cp) char *cp;
which screws up the prototype. I changed this to
void free(cp) MALLOCPTRTYPE *cp;
8. Also in malloc.c, realloc needs the pointer to
be of MALLOCPTRTYPE as well.
Re #6-8, My ANSI guru tells me that Thou Shalt Not redefine a C lib
function according to the Rules, so that you really should have MALLOC,
FREE, and REALLOC functions that point to either the system malloc or else
to my_malloc, etc.
It runs now, passes all tests, and solves a coredumping problem I was
having with a massively huge eval.
--tomrbj@uunet.UU.NET (Root Boy Jim) (04/25/91)
<1991Apr24.232208.24472@convex.com>tchrist@convex.com (Tom Christiansen) writes: > >First compiler switches: There's -pcc for old pcc stuff, and -ext for >ANSI C + POSIX + Convex extensions. You need three switches. ANSI C has nothing to do with POSIX. The former describes the translation of symbolic tokens to machine language, while the latter describes the execution environment. ANSI C also specifies semantics of certain library routines, however, they occasionally conflict with POSIX ones. When in doubt, I would go with the POSIX semantics over the ANSI C ones. >I opted for -ext, because otherwise >I couldn't get things like waitpid(), since a corporate decision was made >not to extend functionality into pcc mode. This is bad. There is no reason to disallow this. You can always wimp out, compile normally, and pull waitpid out of the POSIX library to link with. >Note that one of the disadvantages of POSIX mode is that your old familiar >system calls won't restart anymore, like read from a slow device or wait. >On the other hand, this saves some complex eval/die stuff when you want to >have a timed out read. I never liked that change; presumably they (in 4.2BSD) did it so most applications would work in the presence of SIGTSTP. I wish Larry would provide more signal interfacing. You can always do so with syscall however. >Here are the problems I experienced. I think what most annoys me is that >almost everyone of these is a bogus typing error that the compiler is just >too @!#$$@#%!@ picky about, because if it would just shut up, it would be >fine. Sigh. > >1. /lib/libc.a is only for -pcc mode. -ext uses /usr/lib/libc.a; > I fixed this by editing convex.sh and setting libc='/usr/lib/libc.a'. > Would be nice to have a way to select the right libc. The right one is the only one. Why do you have two? You are slipping into the Dual Universe trap. >2. System functions get redeclared if __STDC__ isn't defined. > For example, sprintf() is wrongly redeclared in perl.h if > this is so. Sadly, Convex only defines __stdc__ except in strictly > conforming mode. This is fixed by adding a -D__STDC__. > Actually, the right thing is > > #if defined(__STDC__) || defined(__stdc__) Why do y'all define it in lowercase? What's the difference. I sure hope Larry never uses the return value of sprintf! >4. Also in doio.c, there are redeclarations of the getpw*() and > getgr*() functions without prototypes. (I'm really getting > to gate these @#$^@#$!@ prototypes.) I fixed this by protecting > them all with #ifndef __STDC__. I assume you know how to make fake prototypes? #ifdef __STDC__ #define PROTO(x) x #else #define PROTO(x) () #endif extern int open PROTO((char *path, int flags, int mode)); Perhaps Larry should adopt that style. Perhaps vendors should as well. The above is for declarations; definitions are harder to do. >5. In eval.c, there is a call to getpgrp(anum). However, in > POSIX, getpgrp() takes no arg, so it doesn't match the prototype > and blows up. This I fixed by an #ifdef __STDC__ in which > the call had no arg, with the #else being what was there before. > (My POSIX guru says this should be #ifdef _POSIX_SOURCE to use > getpgid() instead.) Aha! I'm beginning to see. Faced with a conflict, what do you do? Answer: what did Berkeley do? My feeling is that it's time to break some code. However, who actually cares about getpgrp(pid)? Isn't there a getpgrp2 call for people who really do care? >Re #6-8, My ANSI guru tells me that Thou Shalt Not redefine a C lib >function according to the Rules, so that you really should have MALLOC, >FREE, and REALLOC functions that point to either the system malloc or else >to my_malloc, etc. > >It runs now, passes all tests, and solves a coredumping problem I was >having with a massively huge eval. > >--tom -- [rbj@uunet 1] stty sane unknown mode: sane
ronald@robobar.co.uk (Ronald S H Khoo) (04/26/91)
rbj@uunet.UU.NET (Root Boy Jim) writes: > The right one is the only one. Why do you have two? I have several libc.a's, for compiling for different target systems. Yes, I can actually execute the executables of all of them on this system, but not necessarily the other way round ... I'm grateful that Configure now parameterizes the location of /usr/include, but I wish that it wouldn't go ahead an use /lib/libc.a when I'm actually going to link against /221/lib/Slibc.a. Seeing as /lib is going to be in libpth for systems that want /lib/libc.a anyway, why not dispense with the hardcoded /lib/libc.a ? The last time I compiled perl, I used libpth=/ESRCH and xlibpth=/221/lib *and I meant it!* > I assume you know how to make fake prototypes? > extern int open PROTO((char *path, int flags, int mode)); > Perhaps Larry should adopt that style. > Perhaps vendors should as well. The real point is that, for ANSI conformance, you should *not* redeclare stuff that's in the standard haders. So, if __STDC__, you *should* assume that they are adequately declared already. On the other hand, I'd have no truck with __stdc__, adding -D__STDC__ to hints/whatever should be the case, since this is an exception. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)