Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: Casting void - int question
Message-ID: <3967@umcp-cs.UUCP>
Date: Wed, 22-Oct-86 00:13:22 EDT
Article-I.D.: umcp-cs.3967
Posted: Wed Oct 22 00:13:22 1986
Date-Received: Wed, 22-Oct-86 22:14:55 EDT
References: <26@orion.UUCP> <393@sdchema.sdchem.UUCP>
Reply-To: chris@umcp-cs.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 36

It is amazing how much discussion one compiler bug can generate!

>In article <26@orion.UUCP> heins@orion.UUCP (Michael T. Heins) writes:
>>
>>int fna() { }
>>
>>void fnb() { }
>>
>>int (*array[32])();
>>main() {
>>    array[0] = fna;
>>    array[1] = fnb; /* This won't work as-is. */
>>}
>>
>>I have tried things like
>>	array[1] = (int (*)())fnb;
>>but this generates the message "operands of CAST have incompatible types".

The cast is correct, but the 4.1 and 4.2BSD compilers misunderstand
void functions.  `void' types in these compilers tend to cause all
sorts of internal indigestion.  This is a bug.

In article <393@sdchema.sdchem.UUCP> tps@sdchema.UUCP (Tom Stockfisch) writes:
>The compiler rightly complains because
>	void (*)()
>could conceivably be larger than 
>	int (*)()
>on some wierd machine.

This is true, but that does not mean the compiler should complain,
or at least not so vociferously.  At most it should issue a warning.
Lint should note the cast as non-portable.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu