First C Program, Problems getting serial data

[Chuck Faranda]

I'm trying to debug my first C program (firmware for PIC MCU). The problem
is getting serial data back from my device. My get commands have to be sent
twice for the PIC to respond properly with the needed data. Any ideas?
Here's the code in question, see any reason why a command would not trigger
the 'kbhit' the first time a serial command is sent?: Thanks!

Chuck

************************************************** **
while(1) // loop forever
{

// check for a request via serial
if (kbhit())
{
gets(cmd);
//flash the LED to show a command is being processed
output_high(LED_PIN);
delay_ms(200);
output_low(LED_PIN);
//check for proper request
strcpy(cmdcheck,"CFGET");
if (strcmp(cmd, cmdcheck)=1) // if it is our command return the value
of current
//read the adc value
set_adc_channel(CURRENT_CHANNEL);
delay_us(ADC_DELAY);
s1 = read_adc();
current = (0.05*s1); // check this scaling (10 bits all 1's = 5.0)
//send the requested data
printf("CF%3.1f\r\n", current);
}
delay_ms(50); // delay 50 ms and do another cycle
} // end while
}
************************************************** **
--

Regards,
Chuck Faranda
http://ccdastro.net

[Walter Roberson]

In article <tt******************************@comcast.com>,
Chuck Faranda <as*******@hotmail.com> wrote:

I'm trying to debug my first C program (firmware for PIC MCU). The problem
is getting serial data back from my device. My get commands have to be sent
twice for the PIC to respond properly with the needed data. Any ideas?
Here's the code in question, see any reason why a command would not trigger
the 'kbhit' the first time a serial command is sent?: Thanks! ************************************************* ***
while(1) // loop forever
{

// check for a request via serial
if (kbhit())

kbhit() is not a standard part of the C library, and you have not provided
code for it nor documentation on what *exactly* it does. Any guesses we might
make about why your code does not do what you expect would be... well, guesses.
You need to check out your platform-specific documentation.

Wild guess: the other end is a C program and the other end is set to buffer
output [probably by default] and the other end does not specifically
fflush() to force the output to be sent from the buffers to the device driver.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[Chuck Faranda]

Oops, sorry. Here's the only docs that came with the compiler:

It may be possible fot the buffers to be full, I'll see what can be done
about flushing, thanks.

KBHIT()
Syntax:
value = kbhit()

Parameters:
None

Returns:
0 (or FALSE) if getc() will need to wait for a character to come in, 1
(or TRUE) if a character is ready for getc()

Function:
If the RS232 is under software control this function returns TRUE if
the start bit of a character is being sent on the RS232 RCV pin. If the
RS232 is hardware this function returns TRUE is a character has been
received and is waiting in the hardware buffer for getc() to read. This
function may be used to poll for data without stopping and waiting for the
data to appear. Note that in the case of software RS232 this function
should be called at least 10 times the bit rate to ensure incoming data is
not lost.

Availability:
All devices.

Requires
#use rs232

Examples:
char timed_getc() {

long timeout;

timeout_error=FALSE;

timeout=0;

while(!kbhit()&&(++timeout<50000)) // 1/2 second

delay_us(10);

if(kbhit())

return(getc());

else {

timeout_error=TRUE;

return(0);

}

}

Example Files:
ex_tgetc.c

Also See:
getc(), #USE RS232

--

Regards,
Chuck Faranda
http://ccdastro.net
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:e1**********@canopus.cc.umanitoba.ca...

In article <tt******************************@comcast.com>,
Chuck Faranda <as*******@hotmail.com> wrote:

I'm trying to debug my first C program (firmware for PIC MCU). The
problem
is getting serial data back from my device. My get commands have to be
sent
twice for the PIC to respond properly with the needed data. Any ideas?
Here's the code in question, see any reason why a command would not
trigger
the 'kbhit' the first time a serial command is sent?: Thanks!

************************************************ ****
while(1) // loop forever
{

// check for a request via serial
if (kbhit())

kbhit() is not a standard part of the C library, and you have not provided
code for it nor documentation on what *exactly* it does. Any guesses we
might
make about why your code does not do what you expect would be... well,
guesses.
You need to check out your platform-specific documentation.

Wild guess: the other end is a C program and the other end is set to
buffer
output [probably by default] and the other end does not specifically
fflush() to force the output to be sent from the buffers to the device
driver.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[regis]

Chuck Faranda wrote:

I'm trying to debug my first C program (firmware for PIC MCU). if (strcmp(cmd, cmdcheck)=1) // if it is our command return the value

you probably want :

if (strcmp(cmd, cmdcheck) == 0)

i.e. use the equality operator instead of the assignment operator,
and compare the return value of strcmp with zero...

[Chuck Faranda]

I'll give that a try to see what happens. Thanks.
--
Chuck

"regis" <re**************@free.fr> wrote in message
news:44***********************@news.free.fr...

Chuck Faranda wrote:

I'm trying to debug my first C program (firmware for PIC MCU).

if (strcmp(cmd, cmdcheck)=1) // if it is our command return the
value

you probably want :

if (strcmp(cmd, cmdcheck) == 0)

i.e. use the equality operator instead of the assignment operator,
and compare the return value of strcmp with zero...

[Burton Samograd]

regis <re**************@free.fr> writes:

Chuck Faranda wrote:

I'm trying to debug my first C program (firmware for PIC MCU).

if (strcmp(cmd, cmdcheck)=1) // if it is our command return
the value

you probably want :

if (strcmp(cmd, cmdcheck) == 0)

actually, you probably want:

if (!strcmp(cmd, cmdcheck))

remember, 0 is false, anything else is true in C (not just 1). A lot
of functions in the C/Unix libraries return 0 for sucess (and then set
errno), so most of your calls will be of the if(!function()) style, at
least if you're checking the return value.

Of course the parent was also correct in that you should have the ==
instead of the =, but that goes without saying ;-)

--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com

[Simon Biber]

Burton Samograd wrote:

regis <re**************@free.fr> writes:

Chuck Faranda wrote:

I'm trying to debug my first C program (firmware for PIC MCU).

if (strcmp(cmd, cmdcheck)=1) // if it is our command return
the value

you probably want :

if (strcmp(cmd, cmdcheck) == 0)

actually, you probably want:

if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.
remember, 0 is false, anything else is true in C (not just 1). A lot
of functions in the C/Unix libraries return 0 for sucess (and then set
errno), so most of your calls will be of the if(!function()) style, at
least if you're checking the return value.
But you can also write the if(function() == 0) style, as it's exactly
the same.
Of course the parent was also correct in that you should have the ==
instead of the =, but that goes without saying ;-)

Indeed.

Simon.

[Burton Samograd]

Simon Biber <ne**@ralmin.cc> writes:

Burton Samograd wrote:

if (strcmp(cmd, cmdcheck) == 0)

actually, you probably want:
if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here :)

remember, 0 is false, anything else is true in C (not just 1). A lot
of functions in the C/Unix libraries return 0 for sucess (and then set
errno), so most of your calls will be of the if(!function()) style, at
least if you're checking the return value.

But you can also write the if(function() == 0) style, as it's exactly
the same.

Well, it doesn't seem as clear to me stylisticly (and it's also
shorter), and although teachers are pushing the == 0 style instead of
the ! style, the ! style is still the more 'C like' way to check
return values, at least for unix and standard library.

--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com

[Default User]

Burton Samograd wrote:

Simon Biber <ne**@ralmin.cc> writes:

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

Well, it doesn't seem as clear to me stylisticly (and it's also
shorter), and although teachers are pushing the == 0 style instead of
the ! style, the ! style is still the more 'C like' way to check
return values, at least for unix and standard library.

I have the exact opposite opinion. I feel the == form is clearer for
new learners of the language than applying the ! operator.

Brian

[Chuck Faranda]

I appreciate the insight in to the different ways to do this, it's helpful
in understanding the logic.
--

Regards,
Chuck Faranda
http://ccdastro.net
"Simon Biber" <ne**@ralmin.cc> wrote in message
news:44**********************@news.optusnet.com.au ...

Burton Samograd wrote:

regis <re**************@free.fr> writes:

Chuck Faranda wrote:

I'm trying to debug my first C program (firmware for PIC MCU).

if (strcmp(cmd, cmdcheck)=1) // if it is our command return
the value

you probably want :

if (strcmp(cmd, cmdcheck) == 0)

actually, you probably want:

if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

remember, 0 is false, anything else is true in C (not just 1). A lot
of functions in the C/Unix libraries return 0 for sucess (and then set
errno), so most of your calls will be of the if(!function()) style, at
least if you're checking the return value.

But you can also write the if(function() == 0) style, as it's exactly the
same.

Of course the parent was also correct in that you should have the ==
instead of the =, but that goes without saying ;-)

Indeed.

Simon.

[Keith Thompson]

Burton Samograd <kr**********@gmail.com> writes:

Simon Biber <ne**@ralmin.cc> writes:

Burton Samograd wrote:

>>if (strcmp(cmd, cmdcheck) == 0)
> actually, you probably want:
> if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here :)

I agree that one is clearer than the other; I disagree about which one
it is.

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"Default User" <de***********@yahoo.com> writes:

Burton Samograd wrote:

Simon Biber <ne**@ralmin.cc> writes:

> Those two lines have exactly the same effect. Writing (foo == 0) is
> equivalent to writing (!foo). If foo has a zero value (or is a null
> pointer) then the result is 1, otherwise the result is 0.

Well, it doesn't seem as clear to me stylisticly (and it's also
shorter), and although teachers are pushing the == 0 style instead of
the ! style, the ! style is still the more 'C like' way to check
return values, at least for unix and standard library.

I have the exact opposite opinion. I feel the == form is clearer for
new learners of the language than applying the ! operator.

I find the == form much clearer for myself, and I've been using the
language on and off for about a quarter century.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenneth Brody]

Burton Samograd wrote:

Simon Biber <ne**@ralmin.cc> writes:

Burton Samograd wrote:

>if (strcmp(cmd, cmdcheck) == 0)
actually, you probably want:
if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here :)

"A bit more clear", but "wrong". "Wrong" in the sense that strcmp()
returns zero if the strings compare equal, and using "!strcmp()" gives
the impression that you want "not equal", as in "the comparison failed".

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Default User]

Keith Thompson wrote:

"Default User" <de***********@yahoo.com> writes:

I have the exact opposite opinion. I feel the == form is clearer for
new learners of the language than applying the ! operator.

I find the == form much clearer for myself, and I've been using the
language on and off for about a quarter century.

I would not disagree. I tended to use the ! form years back, but use
the == version these days.

Brian

[Keith Thompson]

Kenneth Brody <ke******@spamcop.net> writes:

Burton Samograd wrote:

Simon Biber <ne**@ralmin.cc> writes:

> Burton Samograd wrote:
> >>if (strcmp(cmd, cmdcheck) == 0)
> > actually, you probably want:
> > if (!strcmp(cmd, cmdcheck))
>
> Those two lines have exactly the same effect. Writing (foo == 0) is
> equivalent to writing (!foo). If foo has a zero value (or is a null
> pointer) then the result is 1, otherwise the result is 0.

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here :)

"A bit more clear", but "wrong". "Wrong" in the sense that strcmp()
returns zero if the strings compare equal, and using "!strcmp()" gives
the impression that you want "not equal", as in "the comparison failed".

If you think of strcmp(x, y) as meaning that the strings x and y are
unequal, !strcmp(x, y) makes sense. I suspect that those programmers
who are comfortable with the "!" form do think of it that way, at
least in that context. I'm not, and I don't -- but as C programmers,
we all need to be able to deal with code written by programmers who
don't think about these things quite the same way we do.

Write code that's as clear as possible. Be prepared to read code
written by programmers who *don't* write code that's as clear as
possible, or who have different opinions about what's clear than you
do.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Vladimir S. Oka]

Chuck Faranda opined:

I appreciate the insight in to the different ways to do this, it's
helpful in understanding the logic.

Please don't top-post.

Your reply belongs below, or interspersed with the text you're replying
to. Especially, don't stick quoted text below your signature, as most
sane news readers will not quote it automatically (see how most of
your post is missing from mine). It then becomes difficult for others
to post a well-formed reply.

--
The only "intuitive" interface is the nipple. After that, it's all
learned. (Bruce Ediger, be*****@teal.csn.org, in comp.os.linux.misc,
on X interfaces.)

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

[jaysome]

Keith Thompson wrote:

Burton Samograd <kr**********@gmail.com> writes:

Simon Biber <ne**@ralmin.cc> writes:

Burton Samograd wrote:

>if (strcmp(cmd, cmdcheck) == 0)

actually, you probably want:
if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here :)

I agree that one is clearer than the other; I disagree about which one
it is.

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

Keith, you are right on. A true Boolean variable should use Boolean
opeartors such as !, and never comparison operators such as ==. A
Boolean value by definition has a binary state, so the C standard
supports it quite nicely:

/* The true condition */
if ( is_on )

/* The false condition */
if ( !is_on )

There is no reason whatsoever to compare a Boolean value to another
value like this:

if ( is_on == TRUE )

or like this:

if ( is_on == FALSE )

or like the myriad other variations of these.

See the C FAQ Section 5.3 for further info:

http://c-faq.com/

--
jay

[Chris Hills]

Hi Chuck

You are in completely the wrong NG

try comp.arch.embedded

This lot have no idea about embedded C much less about PIC C they only
do standard ISO C.

there are a lot more people how understand PICs on comp.arch.embedded

regards
Chris

In article <tt******************************@comcast.com>, Chuck Faranda
<as*******@hotmail.com> writes

I'm trying to debug my first C program (firmware for PIC MCU). The problem
is getting serial data back from my device. My get commands have to be sent
twice for the PIC to respond properly with the needed data. Any ideas?
Here's the code in question, see any reason why a command would not trigger
the 'kbhit' the first time a serial command is sent?: Thanks!

Chuck

************************************************* ***
while(1) // loop forever
{

// check for a request via serial
if (kbhit())
{
gets(cmd);
//flash the LED to show a command is being processed
output_high(LED_PIN);
delay_ms(200);
output_low(LED_PIN);
//check for proper request
strcpy(cmdcheck,"CFGET");
if (strcmp(cmd, cmdcheck)=1) // if it is our command return the value
of current
//read the adc value
set_adc_channel(CURRENT_CHANNEL);
delay_us(ADC_DELAY);
s1 = read_adc();
current = (0.05*s1); // check this scaling (10 bits all 1's = 5.0)
//send the requested data
printf("CF%3.1f\r\n", current);
}
delay_ms(50); // delay 50 ms and do another cycle
} // end while
}
************************************************* ***

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chuck Faranda]

"Chris Hills" <ch***@phaedsys.org> wrote in message
news:Fv**************@phaedsys.demon.co.uk...

Hi Chuck

You are in completely the wrong NG

try comp.arch.embedded

This lot have no idea about embedded C much less about PIC C they only
do standard ISO C.

there are a lot more people how understand PICs on comp.arch.embedded

Thanks Chris, I will try there. The replies thus far have been helpful in
other areas though.

Chuck

[Richard Bos]

jaysome <ja*****@spamcop.com> wrote:

Keith, you are right on. A true Boolean variable should use Boolean
opeartors such as !, and never comparison operators such as ==. A
Boolean value by definition has a binary state, so the C standard
supports it quite nicely:

/* The true condition */
if ( is_on )

/* The false condition */
if ( !is_on )

There is no reason whatsoever to compare a Boolean value to another
value like this:

if ( is_on == TRUE )

or like this:

if ( is_on == FALSE )

or like the myriad other variations of these.

Imprimis, this is a style matter; if someone finds an explicit mention
of TRUE or FALSE clearer than the presence or absence of a !, is that a
problem?
Secundis, while I do agree with your style myself, there is one place
where you can't escape using == on boolean values without jumping
through silly hoops:

if (left_valve_open == right_valve_open)

Richard

[Michael Wojcik]

In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> writes:

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

And there's also the condition-parameter macro style:

#define CMP_STR(s1, op, s2) strcmp(s1, s2) op 0

if (CMP_STR(s1, ==, s2))

which inlines the condition operator and hides the 0. I think I
originally got this macro from Peter van der Linden, who presents it
in chapter 3 of _Expert C Programming_.

--
Michael Wojcik mi************@microfocus.com

Thus, the black lie, issuing from his base throat, becomes a boomerang to
his hand, and he is hoist by his own petard, and finds himself a marked man.
-- attributed to a "small-town newspaper editor in Wisconsin"

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

jaysome <ja*****@spamcop.com> wrote:

Keith, you are right on. A true Boolean variable should use Boolean
opeartors such as !, and never comparison operators such as ==. A
Boolean value by definition has a binary state, so the C standard
supports it quite nicely:

/* The true condition */
if ( is_on )

/* The false condition */
if ( !is_on )

There is no reason whatsoever to compare a Boolean value to another
value like this:

if ( is_on == TRUE )

or like this:

if ( is_on == FALSE )

or like the myriad other variations of these.
Imprimis, this is a style matter; if someone finds an explicit mention
of TRUE or FALSE clearer than the presence or absence of a !, is that a
problem?

Yes, it's a problem. TRUE is presumably equal to 1, but *any*
non-zero value is considered true.

Consider this:

is_on = isalpha(c);
if (is_on == TRUE)

This can fail if isalpha returns a value other than 0 or 1, which it's
allowed to do.
Secundis, while I do agree with your style myself, there is one place
where you can't escape using == on boolean values without jumping
through silly hoops:

if (left_valve_open == right_valve_open)

Again, this fails if left_valve_open and right_valve_open have
differing non-zero values.

If you want to compare two boolean values for logical equality, you
can do something like this:

if (!!left_valve_open == !!right_valve_open)

The double "!" normalizes the value to 0 or 1. (A single "!" would
work, but it would be more obscure, since it would compare the
negations of the two conditions for equality.)

If you have a C99 compiler, you can use type _Bool (or bool with
"#include <stdbool.h>"), which can only take on the values 0 and 1
(unless you cheat and force a different value into a _Bool object).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

Burton Samograd <kr**********@gmail.com> writes:

Simon Biber <ne**@ralmin.cc> writes:

Burton Samograd wrote:
>>if (strcmp(cmd, cmdcheck) == 0)
> actually, you probably want:
> if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.
Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here :)

I agree that one is clearer than the other; I disagree about which one
it is.

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or
below (<0) the last compared character in the other, is useless and heavily
dependent on the nonportable and sometimes random ordering of the character
set. Because of this, I'd posit that strcmp() is _essentially_ a boolean
function: zero equal, non-zero if different.
An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.
Untrue. There is an entire generation of programmers who were taught not to
think in terms of 'true'. They were taught to think entirely in terms of
'false'. 'true' is thought of as 'not false' and 'false' is zero (for all
but a few languages, i.e., ADA which, IIRC, Keith has experience in...). An
if() statement is thought of as 'if(not false)' or 'if(not zero)'. Since
strcmp() returns zero for equality, if(!strcmp()) says 'if(not zero)' which
is understood to be 'true'. if(strcmp()==0), on the other hand says 'if(0
is equal to 0)'. This, of course, lacks the simplicity, elegance, and
mnemonic of 'if(not zero)'.
Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

True. They are not programming in ADA and don't need to separate boolean
false and zero as distinct values.
Rod Pemberton

[Keith Thompson]

"Rod Pemberton" <do*********@sorry.bitbuck.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or
below (<0) the last compared character in the other, is useless and heavily
dependent on the nonportable and sometimes random ordering of the character
set. Because of this, I'd posit that strcmp() is _essentially_ a boolean
function: zero equal, non-zero if different.

strcmp() gives a consistent ordering of string values. Sometimes an
internally consistent ordering is all you need, for example if you
want to build a search tree.

strcmp() is not a boolean function.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Untrue. There is an entire generation of programmers who were taught not to
think in terms of 'true'. They were taught to think entirely in terms of
'false'. 'true' is thought of as 'not false' and 'false' is zero (for all
but a few languages, i.e., ADA which, IIRC, Keith has experience in...). An
if() statement is thought of as 'if(not false)' or 'if(not zero)'. Since
strcmp() returns zero for equality, if(!strcmp()) says 'if(not zero)' which
is understood to be 'true'. if(strcmp()==0), on the other hand says 'if(0
is equal to 0)'. This, of course, lacks the simplicity, elegance, and
mnemonic of 'if(not zero)'.

Yes, in C zero is false, and any non-zero value is true, so a boolean
value should be used directly as a condition, not compared for
equality to either true or false. Something like "if (b == true)" is
both dangerous and unnecessarily verbose; "if (b == false)" happens
not to be as dangerous (because there's only a single false value),
but it's just as unnecessarily verbose. They should be "if (b)" and
"if (!b)", respectively.

But that applies only when b is a boolean value. The result returned
by strcmp() is not.

If you want to define macros like
#define STR_EQ (strcmp((x), (y)) != 0)
#define STR_NE (strcmp((x), (y)) == 0)
then of course you can use them as conditions.

(Aside: I've never heard of a language called "ADA". I've programmed
in Ada. It's a name, not an acronym.)

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

True. They are not programming in ADA and don't need to separate boolean
false and zero as distinct values.

Which has no relevance to what we're actually discussing.

If you want to argue that it's acceptable to treat the result of
strcmp() as a boolean value (true if the arguments are unequal, false
if they're equal), that's not an entirely unreasable argument. I
don't happen to agree with it (if strcmp() were intended to be boolean
it would have a different name), but I recognize that some programmers
either value terseness over clarity, or just don't find !strcmp(x, y)
as unclear as I do. Bringing in an irrelevant argument about true and
false doesn't help your case.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[regis]

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> wrote in message Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or
below (<0) the last compared character in the other, is useless and heavily
dependent on the nonportable and sometimes random ordering of the character
set. Because of this, I'd posit that strcmp() is _essentially_ a boolean
function: zero equal, non-zero if different.

It is a comparison function designed to work with qsort().

If one want to easily detect multiple occurrences of strings
in an array, one way is to use qsort() along with strcmp()
so that these occurrences become contiguous,
and then any behavior of strcmp() fits the job
as long as it is a comparison function.

[Keith Thompson]

regis <re***@dil.univ-mrs.fr> writes:

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or
below (<0) the last compared character in the other, is useless and heavily
dependent on the nonportable and sometimes random ordering of the character
set. Because of this, I'd posit that strcmp() is _essentially_ a boolean
function: zero equal, non-zero if different.

It is a comparison function designed to work with qsort().

If one want to easily detect multiple occurrences of strings
in an array, one way is to use qsort() along with strcmp()
so that these occurrences become contiguous,
and then any behavior of strcmp() fits the job
as long as it is a comparison function.

I'm sure strcmp() was intended to be used directly with qsort() when
the functions were originally designed. However, qsort() expects a
comparison function that takes two arguments of type "const void*",
whereas strcmp() expects arguments of type "const char*". There are
some guarantees of compatibility between void* and char*, but I'm not
sure they extend to compatbility of functions taking them as
arguments.

At worst, though, strcmp() can be used with qsort() with a very simple
wrapper.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@sorry.bitbuck.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... [...]

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or

below (<0) the last compared character in the other, is useless and heavily dependent on the nonportable and sometimes random ordering of the character set. Because of this, I'd posit that strcmp() is _essentially_ a boolean function: zero equal, non-zero if different.

strcmp() gives a consistent ordering of string values. Sometimes an
internally consistent ordering is all you need, for example if you
want to build a search tree.

strcmp() is not a boolean function.

I never said it was. I said it is _essentially_ a boolean function. That's
because ordering of string values is a very low use situation...

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Untrue. There is an entire generation of programmers who were taught not to

think in terms of 'true'. They were taught to think entirely in terms of 'false'. 'true' is thought of as 'not false' and 'false' is zero (for all but a few languages, i.e., ADA which, IIRC, Keith has experience in...). An if() statement is thought of as 'if(not false)' or 'if(not zero)'. Since strcmp() returns zero for equality, if(!strcmp()) says 'if(not zero)' which is understood to be 'true'. if(strcmp()==0), on the other hand says 'if(0 is equal to 0)'. This, of course, lacks the simplicity, elegance, and
mnemonic of 'if(not zero)'.

Yes, in C zero is false, and any non-zero value is true, so a boolean
value should be used directly as a condition, not compared for
equality to either true or false. Something like "if (b == true)" is
both dangerous and unnecessarily verbose; "if (b == false)" happens
not to be as dangerous (because there's only a single false value),
but it's just as unnecessarily verbose. They should be "if (b)" and
"if (!b)", respectively.

But that applies only when b is a boolean value. The result returned
by strcmp() is not.
(Aside: I've never heard of a language called "ADA". I've programmed
in Ada. It's a name, not an acronym.)

True enough, although it is frequently found all capitalized.

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

True. They are not programming in ADA and don't need to separate boolean

false and zero as distinct values.

Which has no relevance to what we're actually discussing.

Yes, it does. That is where you're perspective originates and is why you
have 'clarity' issues with treating the result of strcmp as a boolean.
If you want to argue that it's acceptable to treat the result of
strcmp() as a boolean value (true if the arguments are unequal, false
if they're equal), that's not an entirely unreasable argument. I
don't happen to agree with it (if strcmp() were intended to be boolean
it would have a different name), but I recognize that some programmers
either value terseness over clarity, or just don't find !strcmp(x, y)
as unclear as I do. just don't find !strcmp(x, y) as unclear as I do.
Why do you find this unclear? If you treat 1 and -1 as 'not false' and 0 as
false, it's completely clear.
Bringing in an irrelevant argument about true and
false doesn't help your case.

Irrelevant? I tried to explain things, when _you_ said you found things
unclear:

but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

The discussion regarding true and false describes why others don't find it
unclear. If you spent time to comprehend, perhaps it would help your
clarity.
Rod Pemberton

[Kenneth Brody]

Rod Pemberton wrote:
[...]

Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or
below (<0) the last compared character in the other, is useless
I'm sure anyone who has needed to sort a list of strings will disagree
with your "useless" tag.
and heavily
dependent on the nonportable and sometimes random ordering of the character
set.
Yet it will always compare the same way on a given platform.

And if you're on a platform where the letters do not sort in order, then
you get what you deserve. :-)
Because of this, I'd posit that strcmp() is _essentially_ a boolean
function: zero equal, non-zero if different.

Hardly.

While that _might_ be the _majority_ of the cases where it's used, it's
hardly the only way.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Untrue. There is an entire generation of programmers who were taught not to
think in terms of 'true'. They were taught to think entirely in terms of
'false'. 'true' is thought of as 'not false' and 'false' is zero (for all
but a few languages, i.e., ADA which, IIRC, Keith has experience in...). An
if() statement is thought of as 'if(not false)' or 'if(not zero)'. Since
strcmp() returns zero for equality, if(!strcmp()) says 'if(not zero)' which
is understood to be 'true'. if(strcmp()==0), on the other hand says 'if(0
is equal to 0)'. This, of course, lacks the simplicity, elegance, and
mnemonic of 'if(not zero)'.

But, as has been pointed out, strcmp() _isn't_ a boolean function. And
if you treat it as if it were, the "truthness" is backwards from how most
people would think of it. If you are comparing two strings, "true" should
mean "equal". By testing "if (!strcmp(a,b))", most people would probably
read it as "if the two strings are _not_ equal".

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

"Rod Pemberton" <do*********@sorry.bitbuck.cmm> writes:
[...]

The discussion regarding true and false describes why others don't find it
unclear. If you spent time to comprehend, perhaps it would help your
clarity.

I understand your argument. I just disagree with it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@sorry.bitbuck.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.
Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or below (<0) the last compared character in the other, is useless and heavily dependent on the nonportable and sometimes random ordering of the character set. Because of this, I'd posit that strcmp() is _essentially_ a boolean function: zero equal, non-zero if different.

strcmp() gives a consistent ordering of string values. Sometimes an
internally consistent ordering is all you need, for example if you
want to build a search tree.

strcmp() is not a boolean function.

I never said it was. I said it is _essentially_ a boolean function. That's
because ordering of string values is a very low use situation...

No, it is essentially a comparison function with three return values,
something I have a lot of use for. It is often used in a boolean context
where two of those values are treated the same.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.
Untrue. There is an entire generation of programmers who were taught not to think in terms of 'true'. They were taught to think entirely in terms of 'false'. 'true' is thought of as 'not false' and 'false' is zero (for all but a few languages, i.e., ADA which, IIRC, Keith has experience in...). An if() statement is thought of as 'if(not false)' or 'if(not zero)'. Since strcmp() returns zero for equality, if(!strcmp()) says 'if(not zero)' which is understood to be 'true'. if(strcmp()==0), on the other hand says 'if(0 is equal to 0)'. This, of course, lacks the simplicity, elegance, and
mnemonic of 'if(not zero)'.

Yes, in C zero is false, and any non-zero value is true, so a boolean
value should be used directly as a condition, not compared for
equality to either true or false. Something like "if (b == true)" is
both dangerous and unnecessarily verbose; "if (b == false)" happens
not to be as dangerous (because there's only a single false value),
but it's just as unnecessarily verbose. They should be "if (b)" and
"if (!b)", respectively.

But that applies only when b is a boolean value. The result returned
by strcmp() is not.

(Aside: I've never heard of a language called "ADA". I've programmed
in Ada. It's a name, not an acronym.)

True enough, although it is frequently found all capitalized.

That doesn't make it correct.

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.
True. They are not programming in ADA and don't need to separate boolean false and zero as distinct values.

Which has no relevance to what we're actually discussing.

Yes, it does. That is where you're perspective originates and is why you
have 'clarity' issues with treating the result of strcmp as a boolean.

I spent a lot of my early career as an assembler programmer, and
comparing strings I would naturally end up with something that behaved
like strcmp since comparing two bytes gave that information on the
processors I was using. So I come from a background of not having a boolean.

Like Keith I find it easier to read/write comparing strcmp with 0 than
using it as a boolean. I can read it used as a boolean, I just have to
spend an extra couple of seconds interpreting it.

If you want to argue that it's acceptable to treat the result of
strcmp() as a boolean value (true if the arguments are unequal, false
if they're equal), that's not an entirely unreasable argument. I
don't happen to agree with it (if strcmp() were intended to be boolean
it would have a different name), but I recognize that some programmers
either value terseness over clarity, or just don't find !strcmp(x, y)
as unclear as I do.

just don't find !strcmp(x, y) as unclear as I do.

Why do you find this unclear? If you treat 1 and -1 as 'not false' and 0 as
false, it's completely clear.

It is unambiguous but for some it takes longer to read than a comparison
with 0.

Bringing in an irrelevant argument about true and
false doesn't help your case.

Irrelevant? I tried to explain things, when _you_ said you found things
unclear:

Some people find that reading "if (strcmp(x,y))" or "if (!strcmp(x,y))"
takes a little though where comparing against 0 doesn't because they
think of it as returning three values, not returning a boolean that is
the wrong way up.

but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

The discussion regarding true and false describes why others don't find it
unclear. If you spent time to comprehend, perhaps it would help your
clarity.

I'm sure Keith fully understands how boolean context work in C.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[regis]

Keith Thompson wrote:

regis <re***@dil.univ-mrs.fr> writes:

Rod Pemberton wrote:

Because of this, I'd posit that strcmp() is _essentially_ a boolean
function: zero equal, non-zero if different.

It is a comparison function designed to work with qsort().

If one want to easily detect multiple occurrences of strings
in an array, one way is to use qsort() along with strcmp()
so that these occurrences become contiguous,
and then any behavior of strcmp() fits the job
as long as it is a comparison function.

I'm sure strcmp() was intended to be used directly with qsort() when
the functions were originally designed. However, qsort() expects a
comparison function that takes two arguments of type "const void*",
whereas strcmp() expects arguments of type "const char*". There are
some guarantees of compatibility between void* and char*, but I'm not
sure they extend to compatbility of functions taking them as
arguments.

At worst, though, strcmp() can be used with qsort() with a very simple
wrapper.

Oups. And to make things worse...

Should this extension of compatibility have existed between
functions taking "char*" and "void*" as arguments,
this would not have worked either with the example I had in mind,
that is, sorting an array of elements, each of type char *,
because another level of indirection is introduced:

The comparison function of qsort expects two pointers to the elements
be compared, as opposed to the elements themselves,
therefore here, behind the two "void *"
it expects two "const char **" as opposed to two "const char *"

int strcmp_wrapper (const void * a, const void * b)
{
return strcmp (* (const char **) a, * (const char **) b);
}

[Barry Schwarz]

On Tue, 18 Apr 2006 22:02:21 +0200, regis <re***@dil.univ-mrs.fr>
wrote:

Rod Pemberton wrote:

"Keith Thompson" <ks***@mib.org> wrote in message

Determining if strings are equal or different is useful. However,
determining if the last compared character in one string was above (>0) or
below (<0) the last compared character in the other, is useless and heavily
dependent on the nonportable and sometimes random ordering of the character
set. Because of this, I'd posit that strcmp() is _essentially_ a boolean
function: zero equal, non-zero if different.

It is a comparison function designed to work with qsort().

strcmp is not designed to work with qsort. Passing strcmp to qsort as
the fourth parameter requires a diagnostic.
Remove del for email

[Richard Bos]

"Rod Pemberton" <do*********@sorry.bitbuck.cmm> wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

strcmp() gives a consistent ordering of string values. Sometimes an
internally consistent ordering is all you need, for example if you
want to build a search tree.

strcmp() is not a boolean function.

I never said it was. I said it is _essentially_ a boolean function. That's
because ordering of string values is a very low use situation...

Speaking as someone who has dealt with databases containing names, I
have to snigger a bit at your naivete.

(Aside: I've never heard of a language called "ADA". I've programmed
in Ada. It's a name, not an acronym.)

True enough, although it is frequently found all capitalized.

So? main() is also frequently declared void. Red lights are frequently
driven through.

Richard

[Richard Bos]

Keith Thompson <ks***@mib.org> wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

jaysome <ja*****@spamcop.com> wrote:

Keith, you are right on. A true Boolean variable should use Boolean
opeartors such as !, and never comparison operators such as ==. A
Boolean value by definition has a binary state, so the C standard
supports it quite nicely:

/* The true condition */
if ( is_on )

/* The false condition */
if ( !is_on )

There is no reason whatsoever to compare a Boolean value to another
value like this:

if ( is_on == TRUE )

or like this:

if ( is_on == FALSE )

or like the myriad other variations of these.

Imprimis, this is a style matter; if someone finds an explicit mention
of TRUE or FALSE clearer than the presence or absence of a !, is that a
problem?

Yes, it's a problem. TRUE is presumably equal to 1, but *any*
non-zero value is considered true.

Consider this:

is_on = isalpha(c);
if (is_on == TRUE)

This can fail if isalpha returns a value other than 0 or 1, which it's
allowed to do.

Secundis, while I do agree with your style myself, there is one place
where you can't escape using == on boolean values without jumping
through silly hoops:

if (left_valve_open == right_valve_open)

Again, this fails if left_valve_open and right_valve_open have
differing non-zero values.

Yes and yes, but then you're not talking about truly boolean values in
the first place.

Richard

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Keith Thompson <ks***@mib.org> wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes: [...]

> Imprimis, this is a style matter; if someone finds an explicit mention
> of TRUE or FALSE clearer than the presence or absence of a !, is that a
> problem?

Yes, it's a problem. TRUE is presumably equal to 1, but *any*
non-zero value is considered true.

Consider this:

is_on = isalpha(c);
if (is_on == TRUE)

This can fail if isalpha returns a value other than 0 or 1, which it's
allowed to do.

> Secundis, while I do agree with your style myself, there is one place
> where you can't escape using == on boolean values without jumping
> through silly hoops:
>
> if (left_valve_open == right_valve_open)

Again, this fails if left_valve_open and right_valve_open have
differing non-zero values.

Yes and yes, but then you're not talking about truly boolean values in
the first place.

What do you mean by "truly boolean values"? Prior to C99's
introduction of _Bool, C had no such concept.

Unless they're declared as _Bool, it's a bad idea to assume that
left_valve_open and right_valve_open can only take on the values
0 and 1. Even if you carefully design your program to use only 0 and
1, there's always the risk that you (or a future maintainer) will
introduce a call to isalpha() or something similar. The resulting bug
could be very hard to track down.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Simon Biber]

regis wrote:

Oups. And to make things worse...

Should this extension of compatibility have existed between
functions taking "char*" and "void*" as arguments,
this would not have worked either with the example I had in mind,
that is, sorting an array of elements, each of type char *,
because another level of indirection is introduced:

The comparison function of qsort expects two pointers to the elements
be compared, as opposed to the elements themselves,
therefore here, behind the two "void *"
it expects two "const char **" as opposed to two "const char *"

int strcmp_wrapper (const void * a, const void * b)
{
return strcmp (* (const char **) a, * (const char **) b);
}

This function is badly named, it extends into the name space reserved
for extensions. In general, try not to start functions with 'str'.

You are also casting to the wrong type. The const is in the wrong
location, so you are actually casting away the const qualifier in the
original type.

When programming, I always try to avoid casts whenever possible:

#include <string.h>

int wrap_strcmp(const void * a, const void * b)
{
char * const * c = a;
char * const * d = b;
return strcmp(*c, *d);
}

Although this uses two extra temporary variables, I find the lack of
casts to be an important indicator that there is less likely to be an
erroneous conversion (such as yours).

Simon.

[regis]

Simon Biber wrote:

regis wrote:

int strcmp_wrapper (const void * a, const void * b)
{
return strcmp (* (const char **) a, * (const char **) b);
}

This function is badly named, it extends into the name space reserved
for extensions. In general, try not to start functions with 'str'.

You are also casting to the wrong type. The const is in the wrong
location, so you are actually casting away the const qualifier in the
original type.

When programming, I always try to avoid casts whenever possible:

#include <string.h>

int wrap_strcmp(const void * a, const void * b)
{
char * const * c = a;
char * const * d = b;
return strcmp(*c, *d);
}

Although this uses two extra temporary variables, I find the lack of
casts to be an important indicator that there is less likely to be an
erroneous conversion (such as yours).

Thank you for the correction.
If I had used the two temporary without cast, my compiler
would have warned me about the misplaced const qualifier.

--
regis