Re: Ping from C/C++ doesn't work properly using either System() or popen()

"James J. Dines" <james.dines@xxxxxxxxx> wrote:
Floyd L. Davidson wrote:

"James J. Dines" <james.dines@xxxxxxxxx> wrote:
Floyd L. Davidson wrote:
"James J. Dines" <james.dines@xxxxxxxxx> wrote:
<snip>

Yes ... but quoting the ANSI standard is a red herring. There is no
guarantee a given compiler will even be ANSI C compliant.

If the compiler is not ANSI C compliant, it is not a C compiler.


Hopefully you know the patent absurdity of this statement. Certainly, you
acknowledge the existence of K&R C - perhaps you knew it was a compiled
language from the start, *before* the ANSI committee got hold of C?

A compiler that does not claim ANSI C compliance is *not* a C
compiler in today's world.

I'll stand by that statement. If you want to argue it, I would
suggest either going to comp.lang.c or comp.std.c and ask about
what folks there think. Or you can save yourself the trouble
and just use google...

Can you find even *one* compiler that claims to be C that has
*ever* done it differently?

No. I always use sizeof(char), so it wouldn't effect me if there was.
Perhaps 1 will *always* work, but I have yet to hear of a single time when
it is *better*, unless you are willing to sacrifice consistency

"sizeof (char)" has always been 1 (by definition even in the
original K&R C), is defined by the ISO/ANSI Standard as 1, and
is always going to be 1.

And here (above) is where you contradict your own claim that if it ain't
ANSI, it ain't C. (K&R_C != ANSI_C).

That is *not* a contradiction.

It is helpful in code
reviews to be explicit, and there is absolutely no drawback (again, that I
can think of, or find in my research to date.)

The only effect of writing "sizeof(char)" is a demonstration
that the programmer has less knowledge of C than a person who
writes 1 instead.

No. It demonstrates that I understand the software engineering process.
Programmers use 1, software engineers use sizeof(char).

Being careful to plan for a fundamental change in the C Standard's
basic definitions (that char = byte) is *not* engineering.

More information on portability can be found here:

http://hebb.cis.uoguelph.ca/~dave/27245/Lectures/portability.html

A poorly written page. The information he is trying to relate
is correct, but the lack of a statement that "sizeof(char)" is
defined as 1 makes it less clear than it would otherwise be.

No. His point is excellent. Using 'sizeof(char), sizeof(int)' is
consistent, and '1, sizeof(int)' is inconsistent.

It is consistent for a demonstration, and I did not take
exception to that. The problem was that he never even mentioned
the fact that sizeof (char) is defined as 1, which leads people
to thinking that normal useage the way you do is indeed
necessary. It is unnecessary.

Using sizeof(char) recognizes that there is a layer of abstraction between
the code and the compiled result, and encourages people to minimize
assumptions and be consistent. It exemplifies that art of being explicit
rather than ambiguous or vague.

Sounds like you belong in marketing, not production. :-)

Regardless, you can't sell that here.

He could have pointed out that sizeof(char) is 1, but only if he cautioned
*against* the inconsistency of using sizeof() for all datatypes except
char.

That is silly.

Here is what the C FAQ says,

<snip - content available in parent post>

Thanks for your help on that. It was very informative, and you *are* quite
knowledgeable. Overall, I am quite impressed.

Please be advised that I am not a language lawyer by any means. I'm well
read though. :-) What I actually do know *very* well is the reception
you will receive from real language lawyers if you take these arguments
over to comp.lang.c. I'm being nice, they might not be...

Go to google and search comp.lang.c archives for references to
"sizeof(char)" and what you'll find are comments similar to my
statement that it merely indicates less knowledge of C than a
programmer who uses 1 (or nothing if it is a multiplier).


"Yes, imo the 'sizeof(char)' is simply unnecessary clutter."

"... (sizeof (char)) seems to indicate that the author
doesn't quite understand what is going on."

"... sizeof(char), while not technically incorrect, is
totally pointless."

">sizeof(char), while not technically incorrect, is
>totally pointless.

Agreed ..."

Well ... I could go to any newsgroup, including that one, and show you some
patently absurd comments.

Except those are not absurd statements by people who missed a clue. At
least one of those is from someone who has written one of the better
books on learning C.

A newsgroup post from john whoishe has no
intrinsic value. I was looking more for a quote from Dennis Ritchie, or
Bruce Eckel, or Bjarne Stroustop ... that kind of thing ... and a reason
*not* to do it.

Dennis Ritchie of course does not make definitive statements on
Usenet about what C is or should be. He does, however, have a
great interest in history and sometimes writes about what C once
was or how it came to have something. He infrequently posts to
alt.folklore.computers.

I don't pay attention to C++, hence I'm not sure what Bruce
Eckel or Bjarne Stroustop might do or not do.

Regardless, for C what you really want is viewpoints from people
who are extremely familiar with the ISO/ANSI C Standard. You
cannot say *anything* on comp.lang.c without it being
scrutinized by probably more than one person who is on the
Standards Committee, and by several others who are equally able
to interpret the Committee's actions.

I would highly suggest that you post some of your concepts there,
put on an asbestos jump suit, and try to support your view.

I have already shown that it is not totally pointless
(again, the point is consistency.) I am glad to see that the quotes you
used were careful to say imo and seems.

Yes, it seems nobody agrees with you.

Note though that it in fact never does any harm to the program!

So we agree that it never harms. I have shown why it sometimes helps.
(Improves readability and is consistent with sizeof(int), etc.)

In your mind, yes. Nobody seems to agree with that.

Well, I guess that means it is always a good idea IMNSHO. You may not agree.
Reasonable people can disagree. I guess - for me - it is a keeper, Random C
Poster's comments not withstanding ;-)

(No disrespect to your excellent and thoughtful commentary on the subject
intended either)

Ironically enough, I was thinking more along the lines of C++ and the
possibility that char would be over-ridden originally (recall the original
poster wasn't clear if using C or C++ though his code was "very C"), but I
haven't had time to follow up on that. I would imagine it is something
that cannot be done, and I certainly would never do it if one could, but as
we both know, that won't necessarily stop a lot of people ...

I really would like to encourage you to carefully ask about this in
comp.lang.c and get a more definitive answer from people you can
verify as experts.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@xxxxxxxxxx
.

Relevant Pages

  • ANSI C compliance
    ... "My boss would fire me if I wrote 100% ANSI C code" ... standard which is defined by an international committee. ... as intended on all platforms for which you have an ANSI C compiler, ... Writing truly standard C as valued by the "regulars" ...
    (comp.lang.c)
  • Re: Ping from C/C++ doesnt work properly using either System() or popen()
    ... but quoting the ANSI standard is a red herring. ... guarantee a given compiler will even be ANSI C compliant. ... If the compiler is not ANSI C compliant, it is not a C compiler. ... consistent, and '1, sizeof' is inconsistent. ...
    (comp.os.linux.networking)
  • Re: K&R Ex 1-3
    ... The ANSI C ... Standard of 1989 was a significant step forward for C. ... Given a choice between the best C compiler ever written for the Apple ...
    (comp.lang.c)
  • Re: ANSI C compliance
    ... > We are discussing whether this newsgroup should focus on 100% ANSI C ... > is a C standard which is defined by an international committee. ... behaviour of programs compiled with a C compiler, ... vendor then there are newsgroups for that too. ...
    (comp.lang.c)
  • Re: coding conventions
    ... Your standard is not the right standard: ... You have to be consistent. ... their *source code* with your own, the convention Sun uses is irrelevant to the discussion. ... The compiler doesn't need to do anything else. ...
    (comp.lang.java.help)