Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!purdue!decwrl!decvax!zinn!mem
From: mem@zinn.MV.COM (Mark E. Mallett)
Newsgroups: comp.unix.microport
Subject: Re: Compile errors on V/386 3.0E
Message-ID: <424@zinn.MV.COM>
Date: 14 Dec 88 14:30:04 GMT
References: <680@wa3wbu.UUCP> <417@zinn.MV.COM> <273@uport.UUCP>
Reply-To: mem@zinn.MV.COM (Mark E. Mallett)
Organization: Zinn Computer Co., Litchfield NH
Lines: 34

In article <273@uport.UUCP> plocher@uport.UUCP (John Plocher) writes:
>In article <417@zinn.MV.COM> mem@zinn.MV.COM (Mark E. Mallett) writes:
>>	extern	(*signal())();
>
>NO!
>
>In ATT System Vr3 (Microport's V/386 2.2 & 3.0e, ISC's 1.0x, BT's 3.0...)
>signal() was changed to be of type void.  This is different from almost
>everyone else (uugh!) but that's how AT&T did it.


"No" is right... as I've been told.  Except, of course, that I was
mostly describing out where the warnings came from and not so much
what the correct signal.h should have in it.  Although signal() is not
of type void, but of type ptr-to-function-returning-void.

(1)	extern void (*signal())();

looks like a better definition than the traditional

(2)	extern int (*signal())();

since in (1), signal() is defined to return a pointer to a routine that
doesn't return anything, and in (2) it returns a pointer to a routine
that returns an int.  Of course, umpty-ump thousands of programs that
use signal() as a (2) will now compile with warnings.  A small
price for perfection :-)


-mm-
-- 
Mark E. Mallett  Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 
Bus. Phone: 603 645 5069    Home: 603 424 8129     BIX: mmallett
uucp: mem@zinn.MV.COM  (  ...{decvax|elrond|harvard}!zinn!mem   )
Northern MA and Southern NH consultants:  Ask me about MV.COM