john@wa3wbu.UUCP (John Gayman) (11/30/88)
I am in the process of compiling NetNews 2.11 patch 8 on a 386 machine running Microport 3.0E. I am getting some warnings that I didn't get when I compiled the same source on Sys V/AT. I had a suggestion to use the Green Hills compiler instead which pretty much works but I was curious if there is someway to patch-out the warnings ? This is an excerp from my make log: cc -O -DUSG -Dindex=strchr -Drindex=strrchr -DRNEWS=\"/usr/bin/rnews\" -DSPOOLDIR=\"/usr/spool/news\" -DBATCHDIR=\"/usr/spool/batch\" -DLIBDIR=\"/usr/lib/news\" -DBINDIR=\"/usr/bin\" -DNEWSUSR=\"news\" -DNEWSGRP=\"news\" -DSCCSID -Dvfork=fork -c control.c "control.c", line 898: warning: illegal pointer combination, op = "control.c", line 899: warning: illegal pointer combination, op = "control.c", line 900: warning: illegal pointer combination, op = cc -O -DUSG -Dindex=strchr -Drindex=strrchr -DRNEWS=\"/usr/bin/rnews\" -DSPOOLDIR=\"/usr/spool/news\" -DBATCHDIR=\"/usr/spool/batch\" -DLIBDIR=\"/usr/lib/news\" -DBINDIR=\"/usr/bin\" -DNEWSUSR=\"news\" -DNEWSGRP=\"news\" -DSCCSID -Dvfork=fork -c funcs.c "funcs.c", line 160: warning: illegal pointer combination, op = "funcs.c", line 161: warning: illegal pointer combination, op = There are a few more compile lines which have the same complaints. If anyone can shed some light on this I would appreciate it. ALso, I will be porting most all the applications Im currently using, (Elm, News, Smail, etc.) to V/386 and would appreciate any pointers on things to look out for when dealing with V/386 in place of Sys V/AT. Thanks. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
mem@zinn.MV.COM (Mark E. Mallett) (12/09/88)
In article <680@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: > > [ with green hills ] > > cc -O -DUSG -Dindex=strchr -Drindex=strrchr -DRNEWS=\"/usr/bin/rnews\" -DSPOOLDIR=\"/usr/spool/news\" -DBATCHDIR=\"/usr/spool/batch\" -DLIBDIR=\"/usr/lib/news\" -DBINDIR=\"/usr/bin\" -DNEWSUSR=\"news\" -DNEWSGRP=\"news\" -DSCCSID -Dvfork=fork -c control.c >"control.c", line 898: warning: illegal pointer combination, op = >"control.c", line 899: warning: illegal pointer combination, op = >"control.c", line 900: warning: illegal pointer combination, op = If your line numbers match up with my sources, which it appears that they do, then perhaps the signal.h for green hills compiler doesn't [properly] declare the signal() routine, or worse, doesn't properly implement it. It should be declared: extern (*signal())(); Now... I didn't realize that you could get Green Hills compiler for Microport. Care to post some details and/or opinions? -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
pim@ctisbv.UUCP (Pim Zandbergen) (12/10/88)
In article <417@zinn.MV.COM> mem@zinn.MV.COM (Mark E. Mallett) writes: > >If your line numbers match up with my sources, which it appears that >they do, then perhaps the signal.h for green hills compiler doesn't >[properly] declare the signal() routine, or worse, doesn't properly >implement it. It should be declared: > > extern (*signal())(); In System V release 3.x on the AT&T 3B2, signal() is declared as extern void (*signal())(); This should be the same with any compiler on any Sys Vr3 system. This usually results in compiler warnings when the return value of signal() is stored in a pointer pointing to a function returning an int. -- --------------------+------------------------------------+--------------------- Pim Zandbergen | CTI Software BV | Phone: +31 70 542302 pim@ctisbv.UUCP | Laan Copes van Cattenburch 70 | Fax: +31 70 512837 ..!mcvax!ctisbv!pim | 2585 GD The Hague, The Netherlands | Telex: 32133 CTI NL
james@bigtex.cactus.org (James Van Artsdalen) (12/10/88)
In <417@zinn.MV.COM>, mem@zinn.MV.COM (Mark E. Mallett) wrote: > [...] the signal.h for green hills compiler doesn't [properly] > declare the signal() routine, or worse, doesn't properly implement it. > It should be declared: > extern (*signal())(); How about: void (*signal(int sig, void (*func)()))(); Green Hills isn't bug free, and it isn't ANSI. Use GNU C (now at v1.31): it's better. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759
john@wa3wbu.UUCP (John Gayman) (12/10/88)
In article <417@zinn.MV.COM>, mem@zinn.MV.COM (Mark E. Mallett) writes: > In article <680@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: > > > Now... I didn't realize that you could get Green Hills compiler > for Microport. Care to post some details and/or opinions? > The compile errors which I indicated were not compiled with Greenhills C but with the standard C-compiler. You do, however, get the Greenhills C compiler standard with the Microport V/386 3.0e release. One suggestion I received was to use the Greenhills compiler in place of the normal one and this in fact eliminated the warning messages. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
plocher@uport.UUCP (John Plocher) (12/12/88)
In article <417@zinn.MV.COM> mem@zinn.MV.COM (Mark E. Mallett) writes: >In article <680@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: >> >> [ with green hills ] >> >> cc -O ... -c control.c >>"control.c", line 898: warning: illegal pointer combination, op = ... > > perhaps the signal.h for green hills compiler doesn't >[properly] declare the signal() routine, or worse, doesn't properly >implement it. It should be declared: > > 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. (from <signal.h>) extern void(*signal())(); extern void(*sigset())(); The news code assumes signal() is of type int; signal.h declares it as type void, and the compiler says "oops", just like it should. The >>warning<< >>seems<< to be ignorable. Under the DIAGNOSTICS section of signal(2) it says: "Upon successful completion, SIGNAL returns the previous value of FUNC for the specified signal SIG. Otherwise a value of SIG_ERR is returned and errno is set to indicate the error. SIG_ERR is defined in the include file SIGNAL.H." I thought type void meant "nothing returned", yet signal is clearly type void and it returns something! What don't I understand here? :-) John Plocher
dave@pmafire.UUCP (Dave Remien) (12/13/88)
[stuff about signal type declarations deleted] > >I thought type void meant "nothing returned", yet signal is clearly type void >and it returns something! What don't I understand here? :-) Any more about AT&T than the rest of us do? I.E., not much? ;-). > > John Plocher -- Dave Remien - WINCO Computer Engineering Group (only somewhat confused, now) 208-526-3523 Paths: ...!bigtex!pmafire!dave | ...!ucdavis!egg-id!pma386!dave
kjk@pbhyf.PacBell.COM (Ken Keirnan) (12/13/88)
In article <273@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: [ stuff about declaration of signal deleted ] > >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. > >(from <signal.h>) > > extern void(*signal())(); > extern void(*sigset())(); > [ more stuff deleted ] > >I thought type void meant "nothing returned", yet signal is clearly type void >and it returns something! What don't I understand here? :-) > > John Plocher Actually, the declaration of signal() above doesn't say that signal() returns void, but rather that signal() returns a pointer to some function that returns "void". Therefore, any function name given to the signal() call should be declared void: void doexit() { (void)printf("\nGoodbye\n"); exit(0); } ... ... ... (void)signal(SIGINT, doexit); ... ... Hope this helps. Ken Keirnan -- Ken Keirnan - Pacific Bell - {att,bellcore,sun,ames,pyramid}!pacbell!pbhyf!kjk San Ramon, California kjk@pbhyf.PacBell.COM
scjones@sdrc.UUCP (Larry Jones) (12/13/88)
In article <273@uport.UUCP>, plocher@uport.UUCP (John Plocher) writes: > (from <signal.h>) > extern void(*signal())(); > extern void(*sigset())(); > > Under the DIAGNOSTICS section of signal(2) it says: > "Upon successful completion, SIGNAL returns the previous value of FUNC for > the specified signal SIG. Otherwise a value of SIG_ERR is returned and > errno is set to indicate the error. SIG_ERR is defined in the include > file SIGNAL.H." > > I thought type void meant "nothing returned", yet signal is clearly type void > and it returns something! What don't I understand here? :-) The declaration. It says that signal is a function which returns a pointer to a function that returns nothing. Thus, signal is not a void function, the signal handler function that it returns a pointer to is. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@sdrc.uucp 2000 Eastman Dr. BIX: ltl Milford, OH 45150 AT&T: (513) 576-2070 "Save the Quayles" - Mark Russell
wietse@wzv.UUCP (Wietse Z. Venema) (12/13/88)
In article <273@uport.UUCP> plocher@uport.UUCP (John Plocher) writes:
# (from <signal.h>)
#
# extern void(*signal())();
# extern void(*sigset())();
#
# The news code assumes signal() is of type int; signal.h declares it as type
# void, and the compiler says "oops", just like it should. The >>warning<<
# >>seems<< to be ignorable.
# [...]
# I thought type void meant "nothing returned", yet signal is clearly type void
# and it returns something! What don't I understand here? :-)
#
# John Plocher
Actually, signal is not of type void:
cdecl> explain void(*signal())()
declare signal as function returning pointer to function returning void
So it really is declared as returning something...
--
work: wswietse@eutrc3.uucp | Eindhoven University of Technology
work: wswietse@heitue5.bitnet | Mathematics and Computing Science
home: wietse@wzv.uucp | 5600 MB Eindhoven, The Netherlandsmem@zinn.MV.COM (Mark E. Mallett) (12/14/88)
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