[net.lang.c] void

wrc@brunix.UUCP (04/20/85)

Expires:
References:
Sender:
Keywords:

Can anyone explain this problem with void?  I give a parallel example
with pointers to functions returning ints just as an example that
works.  I don't understand why you can't have a pointer to a function
returning void.

int IntFun() { puts("int"); return (5); }
void VoidFun() { puts("void"); }
int main()
{
    int (*IntPoint)(), i;
    void (*VoidPoint)();

    IntPoint = IntFun;
    VoidPoint = VoidFun;
/* cc and lint: "foo.c", line 10: operands of = have incompatible types */

    i = (*IntPoint)();
    (*VoidPoint)();
    }

swa@talcott.UUCP (Shakalneer) (04/22/85)

> Can anyone explain this problem with void?  I give a parallel example
> with pointers to functions returning ints just as an example that
> works.  I don't understand why you can't have a pointer to a function
> returning void.
> 
>     void (*VoidPoint)();

This is a bug in the c compiler.  I once ran into it on a BSD 4.1 system.
It should work.  It won't.  You'll have to (yeech) declare it of type integer
instead of void.
-- 
Let the beauty we love be what we do.

Steven Augart
{harvard,wjh12}!talcott!swa		(617) 497-7412, 495-3864
swa%talcott@harvard.arpa		AUGART%HARVUNXT.BITNET

gwyn@Brl-Vld.ARPA (VLD/VMB) (04/22/85)

Please, when posting problems like this specify the compiler
you are using.  There is nothing wrong with type (void (*)())
but older versions of PCC (such as the one on 4.2BSD) do not
handle them correctly.

friesen@psivax.UUCP (Stanley Friesen) (04/23/85)

In article <10339@brunix.UUCP> wrc@brunix.UUCP (william cook) writes:
>
>int IntFun() { puts("int"); return (5); }
>void VoidFun() { puts("void"); }
>int main()
>{
>    int (*IntPoint)(), i;
>    void (*VoidPoint)();
>
>    IntPoint = IntFun;
>    VoidPoint = VoidFun;
>/* cc and lint: "foo.c", line 10: operands of = have incompatible types */
>
>    i = (*IntPoint)();
>    (*VoidPoint)();
>    }

	The above is a known bug in the BSD "C" compiler, it has been
reported and is listed in the Mt Xinu Buglist Abstract which is
available over the net.
-- 

				Sarima (Stanley Friesen)

{trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen
or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen

bs@alice.UucP (Bjarne Stroustrup) (08/02/86)

I tried a little program on the three 8th Edition UNIX C compilers:

	cc	- the standard C compiler
	cyntax	- a very competent C checker
	CC	- the C++ compiler

void f1(), f2();
int f3();

void h()
{
	int i;			/* 	cc	cyntax	CC	*/
	f1();			/*				*/
	i = f1();		/*	error	error	error	*/
	f1(),f2();		/*				*/
	f1(),f3();		/*				*/
	i = (f1(),f2());	/*	error	error	error	*/
	i = (f1(),f3());	/*				*/
	i?f1():f3();		/*	error			*/
	i = i?f1():f2();	/*	error	error	error	*/
	i = i?f1():f3();	/*	error	error	error	*/
}

They don't like assigning a void to an int.
They don't mind an operand of ``,'' being void as long as it is not
assigned to anything.
They all agree that the second and third operands of ?: must be of the
same type (modulo standard conversions).
cc insists that an operand of ?: must not be void even if it is not used;
cyntax and CC disagree.

I think cyntax and CC are right. It is inconsistent to allow an operand
to ``,'' to be void provided it is not used and at the same time to disallow
an operand of ``?;'' from being void even when it is not used. I think cc's
behaviour is a leftover from the days where there were no void.