NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/gnu/misc/discuss/4014

Internet Message Format | 1992-12-16 | 3.6 KB

Xref: sparky gnu.misc.discuss:4014 comp.sys.sgi:18113
Newsgroups: gnu.misc.discuss,comp.sys.sgi
Path: sparky!uunet!stanford.edu!microunity!brendan
From: [e-mail] (Brendan Eich)
Subject: Re: makefile for gnu make on SGI
Message-ID: <[e-mail]>
Sender: [e-mail] (news)
Nntp-Posting-Host: atm.microunity.com
Organization: MicroUnity Systems Engineering Inc.
References: <[e-mail]> <[e-mail]>
Date: Wed, 16 Dec 1992 22:44:21 GMT
Lines: 71

In comp.sys.sgi, "Stephen E. Bacher" <[e-mail]> writes:
| Irix Release 4.0.1 System V (which is where I did the build)
| appears to have __builtin_alloca, as shown in /usr/include/alloca.h,
| which is why I used -Dsparc (which doesn't trigger anything else in
| this particular make).  Is this OK to use, or do I still need to get
| the GNU alloca?

I think the Irix __builtin_alloca works only in certain contexts.
Someone should double-check my memory, but I believe you can't

    array[i] = alloca(1024);

nor can you

    call_a_function(alloca(1024));

There may be other restrictions.  If the man page doesn't treat them,
the release notes may.  Or you could enquire on comp.sys.sgi -- Dave
Anderson will have the answer.

Rather than worry, I just grabbed gcc alloca.c.

| ># Install make setgid to this group so it can read /dev/kmem.
| ># [ Irix allows group sys to read /dev/kmem.  /be ]
|
| [...]
|
| >group = sys
|
| Right.  However, I notice that Irix allows me to do the chgrp to sys for
| a setgid file from an unprivileged account!  Is this right?  Looks like
| a huge hole to me.

No, this is the System V (as opposed to v7/BSD) behavior: you can give
away files that you own to another owner/group.  You can't do this to
files owned by other users or groups, of course.  It creates no security
holes by itself (you can't give away trojan horses if system directories
are protected and root has no . in its path; you can't give away a suid-
[sgid]-to-yourself file without the suid bit being cleared).

| >I did change make.h to define SIGHANDLER as a pointer-to-void-function,
| >not pointer-to-int, #ifndef __STDC__:
| >
| >#define SIGHANDLER      void (*)()
|
| Is this critical?  I'd rather not do source code changes, as a matter
| of general policy, unless absolutely required.

As the default SGI compilation mode in 4.0.x is -xansi, which fails to
define __STDC__, this is necessary unless you add a -D__STDC__ to the
defines macro.  If you define __STDC__ you get a slew of warnings like:

accom: Warning 182: main.c, line 324: void * and function pointers are not convertible to each other
         if (((void * ) signal(((10     )), (void * ) ( (void * ) fatal_error_signal)))         == (void * )    ((SIG_PF)1) )   (void) ((void * ) signal(((10   )), (void * ) (         ((SIG_PF)1) ))) ;       else    fatal_signal_mask |= (1L << ((10        )-1)) ; ;
       ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^

I decided to hack the source, but if you don't mind warning storms, add
the -D__STDC__.  In a future release, SGI's cc will define __STDC__ when
given the (still likely to be default) -xansi option.  The lack of this
define when using -xansi is now considered a mistake.

You could add -cckr to CFLAGS, but I wanted prototype checking.  It has
helped turn out bugs when porting code often enough that I resist falling
back on -cckr or gcc -traditional.

/be
--
-----
Brendan Eich
MicroUnity Systems Engineering, Inc.
[e-mail]