Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.lang.perl
Subject: Re: compiling perl 4.003 on a Convex
Message-ID: <130322@uunet.UU.NET>
Date: 25 Apr 91 01:26:15 GMT
References: <1991Apr24.232208.24472@convex.com>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 101

<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