Probably correct on some compilers. However, this is far from the only
place where it is assumed the compiled manages a sequence point at ? and
only evaluates the correct alternative.
According to all C documentation I have been able to find this should be
the case, but it has been indicated that not all compilers follows this
rule in all cases. If they don't I think the compiler is broken until
proven othervise.
I.e. to all my knowledge the following two code fragments SHOULD be
identical in the absense of sideefects in the expression d.
d = a ? b : c;
if (a)
d = b;
else
d = c;
Or more expressive, if you write
a ? b() : c()
then b is called IFF a is true, and c called IFF a is false
a ? b->c : d
then b is dereferenced as part of the evaluation of b->c IFF a is
true. If a is false then only d is evaluated and b is never
dereferenced.
a ? b++ : c++
then the sideeffect b++ is executed IFF a is true, and c++ IFF a is
false.
b=1;
a[b++] ? b : c
should evaluate to 2 (b++) if a[1] is true, c otherwise.
If you have any C alnguage information which contradicts this then I
would be very glad to know.
-- Henrik Nordstrom Squid Hacker Zhang Luwei wrote: > > Hi all, > > I am Zhang Luwei again, the Masters Research Student from the > National University of Singapore (NUS). I have just looked upon the patch > at the url below for refreshIsCachable method: > > http://squid.sourceforge.net/hno/patches/squid-2.1.PATCH2.dont_cache_unrefreshable.patch > > In the code under the method refreshIsCachable, we have: > > rep = entry->mem_obj ? entry->mem_obj->reply : NULL; > > Would like to suggest a better patch. My suggestion is based on the > assembly theory. The patch above, when transformed into assembly language, > may cause instability in the proxy server. > My suggestion to a better way to write the line will be: > > if (entry->mem_obj && entry->mem_obj->reply && (entry->mem_obj->reply->content_length == 0)) > return 0; > > Hope my suggestion helps, > Hope to hear from all of you soon. > > Best regards, > Truly yours, > LuweiReceived on Mon Jul 02 2001 - 08:42:55 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:05 MST