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

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?

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).

<snip>

That misses the point entirely, in regard to the sizeof operator.
Sizeof does *not* concern itself with bits. *All* objects are defined in
terms of size compared to a char object, which is defined as size 1.

The chart is meaninless in context of a sizeof operator discussion.


Yes, I thought about that *after* I posted. Didn't see the point in
piggybacking on my follow-up. I blew it there.

Not all hardware architectures are equal. Not every compiler follows the
standard correctly. Indeed, on the Unisys 1100, it is bound by the
hardware to not do so.

That is untrue.

I assume you are referring to the third sentence, which I acknowledge I blew
it on, but *obviously* the first two statements are true. Well .. perhaps
a better way to say the second one is: It is within the realm of
possibility that not every compiler follows the standard correctly, though
I now admit that, thanks to your help, I find that much less likely.


Furthermore, sizeof(char) makes explicit what is being passed. There is
no
benefit to removing information from source code. With '1', I must know
that the parameter is not a flag of some kind.

I don't believe that is true. Anyone who does not know enough
about the code they are writing to know the difference between
"a flag of some kind" and the size of an object has a problem
beyond the scope of this discussion.)

I am assuming you mean are referring to the last sentence. Agreed, if I was
not talking about code reviews or maintanence. I meant, as the *reviewer*
or other second party I must know this, and it is just one more
diversionary hassle that is unnecessary. (you cipped into the middle of the
paragraph, so you'll have to look below for the rest of the text that makes
this implication. I - perhaps mistakenly - thought I was being clear. *Of
course* if you don't know what the parameters of a function do when you are
the original coder, you haven't got a prayer in hell and you might as well
hang up your reference manuals and go home.



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).


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.

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.

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.

There is also another issue, involving the introduction of a size_t into
the expression under certain circumstances, which is explained here:

http://c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=malloc#sizeofchar

You know more about the standard, so maybe you know what it is, and can
elaborate?

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.


These are the reasons *for* sizeof(char) over a literal. Did I miss any
*against* it? I couldn't find any. I am always willing to learn new
things, so if there is one, please speak up (as if I need to ask you to
;-)

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. 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. 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.


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.)

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 ...

Cheers,

Jim D.
.

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: 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: 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. ... It is consistent for a demonstration, ...
    (comp.os.linux.networking)
  • 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)