Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!gdt!gdr!exspes
From: exspes@gdr.bath.ac.uk (P E Smee)
Newsgroups: comp.lang.c
Subject: Re: Compilers and programming style (was Re: A question of style)
Message-ID: <1990Jan5.100042.26760@gdt.bath.ac.uk>
Date: 5 Jan 90 10:00:42 GMT
References: <1989Dec22.100135.2903@gdt.bath.ac.uk> <4367@rtech.rtech.com> <1989Dec31.153241.16479@gdt.bath.ac.uk> <649@codonics.COM>
Reply-To: exspes@gdr.bath.ac.uk (P E Smee)
Organization: University of Bristol c/o University of Bath
Lines: 53

In article <649@codonics.COM> bret@codonics.com (Bret Orsburn) writes:
>In article <1989Dec31.153241.16479@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes:
>>>
>>>	*ptr;		/* Should be (*ptr)(), of course */
>>
>>while valid as written, clearly has no effects and no side effects.
>
>Let me get something clear: are_you/is_anybody claiming that *all* isolated
>pointer dereferences are inherently worthless (hence, fair game for whining
>compilers), or would you reserve this judgement just for the special case of
>an isolated pointer-to-function?

Did you miss the beginning of this chain, then?  I *was* claiming that
isolated pointer deferences to *functions* had no effects and no
side-effects.  I was *also* saying, though, that as the construct is
valid C, the compiler has *no business* whining (I used 'chatting', but
the idea's the same) about it, unless the user has used some special
command-line -switch which means 'I want to get whined at'.  I was
claiming even more strongly that a compiler should not, (at least as
its default behaviour) put out messages complaining about constructs
which are linguistically valid.

>If you are making the former, stronger claim, I could cite a lot of counter-
>examples from the realm of Systems Programming (read: Pounding on Hardware).

Probably.  I have since (in continued email discussion with various
people) realised that I can think of at least one context from my past
experience where I would expect 'isolated pointer dereference to a
function' to cause (machine-dependent) meaningful side-effects.  I was
already aware of the possible (mchine/system dependent) uses for
apparently isolated dereferences of other pointers, so would agree that
the stronger claim is incorrect.  I am now of the opinion that even the
weaker claim is not always correct.

And, I'd reiterate, even if something is patently, obviously, provably
always useless, if it is linguistically valid the default behavior of
the compiler should be to accept it.  Silently.

I would add two more threads to this, though.  The compiler has to do a
fair amount of flow analysis (particularly if it tries any
optimisation) and so it would be handy, IMHO, if compilers included a
(non-default) -switch which said 'I would like you to whine about
anything you don't understand'.  And I think it would be useful to have
a 'noddy' compiler for less computer literate users (I see a lot of
them) which DID put out excessive warnings, alongside the 'professional
production' compiler which didn't.  In order that the two have a
consistent view of the language, I would actually suggest that they
ought to be the same program, accessed by different names, in the
manner of vi/view/ed on Unices.

-- 
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
 Smee@bristol.ac.uk  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)