Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!ark
From: ark@alice.UucP (Andrew Koenig)
Newsgroups: net.lang.c,net.bugs
Subject: Re: C Compiler bug (and fix for a different one)
Message-ID: <5910@alice.uUCp>
Date: Wed, 6-Aug-86 09:07:03 EDT
Article-I.D.: alice.5910
Posted: Wed Aug  6 09:07:03 1986
Date-Received: Sat, 9-Aug-86 01:18:12 EDT
References: <111@apple.UUCP>
Organization: Bell Labs, Murray Hill
Lines: 21
Xref: watmath net.lang.c:10174 net.bugs:864

>	Consider the case where you're writing a really complex #define macro,
>and you decide that you'd like some sort of IF statement in it,
>(take a look at getchar()).  Can't you see a case where you might want to
>call a void function, and then set the value of the #define macro to be
>a side effect of the function?  Sort of like
>#define foo(c) buffer_empty?fill_buff(),first_char_in_buf:first_char_in_buf

No problem using a void as the LHS of a comma operator, just as
there's no problem using a void before a semicolon.

Of course, you'd better parenthesize:

	#define foo(c) (empty?(fill(),first):first)

Moreover, fill() probably returns a value you don't want to ignore,
so maybe you should write it to return either the value of first or
an error code.  You can then write

	(empty?fill():first)

which avoids the void issue altogether.