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

I am trying to find out whether remote host is connected or not using
C/C++ code on Redhat Linux. If its connected, I can send a result to
"Pass" and if its not "Failed"

I tried 2 different things:
1)


#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>


int ping_ret, status;


status = system("ping -w 2 192.168.0.2");


if (-1 != status)
ping_ret = WEXITSTATUS(status);


But, even if ethernet cable is connected or not to the remote host, I
always get "Ping_ret" = 0. So, I don't get a desired result in this
case.


2)
I also tried popen():


char psBuffer[1024];
FILE * fdRTP;


if( (fdRTP = popen( "ping -c 1 192.168.0.2", "r" )) == NULL
)
{
FSLog(LOG_ERROR,
"AebEthernetTest::HandleDmseCommand(): Failed to
create Pipe");
error_code = AEB_DPI_INIFILEREADERR;
}


else
{
/* Read this pipe and print to the stdout until end of
file */
while( !feof( fdRTP ) )
{
if( fread( psBuffer, sizeof(char), 1024, fdRTP
) )
{
if(0 == strcmp(psBuffer,"0%
loss"))
{
result = TRUE;
}
}
}
}


/* Close pipe */
pclose( fdRTP );


But, in this case, its not even "Ping".


If possible, help me guys.


Thanks

"Neel" <nilayhshah@gmail.com> wrote:
>I am trying to find out whether remote host is connected or not using
>C/C++ code on Redhat Linux. If its connected, I can send a result to

C is one language, C++ is another. You can't use both of them in one
source code file.

>"Pass" and if its not "Failed"
>
>I tried 2 different things:
>1)
>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <sys/wait.h>
>
> int ping_ret, status;
>
> status = system("ping -w 2 192.168.0.2");
>
> if (-1 != status)
> ping_ret = WEXITSTATUS(status);
>
>But, even if ethernet cable is connected or not to the remote host, I
>always get "Ping_ret" = 0. So, I don't get a desired result in this
>case.

That works fine for me. I get 1 if there is no connection, and
0 if there is.

>2)
>I also tried popen():
>
> char psBuffer[1024];
> FILE * fdRTP;

Your choice of variable names is confusing. "fd" is usually an
indication that you are dealing with a File Descriptor, which is
an integer value. FILE pointers (FILE *) are pointers to a
struct FILE, and should not be confused with File Descriptors.
Generally "fp" is used for variable names associated with a FILE
pointer.

>
> if( (fdRTP = popen( "ping -c 1 192.168.0.2", "r" )) == NULL
>)
> {
> FSLog(LOG_ERROR,
>"AebEthernetTest::HandleDmseCommand(): Failed to
>create Pipe");
> error_code = AEB_DPI_INIFILEREADERR;
> }
>
> else
> {
> /* Read this pipe and print to the stdout until end of
>file */
> while( !feof( fdRTP ) )

There is no point in using feof(3) as the test to stop reading.
The fread(3) function will return 0 at eof.

> {
> if( fread( psBuffer, sizeof(char), 1024, fdRTP

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

>) )

You are assuming that fread will return all of the output from popen()
in one read, but that may not happen. Use fgets() instead, and then
parse the output on line at a time.

> {
> if(0 == strcmp(psBuffer,"0%
>loss"))
> {
> result = TRUE;
> }
> }
> }
> }

That doesn't work. Your code assumes that the "0% loss" will
just accidentally happen to be at the beginning of the buffer.
It won't! With a 1024 byte buffer, it is likely that the entire
output of ping will be saved in a single read. You might try
something like strstr(3) to detect that string. But that won't
help if fread() returns with only part of the data, an in
particular if it splits the string you are searching for between
to different calls to fread().

But it would be much easier to use fgets(), which breaks the
output into individual lines that will allow you to *know*
exactly where in the buffer that text would land. The string
ping returns may not be consistant for failurs though, as
either of these might be seen:

1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

But for success apparently the format will remain the same:

3 packets transmitted, 3 received, 0% packet loss, time 1999ms

Regardless, the best way to deal with that is to use strstr(3)
to search for something like " 100% packet loss". Note that by
including the space before the percentage it helps to avoid
ambiguity. For example, searching for "0% packet loss" would be
valid for several different percentages, only one of which is 0.

> /* Close pipe */
> pclose( fdRTP );
>
>But, in this case, its not even "Ping".
>
>If possible, help me guys.
>
>Thanks

Here is a short program that implements two different ways of
doing it, one using system() and two using popen().

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(int argc, char **argv)
{
char cmd[100], buf[1024];
int status, ping_rtn;
FILE *fp;

if (argc < 2) {
fprintf(stderr, "Specify a target IP address or host name.\n");
exit(1);
}

sprintf(cmd, "ping -w 2 %s > /dev/null", argv[1]);
status = system(cmd);
ping_rtn = status;
if (status != -1) {
ping_rtn = WEXITSTATUS(status);
printf("ping returned: %sConnected\n", ping_rtn ? "Not " : "");
} else {
fprintf(stderr, "The system(3) function returned -1\n");
}

sprintf(cmd, "ping -w 2 %s", argv[1]);
if (NULL == (fp = popen(cmd, "r"))) {
fprintf(stderr, "The popen(3) function returned NULL\n");
exit(2);
}

status = 1;
ping_rtn = 0;
while (NULL != fgets(buf, sizeof(buf), fp)) {
char *s;
if (NULL != (s = strstr(buf, " packet loss"))) {
status = 0;
if (NULL != (s = strstr(buf, " 100% packet loss"))) {
ping_rtn = 1;
break;
}
}
}

pclose(fp);
if (0 == status) {
printf("ping returned: %sConnected\n", ping_rtn ? "Not " : "");
} else {
printf("ping did not indicate success or failure.\n");
}

return 0;
}

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

Floyd L. Davidson wrote:

> "Neel" <nilayhshah@gmail.com> wrote:
>>I am trying to find out whether remote host is connected or not using
>>C/C++ code on Redhat Linux. If its connected, I can send a result to
>
> C is one language, C++ is another. You can't use both of them in one
> source code file.
>

Agreed, absolutely. C++ is not an extension to C. It is a different
language with some similarities in syntax. The underlying mechanisms are
different in many cases, and the design philosophy requires the adoption of
a completely different paradigm (C == structured, C++ == object oriented)

Bjarne Stroustrop (http://public.research.att.com/~bs/ - C++ language
creator, for those who didn't know) has stated this with explicit language
on his web site. Of special interest to those interested in this is this
statement in one of his FAQs:

http://public.research.att.com/~bs/b...l#prerequisite

<snip>
>
> Your choice of variable names is confusing. "fd" is usually an
> indication that you are dealing with a File Descriptor, which is
> an integer value. FILE pointers (FILE *) are pointers to a
> struct FILE, and should not be confused with File Descriptors.
> Generally "fp" is used for variable names associated with a FILE
> pointer.

Again, right on the money.

><snip>
>> {
>> if( fread( psBuffer, sizeof(char), 1024, fdRTP
>
> 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.

<snip>

"James J. Dines" <james.dines@gmail.com> 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.

6.5.3.4 The sizeof operator

...

Semantics

...

3 When applied to an operand that has type char, unsigned
char, or signed char, (or a qualified version thereof) the
result is 1. ...


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

Floyd L. Davidson wrote:

> "James J. Dines" <james.dines@gmail.com> 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. 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.)

From: http://www.doc.ic.ac.uk/lab/secondye...le/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
************************************************** *************************

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.

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

More information on portability can be found here:

http://hebb.cis.uoguelph.ca/~dave/27...rtability.html

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...loc#sizeofchar

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

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

Cheers,

Jim D.

"James J. Dines" <james.dines@gmail.com> wrote:
>Floyd L. Davidson wrote:
>> "James J. Dines" <james.dines@gmail.com> 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/secondye...le/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/27...rtability.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...loc#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@apaflo.com

Floyd L. Davidson wrote:

> "James J. Dines" <james.dines@gmail.com> wrote:
>>Floyd L. Davidson wrote:
>>> "James J. Dines" <james.dines@gmail.com> 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/27...rtability.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...loc#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.

"James J. Dines" <james.dines@gmail.com> wrote:
>Floyd L. Davidson wrote:
>
>> "James J. Dines" <james.dines@gmail.com> wrote:
>>>Floyd L. Davidson wrote:
>>>> "James J. Dines" <james.dines@gmail.com> 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/27...rtability.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@apaflo.com

Floyd L. Davidson wrote:

> "James J. Dines" <james.dines@gmail.com> wrote:
>>Floyd L. Davidson wrote:
>>
<*MUCH* back and forth deleted>
>>
>>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 know you aren't a C++ guy, but do you see where I was originally going
with this when I was viewing the code in a C++ context?

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

No thanks. I have no doubt that you follow it religiously, and are
accurately portraying the general sentiment. Again, reasonable people can
disagree. I believe it is clear that we are both reasonable people. I
have views on what makes good source code, and what makes for bad source
code, and they are opinions, not absolute fact. I have thought about it in
enough detail that Kernighan, Ritchie, or any contemporary C language guru
would not convince me otherwise. Again, to me this is a big picture thing
that transcends implementation detail, and is about good coding practice.
Portable practice, as opposed to portability practice.

My rule of thumb is this: Without exception, be consistent and explicit
except when to do otherwise would obfuscate the meaning of the code,
confuse, mislead, and/or cause unnecessary effort to be expended by the
code reviewer, or cause the function of the resultant binary to behave
differently. As far as I am concerned, source code should be a special
case of compilable documentation in as much as that is possible.

I'd rather have someone say, did you know you could use a 1 there instead of
sizeof(char)? (-and now, thanks to you, I do :-) ... than ... 'it took me
10 minutes to find the function reference and see what that 1 was supposed
to represent in this context.' Many things are a trade-off. Not everyone
will pick the same option when one is presented.

I spread myself too thin to change that approach, and keep track of all of
the exceptions for each language, platform, etc ... It would be a kind of
spaghetti code in my psyche that I don't have the time, inclination, or -
perhaps - ability, with which to deal.

Peace; thanks for your help, your valuable input, and your time!

Jim D.