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:

Note that sizeof(char) is defined as 1, so there is no point not
just putting a 1 there.

I don't agree with you here. It is better practice for writing portable
code to use sizeof(char) ... I believe any decent compiler will optimize
it to a 1 for architectures where 1 is correct, and another value when it
changes on a different architecture. No function call overhead, still
portable, better style.

The only correct result, on *any* architecture, is 1. That is
required by the ISO/ANSI C Standard.

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.

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

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

Furthermore,
architecture refers to software architecture as well as hardware
architecture. No assumption about ASNI C compliance should be made when
considering portability issues (though when there is a trade-off, ANSI
should be favored ... there isn't one here as far as any research I did was
able to turn up.)

No assumption about ANSI C compliance should be made...
*unless* you are talking about C. In that case it absolutely
should. C has been standardized now for more than 15 years. I
know of *no* compilers that claim to be C that do not also claim
some level of standards compliance.

From: http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node20.html

**************************************************************************
Pay attention to word sizes. Objects may be non-intuitive sizes, Pointers
are not always the same size as int s, the same size as each other, or
freely interconvertible. The following table shows bit sizes for basic
types in C for various machines and compilers.
type pdp11 VAX/11 68000 Cray-2 Unisys Harris 80386
series family 1100 H800
char 8 8 8 8 9 8 8
short 16 16 8/16 64(32) 18 24 8/16
int 16 32 16/32 64(32) 36 24 16/32
long 32 32 32 64 36 48 32
char* 16 32 32 64 72 24 16/32/48
int* 16 32 32 64(24) 72 24 16/32/48
int(*)() 16 32 32 64 576 24 16/32/48
***************************************************************************

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.

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.

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


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.

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.

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,

"It's never necessary to multiply by sizeof(char), since
sizeof(char) is, by definition, exactly 1. (On the other
hand, multiplying by sizeof(char) doesn't hurt, and in some
circumstances may help by introducing a size_t into the
expression; see question 7.15.) See also questions 8.9 and
8.10."

What he means is that if someone did something like this,

int *ptr = malloc( 100 * sizeof(char));

It is distinct from

int *ptr = malloc( 100 );

in that the expression used as the argument in the first
statement becomes a type size_t because the return from the
sizeof operator is a size_t, while in the second statement the
constant 100 is a type int. The malloc function of course is
defined as having a single size_t type argument in the parameter
list.

Hence this,

int *ptr = malloc(100 * (size_t) 1);

is usually the same as any of these,

int *ptr = malloc(100 * (unsigned int) 1);
int *ptr = malloc(100 * 1U);

If an explicit conversion is somehow desirable (and I'm not
convinced that it is), this one is best,

int *ptr = malloc( (size_t) 100 );

But there is a valid question of is there ever some advantage to
explicitly specifying the constant as size_t as oppose to a type
int.

There can be a significant difference between these two,

int *ptr = malloc( (size_t) 100 );
int *ptr = malloc( 100 );

If you can find a system where size_t is an unsigned long, it is
possible that the constant 100, which is a type int, will
produce garbage unless cast to size_t.

Of course while inserting sizeof(char) might well to the same
thing, it won't win awards for clarity either... ;-)

<snip>

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

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

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

Relevant Pages

  • Re: I need a new compiler...
    ... finished all the nested program "stuff"? ... "optional" for ANSI compliance but was required for FIPS compliance - by 1993). ... it is a VERY complete compiler including both '85 Standard ...
    (comp.lang.cobol)
  • Re: return values for void functions
    ... >> How can someone know if their compiler is any good ... appropriate tool to test compliance. ... *code* complied with the standard, ... discussing compliance of some random compiler, ...
    (comp.lang.cpp)
  • Re: f03?
    ... like that for standard compliance. ... make a compiler fully f2003 compliant, ... There is an interpretation ...
    (comp.lang.fortran)
  • Re: Toward a Forth thats easier to learn
    ... is an architecture standard, not a language standard. ... in the CORE that are only of interest to compiler builders and system ... standard (ANS system, ...
    (comp.lang.forth)
  • Re: Ping from C/C++ doesnt work properly using either System() or popen()
    ... The only correct result, on *any* architecture, is 1. ... but quoting the ANSI standard is a red herring. ... guarantee a given compiler will even be ANSI C compliant. ... considering portability issues (though when there is a trade-off, ...
    (comp.os.linux.networking)