Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! |
| Date | 2011-11-28 14:59 -0800 |
| Organization | None to speak of |
| Message-ID | <lnipm3svjd.fsf@nuthaus.mib.org> (permalink) |
| References | (2 earlier) <459390d2-53c4-49cc-9b97-c25337d9007e@o5g2000yqa.googlegroups.com> <4ed0c94d$0$1387$4fafbaef@reader2.news.tin.it> <EI7Aq.35597$t37.31719@newsfe14.iad> <lnvcq4sh88.fsf@nuthaus.mib.org> <GuQAq.8954$g35.8441@newsfe09.iad> |
Lew Pitcher <lpitcher@teksavvy.com> writes:
> On November 28, 2011 04:56, in comp.lang.c, kst-u@mib.org wrote:
>> Lew Pitcher <lpitcher@teksavvy.com> writes:
>>> On November 26, 2011 06:11, in comp.lang.c, superpollo@tznvy.pbz wrote:
>>>> Lew Pitcher ha scritto:
>>> [snip]
>>>>> for (p = 0; p < P; ++p)
>>>>> {
>>>>> e[0] = 0;
>>>>> multiply(e,10,I+X);
>>>>> fputc(e[0]+'0',stdout);
>>>>> if (p%5 == 4)
>>>>> if (p%50 == 49)
>>>>
>>>> here my compiler says:
>>>>
>>>> temp.c: In function ‘main’:
>>>> temp.c:50: warning: suggest explicit braces to avoid ambiguous ‘else’
>>
>> The code in question is:
>>
>> if (p%5 == 4)
>> if (p%50 == 49)
>> fputs("\n\t",stdout);
>> else
>> fputc(' ',stdout);
>>
>>> The C standard is pretty clear about the association of <<else>> to the
>>> appropriate <<if>>For instance, in IEC 9899-1999, section 6.8.4.1 ("The
>>> if statement"), point 3, it says:
>>> "An else is associated with the lexically nearest preceding if that is
>>> allowed by the syntax."
>>>
>>> That doesn't seem very ambiguous to me.
>>
>> It's not ambiguous at all as far as the language is concerned, but it
>> could be ambiguous to a human reader.
>>
>>> I suggest that your compiler's warning level is wound up too tight. I
>>> know that compilers are permitted to emit warnings for anything they
>>> want, from noting potential syntax errors to baying at a full moon. That
>>> doesn't mean that the compiler doesn't know what to do with the code, or
>>> that the code violates the C standard in any way. It just means that the
>>> compiler writer thought that the programmer would like to know something.
>>
>> I disagree. The warning is an important one. The solution (though it's
>> not required by the language) is to add braces:
>>
>> if (p%5 == 4) {
>> if (p%50 == 49) {
>> fputs("\n\t",stdout);
>> }
>> else {
>> fputc(' ',stdout);
>> }
>> }
>
> I've worked in shops that required "clean" (no errors, no warnings)
> compiles. Often the programmers took very convoluted steps to ensure
> compliance (granted, this was in COBOL, so compliance became very wordy).
>
>> Certainly you can turn off the warning if you like, but I wouldn't (and
>> frankly I probably wouldn't see the warning in the first place when
>> compiling my own code).
>
> I agree that warnings are good to see. But, taking concern when the warning
> warns you that the code will do /what you intended it to do/ seems just
> silly to me. And, that's the point I was trying to get across (obviously,
> poorly).
>
> Of course, the programmer has (at least) three options:
> 1) to confirm that the warning can be ignored (because it warns about
> a /wanted/ condition).
> 2) to ignore or disable warnings, or
> 3) to change the code so that the warning goes away.
>
> In the above example code, you seem to advocate option #3.
>
> However, I /know/ (from your past postings) that you don't believe this in
> all cases. How do I know? Well, because you regularly advocate for option
> #1 or option #2 when people complain that their call to malloc() results in
> a warning. You /definitely/ don't like option #3 in those cases, because in
> practice it results in code that uses a cast of malloc()s return value to
> eliminate the warning. You know the dangers of that sort of code fix as
> much as I do.
Hmm. Warnings on calls to malloc() often result from a missing
"#include <stdlib.h>". One way to avoid the warning is to add a
cast; the *right* way is to leave the cast out and add the required
#include directive. Of course I don't advocate the first solution,
which silences the warning while leaving the program with undefined
behavior. Adding the #include is an instance of #3.
Or are you talking about some other problem with malloc() calls?
In any case, I don't have a general rule about how to deal with
warnings. There are cases where I dislike changing the code to
deal with an overly picky compiler. For example, if "do { ... }
while (0)" in a macro definition results in a warning that the
condition is always false, that's just too bad; it's the right
way to do it. Similarly, "some_complicated type obj = { 0 };"
may trigger a warning about missing initializers; that's just the
compiler being insufficiently clever in recognizing a perfectly
good idiom.
> In any case, I originally wrote that code as a learning experience, and
> didn't intend it to be an example of "best practices". I, too, watch the
> warnings, and evaluate the code that such messages highlight. But, I know
> when to ignore warnings when they tell me that what I'm doing is what I
> intended to do.
My own preference would be to write
if (cond1)
if (cond2)
something;
else
something;
as
if (cond1) {
if (cond2) {
something;
}
else {
something;
}
}
*whether the compiler warns about it or not*. I use braces for
all control structures, even when they're not strictly necessary.
I'll sometimes omit the braces if the whole thing fits on one line,
but that's uncommon. (It's a habit I picked up from Perl, where
they're always required, but I think it's a good idea for C anyway.)
If I were *really* strict about this, I'd add lots of extra braces to
"if .. else if ... else if ... else ..." chains, but that's such
a common idiom that I treat them as linear rather than nested.
I do not claim to be 100% consistent.
Of course not everyone follows the same style rules I do. (Of course
*THEY SHOULD*!!!1!!!).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread
OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-20 11:12 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Ian Collins <ian-news@hotmail.com> - 2011-11-21 08:18 +1300
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-20 20:22 +0100
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-20 11:23 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-20 15:03 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Kaz Kylheku <kaz@kylheku.com> - 2011-11-20 20:06 +0000
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-20 12:13 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Ian Collins <ian-news@hotmail.com> - 2011-11-21 09:16 +1300
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-20 15:37 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-20 14:15 -0700
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-20 13:45 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-21 00:44 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-21 12:44 +0200
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-21 10:41 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-21 00:53 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! "io_x" <a@b.c.invalid> - 2011-11-24 19:08 +0100
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Martin Ambuhl <mambuhl@earthlink.net> - 2011-11-20 17:32 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Keith Thompson <kst-u@mib.org> - 2011-11-20 14:55 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-20 16:54 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Keith Thompson <kst-u@mib.org> - 2011-11-20 19:35 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-22 00:39 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Keith Thompson <kst-u@mib.org> - 2011-11-22 13:18 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-24 01:50 -0800
Re: Euler's constant jacob navia <jacob@spamsink.net> - 2011-11-21 12:45 +0100
Re: Euler's constant Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-21 13:54 +0100
Re: Euler's constant jacob navia <jacob@spamsink.net> - 2011-11-21 14:48 +0100
Re: Euler's constant Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-21 18:58 +0100
Re: Euler's constant Markus Wichmann <nullplan@gmx.net> - 2011-11-21 14:10 +0100
Re: Euler's constant jacob navia <jacob@spamsink.net> - 2011-11-21 15:36 +0100
Re: Euler's constant 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-21 07:08 -0800
Re: Euler's constant jacob navia <jacob@spamsink.net> - 2011-11-21 16:16 +0100
Re: Euler's constant Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-22 00:44 -0800
Re: Euler's constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-21 15:33 +0000
Re: Euler's constant Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-21 08:50 -0800
Re: Euler's constant "BartC" <bc@freeuk.com> - 2011-11-21 17:13 +0000
Re: Euler's constant James Kuyper <jameskuyper@verizon.net> - 2011-11-21 12:29 -0500
Re: Euler's constant Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-21 09:28 -0800
Re: Euler's constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-21 23:07 +0000
Re: Euler's constant Kaz Kylheku <kaz@kylheku.com> - 2011-11-21 17:29 +0000
Re: Euler's constant James Kuyper <jameskuyper@verizon.net> - 2011-11-21 12:36 -0500
Re: Euler's constant Keith Thompson <kst-u@mib.org> - 2011-11-21 13:46 -0800
Re: Euler's constant "io_x" <a@b.c.invalid> - 2011-11-24 19:08 +0100
Re: Euler's constant Markus Wichmann <nullplan@gmx.net> - 2011-11-24 20:31 +0100
Re: Euler's constant "io_x" <a@b.c.invalid> - 2011-11-27 11:24 +0100
Re: Euler's constant Markus Wichmann <nullplan@gmx.net> - 2011-11-27 12:09 +0100
Re: Euler's constant "io_x" <a@b.c.invalid> - 2011-11-27 13:33 +0100
Re: Euler's constant Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-21 10:44 -0800
Re: Euler's constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-21 22:53 +0000
Re: Euler's constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-21 23:51 +0000
Re: Euler's constant 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-22 04:17 -0800
Re: Euler's constant 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-27 17:50 -0800
Re: Euler's constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 03:09 +0000
Re: Euler's constant 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-28 02:52 -0800
Re: Euler's constant Seebs <usenet-nospam@seebs.net> - 2011-12-28 18:17 +0000
Re: Euler's constant Dr Nick <3-nospam@temporary-address.org.uk> - 2011-12-28 18:49 +0000
Re: Euler's constant 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-04 04:44 -0800
Re: Euler's constant Robert Wessel <robertwessel2@yahoo.com> - 2012-01-04 12:33 -0600
Re: Euler's constant 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-21 15:07 -0800
Re: Euler's constant "io_x" <a@b.c.invalid> - 2011-11-24 19:08 +0100
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-21 04:00 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-11-21 12:37 +0000
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-21 04:45 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-11-21 13:35 +0000
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-22 00:01 +0200
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-11-22 11:53 +0000
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Keith Thompson <kst-u@mib.org> - 2011-11-22 13:21 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Kleuske <kleuske@nowhere.net> - 2011-11-24 14:50 +0000
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! "io_x" <a@b.c.invalid> - 2011-11-24 14:08 +0100
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! "io_x" <a@b.c.invalid> - 2011-11-24 18:02 +0100
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-25 15:31 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-25 17:40 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-25 22:03 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-25 22:43 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Joe Wright <joewwright@comcast.net> - 2011-11-26 02:13 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-26 19:40 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-27 15:35 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Ian Collins <ian-news@hotmail.com> - 2011-11-26 20:22 +1300
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-26 10:55 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Seebs <usenet-nospam@seebs.net> - 2011-11-28 08:32 +0000
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! superpollo <superpollo@tznvy.pbz> - 2011-11-26 12:11 +0100
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-26 10:37 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! superpollo <superpollo@tznvy.pbz> - 2011-11-26 21:48 +0100
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Keith Thompson <kst-u@mib.org> - 2011-11-28 01:56 -0800
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-28 13:34 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! James Kuyper <jameskuyper@verizon.net> - 2011-11-28 13:45 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-28 13:50 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! James Kuyper <jameskuyper@verizon.net> - 2011-11-28 14:32 -0500
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Kleuske <kleuske@nowhere.net> - 2011-11-28 21:16 +0000
Re: OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!! Keith Thompson <kst-u@mib.org> - 2011-11-28 14:59 -0800
csiph-web