When does void make code less readable?

[Kevin Szabo]

In article <1995 at sun.uucp> tut at sun.uucp (Bill Tuthill) writes:
 +--------
 |In general, void is A Good Thing.  C routines that return a value
 |are like Pascal functions, while C routines not returning values
 |are like Pascal procedures, and should be declared as void to keep
 |things clear.
 +--------
I thought that just using `return' instead of `return ( expression )'
told lint that the function wasn't returning a value, and hence
the returned value could be ignored. VOID tells lint that a
value is returned but it is ignored. Please correct me if I am wrong!
 +--------
 |However, some system/library routines, such as close(),
 |fclose(), and free() return values that programs don't usually care
 |about.  If the system is unable to close a file, you've got problems
 |that a normal program can't deal with anyway. 
 +--------
I agree. I think it would be a useful thing for routines that normally
"can't" fail, or return values that are ignored 90% of the time, to
provide instead a general `event' handling function. This could probably
look a little like the signal handling stuff. Thus we can have

	event( FAILED_PRINTF, bad_exit );
	event( FAILED_MALLOC, garbage_collect );

By default `events' could probably be a PERROR with an exit(1). This scheme
is not perfect but is much better than having to VOID every
system call that should always work. It is also a lot better
than segmentation faults/bus errors that occur when you try to carry
on after an unchecked system call does fail. Of course, it adds
complexity which is why it wasn't done this way in the first place.

After perusing the manual pages on our machine it looks like the Math
Faculty Computing Facility (at U of Waterloo) has already made a stab
at providing these event handling facilities for their new stuff.
I don't know anything about them though.

					Kevin
-- 
Kevin Szabo  watmath!wateng!ksbszabo (U of Waterloo VLSI Group, Waterloo Ont.)