Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: I want to ask a question... Date: Wed, 19 Aug 2015 20:25:35 -0700 Organization: None to speak of Lines: 51 Message-ID: References: <87pp2y7wl7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="24090"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eRia95P3cfyPiPREKbIDt" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:ij7EnEaV+3WrwoSyS+Zb7T4agfM= sha1:JCwO6vlUGs/P76KnMiMoTwIWC/U= Xref: csiph.com comp.lang.c:67865 glen herrmannsfeldt writes: > Keith Thompson wrote: >> supercat@casperkitty.com writes: > > (snip) >>> If a pointer isn't null, doesn't identify a valid object, and isn't a >>> "one-past" pointer of a valid object, even something as seemingly-benign as > >>> free(ptr); >>> if (condition1) {foo(); ptr=NULL;} >>> if (condition2) {bar(); ptr=NULL;} >>> if (ptr != NULL) printf("Forgot to clear out pointer!"); > >>> may cause some compilers to infer that if condition1 is false, bar() >>> should be called unconditionally since the Standard would not require >>> that the compiler evaluate condition2 in such case. Unfortunately, >>> some compilers writers seem to think that such "optimizations" are a >>> good thing. > >> The code has undefined behavior if condition1 and condition2 are both >> false. > > I completely agree that it is official UB. > >> Since the code is incorrect, it shouldn't matter much how it behaves. >> But it would be nice if the compiler printed a warning. > > I suppose a warning is fine, but on most processors it isn't > all that hard to do what the program says. Doing the optimization > and then not warning about it is mean. Legal, but mean. What do you mean by "what the program says"? As far as the C standard is concerned, the program has no meaning if condition1 and condition2 are both false. Even ignoring the optimizations permitted by the standard, if both conditions are false the program accesses the value of a dangling pointer. On some plausible target systems, that could at least cause the program to crash. > How about a special option that enables this kind of optimization, > so it can be turned off when one doesn't want it. If a compiler vendor wants to provide such an option, that's fine with me. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"