Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23515 > unrolled thread

qsort man page

Back to article view | Back to comp.lang.c

Contents

  qsort man page Bill Cunningham <billcun@suddenlink.net> - 2012-07-21 14:14 -0700
    Re: qsort man page Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-21 22:57 +0100
      Re: qsort man page Bill Cunningham <billcun@suddenlink.net> - 2012-07-21 18:07 -0700
        Re: qsort man page Mark Storkamp <mstorkamp@yahoo.com> - 2012-07-23 08:49 -0500
          Re: qsort man page Bill Cunningham <billcun@suddenlink.net> - 2012-07-23 10:44 -0700
            Re: qsort man page tom st denis <tom@iahu.ca> - 2012-07-26 09:02 -0700
              Re: qsort man page John Gordon <gordon@panix.com> - 2012-07-26 16:41 +0000
                Re: qsort man page tom st denis <tom@iahu.ca> - 2012-07-26 09:59 -0700
        Re: qsort man page Ike Naar <ike@sverige.freeshell.org> - 2012-07-23 14:43 +0000
          Re: qsort man page Bill Cunningham <billcun@suddenlink.net> - 2012-07-23 13:16 -0700
            Re: qsort man page Barry Schwarz <schwarz45@yahoo.com> - 2012-07-23 13:29 -0700
              Re: qsort man page Bill Cunningham <billcun@suddenlink.net> - 2012-07-23 16:56 -0700
                Re: qsort man page Noob <root@localhost> - 2012-07-24 09:29 +0200
                  Re: qsort man page Keith Thompson <kst-u@mib.org> - 2012-07-24 23:17 -0700
                Re: qsort man page Barry Schwarz <schwarz45@yahoo.com> - 2012-07-25 09:51 -0700
                  Re: qsort man page Bill Cunningham <billcun@suddenlink.net> - 2012-07-25 20:51 -0700
                    Re: qsort man page Barry Schwarz <schwarz45@yahoo.com> - 2012-07-26 14:27 -0700
                      Re: qsort man page Bill Cunningham <billcun@suddenlink.net> - 2012-07-26 18:20 -0700
                        Re: qsort man page Barry Schwarz <schwarz45@yahoo.com> - 2012-07-28 07:24 -0700
          Re: qsort man page pete <pfiland@mindspring.com> - 2012-07-23 23:39 -0400
      Re: qsort man page pete <pfiland@mindspring.com> - 2012-07-22 00:11 -0400
        Re: qsort man page Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-22 14:41 +0100
          Re: qsort man page pete <pfiland@mindspring.com> - 2012-07-22 13:01 -0400
            Re: qsort man page Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-22 21:36 +0100
              Re: qsort man page pete <pfiland@mindspring.com> - 2012-07-23 22:40 -0400
                Re: qsort man page pacman@kosh.dhis.org (Alan Curry) - 2012-07-24 04:29 +0000
                  Re: qsort man page Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-24 11:40 +0100
                    Re: qsort man page pete <pfiland@mindspring.com> - 2012-07-24 22:06 -0400
          Re: qsort man page Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:38 -0700
    Re: qsort man page pete <pfiland@mindspring.com> - 2012-07-23 23:34 -0400
      Re: qsort man page pete <pfiland@mindspring.com> - 2012-07-24 00:07 -0400
    Re: qsort man page "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-24 16:36 -0700

Page 2 of 2 — ← Prev page 1 [2]

#23542

Ben Bacarisse wrote:
> 
> Bill Cunningham <billcun@suddenlink.net> writes:
> 
> > This is from the qsort man page.
> > I don't quite understand why there is
> > a comment here saying that arguments to this generic function
> > to pass to qsort is a pointer to pointer.
> > It looks to me like cmpstringp takes
> > a generic pointer. Not pointer to pointer. Why does the comment say
> > pointer to pointer?
> 
> Yup, cmpstringp takes two generic pointers,
> but in order to do anything
> useful with them it must know to what kind of data they really point.
> If the array being sorted is an array of ints,
> then the two pointers are
> really pointing at int data,
> so casting to int * and dereferencing would
> be the right thing to do (you'd write *(const int *)p1).
> 
> But, argv -- the array being sorted here -- is an array of character
> pointers so the comparisson function gets passed pointers to a pair of
> these character pointers, converted to "generic" (void *) pointers.
> 
> >  This is confusing me also with the strcmp
> > parameters which are cast as a pointer to pointer and dereferenced. I
> > hope I'm clear. THanks.
> >
> > Bill
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > static int
> > cmpstringp(const void *p1, const void *p2)
> > {
> >     /* The actual arguments to this function are "pointers to
> >        pointers to char", but strcmp(3) arguments are "pointers
> >        to char", hence the following cast plus dereference */
> >     return strcmp(* (char * const *) p1, * (char * const *) p2);
> > }

I think that the way that the const keyword
is used in the return statement,
shows some confusion on the part of the author.

It causes the result of the dereference
in the strcmp function call, to be const qualified,
which is neither required nor consistent
with the parameters of strcmp
being pointers to const qualified types.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#23572

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>> 
>> Bill Cunningham <billcun@suddenlink.net> writes:
<snip>
>> > #include <stdio.h>
>> > #include <stdlib.h>
>> > #include <string.h>
>> > static int
>> > cmpstringp(const void *p1, const void *p2)
>> > {
>> >     /* The actual arguments to this function are "pointers to
>> >        pointers to char", but strcmp(3) arguments are "pointers
>> >        to char", hence the following cast plus dereference */
>> >     return strcmp(* (char * const *) p1, * (char * const *) p2);
>> > }
>
> I think that the way that the const keyword
> is used in the return statement,
> shows some confusion on the part of the author.
>
> It causes the result of the dereference
> in the strcmp function call, to be const qualified,
> which is neither required nor consistent
> with the parameters of strcmp
> being pointers to const qualified types.

I am not so sure.  The const that is there is a Good Const.  Omitting it
might cause a warning (gcc will oblige) about "casting away" const.  The
question as to whether there should be another:

   *(const char *const *)p1

is not clear cut to me.  The cast, as written, is a correct reflection
of the object being sorted, and there is some documentary merit in doing
that -- cast only to the type of the thing being sorted.

Your suggestion, to cast to the type needed by strcmp, is not wrong but,
in general, I would avoid it.  If you cast to the type of the actual
data, the compiler will warn you if this type is not suitable for the
call being made.  In essence, you get a little more checking.

No big deal in this case because strcmp takes "safer" arguments that
those being passed, but if I were forced to used some odd compare
function like

  int caseless_compare_that_alters_the_data(char *s1, char *s2);

to sort an array of const char **, my rule would show up a problem.  You
cast to the type of the actual data, and the call to this function will
be flagged up as dangerous.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23581

Ben Bacarisse wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Ben Bacarisse wrote:
> >>
> >> Bill Cunningham <billcun@suddenlink.net> writes:
> <snip>
> >> > #include <stdio.h>
> >> > #include <stdlib.h>
> >> > #include <string.h>
> >> > static int
> >> > cmpstringp(const void *p1, const void *p2)
> >> > {
> >> >     /* The actual arguments to this function are "pointers to
> >> >        pointers to char", but strcmp(3) arguments are "pointers
> >> >        to char", hence the following cast plus dereference */
> >> >     return strcmp(* (char * const *) p1, * (char * const *) p2);
> >> > }
> >
> > I think that the way that the const keyword
> > is used in the return statement,
> > shows some confusion on the part of the author.
> >
> > It causes the result of the dereference
> > in the strcmp function call, to be const qualified,
> > which is neither required nor consistent
> > with the parameters of strcmp
> > being pointers to const qualified types.
> 
> I am not so sure.  The const that is there is a Good Const.
> Omitting it might cause a warning
> (gcc will oblige) about "casting away" const. 
> The question as to whether there should be another:
> 
>    *(const char *const *)p1
> 
> is not clear cut to me. 
> The cast, as written, is a correct reflection
> of the object being sorted,
> and there is some documentary merit in doing that
> -- cast only to the type of the thing being sorted.

There is no const in the type of the data being sorted.
The array being sorted by cmpstringp in the example, 
is argv, which is an array of (char *) type elements.

The const is introduced by the parameter type of cmpstringp.

> Your suggestion, to cast to the type needed by strcmp,
> is not wrong but, in general, I would avoid it. 
> If you cast to the type of the actual data,
> the compiler will warn you if this type is not suitable for the
> call being made.  In essence, you get a little more checking.

> No big deal in this case because strcmp takes "safer" arguments that
> those being passed, but if I were forced to used some odd compare
> function like
> 
>   int caseless_compare_that_alters_the_data(char *s1, char *s2);
> 
> to sort an array of const char **,
> my rule would show up a problem. 
> You cast to the type of the actual data,
> and the call to this function will be flagged up as dangerous.


-- 
pete

[toc] | [prev] | [next] | [standalone]

#23584

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>> 
>> pete <pfiland@mindspring.com> writes:
>> 
>> > Ben Bacarisse wrote:
>> >>
>> >> Bill Cunningham <billcun@suddenlink.net> writes:
>> <snip>
>> >> > #include <stdio.h>
>> >> > #include <stdlib.h>
>> >> > #include <string.h>
>> >> > static int
>> >> > cmpstringp(const void *p1, const void *p2)
>> >> > {
>> >> >     /* The actual arguments to this function are "pointers to
>> >> >        pointers to char", but strcmp(3) arguments are "pointers
>> >> >        to char", hence the following cast plus dereference */
>> >> >     return strcmp(* (char * const *) p1, * (char * const *) p2);
>> >> > }
>> >
>> > I think that the way that the const keyword
>> > is used in the return statement,
>> > shows some confusion on the part of the author.
>> >
>> > It causes the result of the dereference
>> > in the strcmp function call, to be const qualified,
>> > which is neither required nor consistent
>> > with the parameters of strcmp
>> > being pointers to const qualified types.
>> 
>> I am not so sure.  The const that is there is a Good Const.
>> Omitting it might cause a warning
>> (gcc will oblige) about "casting away" const. 
>> The question as to whether there should be another:
>> 
>>    *(const char *const *)p1
>> 
>> is not clear cut to me. 
>> The cast, as written, is a correct reflection
>> of the object being sorted,
>> and there is some documentary merit in doing that
>> -- cast only to the type of the thing being sorted.
>
> There is no const in the type of the data being sorted.
> The array being sorted by cmpstringp in the example, 
> is argv, which is an array of (char *) type elements.
>
> The const is introduced by the parameter type of cmpstringp.

That level of const and pointer is removed by the *.  maybe I should
have said "cast to a const pointer to the type thing being pointed to"
but it was all getting a bit wordy.

You see my point, I hope.  One level of pointer and const comes from
using qsort, all the rest comes from the type of thing being sorted.

>> Your suggestion, to cast to the type needed by strcmp,
>> is not wrong but, in general, I would avoid it. 
>> If you cast to the type of the actual data,
>> the compiler will warn you if this type is not suitable for the
>> call being made.  In essence, you get a little more checking.
>
>> No big deal in this case because strcmp takes "safer" arguments that
>> those being passed, but if I were forced to used some odd compare
>> function like
>> 
>>   int caseless_compare_that_alters_the_data(char *s1, char *s2);
>> 
>> to sort an array of const char **,
>> my rule would show up a problem. 
>> You cast to the type of the actual data,
>> and the call to this function will be flagged up as dangerous.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23641

Ben Bacarisse wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Ben Bacarisse wrote:
> >>
> >> pete <pfiland@mindspring.com> writes:
> >>
> >> > Ben Bacarisse wrote:
> >> >>
> >> >> Bill Cunningham <billcun@suddenlink.net> writes:
> >> <snip>
> >> >> > #include <stdio.h>
> >> >> > #include <stdlib.h>
> >> >> > #include <string.h>
> >> >> > static int
> >> >> > cmpstringp(const void *p1, const void *p2)
> >> >> > {
> >> >> >     /* The actual arguments to this function are "pointers to
> >> >> >        pointers to char", but strcmp(3) arguments are
> >> >> >        "pointers
> >> >> >        to char", hence the following cast plus dereference */
> >> >> >     return strcmp(* (char * const *) p1, * (char * const *) p2);
> >> >> > }
> >> >
> >> > I think that the way that the const keyword
> >> > is used in the return statement,
> >> > shows some confusion on the part of the author.
> >> >
> >> > It causes the result of the dereference
> >> > in the strcmp function call, to be const qualified,
> >> > which is neither required nor consistent
> >> > with the parameters of strcmp
> >> > being pointers to const qualified types.
> >>
> >> I am not so sure.  The const that is there is a Good Const.
> >> Omitting it might cause a warning
> >> (gcc will oblige) about "casting away" const.
> >> The question as to whether there should be another:
> >>
> >>    *(const char *const *)p1
> >>
> >> is not clear cut to me.
> >> The cast, as written, is a correct reflection
> >> of the object being sorted,
> >> and there is some documentary merit in doing that
> >> -- cast only to the type of the thing being sorted.
> >
> > There is no const in the type of the data being sorted.
> > The array being sorted by cmpstringp in the example,
> > is argv, which is an array of (char *) type elements.
> >
> > The const is introduced by the parameter type of cmpstringp.
> 
> That level of const and pointer is removed by the *.  maybe I should
> have said "cast to a const pointer to the type thing being pointed to"
> but it was all getting a bit wordy.
> 
> You see my point, I hope.  One level of pointer and const comes from
> using qsort, all the rest comes from the type of thing being sorted.
> 
> >> Your suggestion, to cast to the type needed by strcmp,
> >> is not wrong but, in general, I would avoid it.
> >> If you cast to the type of the actual data,
> >> the compiler will warn you if this type is not suitable for the
> >> call being made.  In essence, you get a little more checking.
> >
> >> No big deal in this case because strcmp
> >> takes "safer" arguments that
> >> those being passed, but if I were forced to used some odd compare
> >> function like
> >>
> >>   int caseless_compare_that_alters_the_data(char *s1, char *s2);
> >>
> >> to sort an array of const char **,
> >> my rule would show up a problem.
> >> You cast to the type of the actual data,
> >> and the call to this function will be flagged up as dangerous.

I don't know.
Maybe I am being wrongly influenced by the warnings
generated by the compiler that I am using.

When I rewrite and compile cmpstringp to do the type conversions 
through assignment to intermediate objects onstead of by casts, 
I get warnings when the intermediate objects are of the same type 
as the cast from the original version of cmpstringp, (char *const *).

I don't get warnings when the intermediate objects are 
of type (const char **).


/* BEGIN new.c */

#include <string.h>

int
cmpstringp(const void *p1, const void *p2)
{
    return strcmp(* (char * const *) p1, * (char * const *) p2);
}

int
cmpstringp_2(const void *p1, const void *p2)
{
    /*
    ** This function is OK
    */
    const char **pp1;
    const char **pp2;

    pp1 = p1;
    pp2 = p2;

    return strcmp(*pp1, *pp2);
}

int
cmpstringp_3(const void *p1, const void *p2)
{
    /*
    ** This function generates warnings
    */
    char *const *pp1;
    char *const *pp2;

    pp1 = p1;
    pp2 = p2;
    /*
    ** (35) : warning C4090: '=' : different 'const' qualifiers
    ** (36) : warning C4090: '=' : different 'const' qualifiers
    */
    return strcmp(*pp1, *pp2);
}

/* END new.c */


-- 
pete

[toc] | [prev] | [next] | [standalone]

#23650

In article <500E0B1B.653C@mindspring.com>,
pete  <pfiland@mindspring.com> wrote:
>
>I don't know.
>Maybe I am being wrongly influenced by the warnings
>generated by the compiler that I am using.
>
>When I rewrite and compile cmpstringp to do the type conversions 
>through assignment to intermediate objects onstead of by casts, 
>I get warnings when the intermediate objects are of the same type 
>as the cast from the original version of cmpstringp, (char *const *).

That's strange. The assignments aren't any worse than the cast. I think
they're slightly better because they're more constrained (the cast will
convert any pointer to any other pointer; the assignment requires compatible
types or void).

>
>I don't get warnings when the intermediate objects are 
>of type (const char **).
>
>
>/* BEGIN new.c */
>
>#include <string.h>
>
>int
>cmpstringp(const void *p1, const void *p2)
>{
>    return strcmp(* (char * const *) p1, * (char * const *) p2);
>}
>
>int
>cmpstringp_2(const void *p1, const void *p2)
>{
>    /*
>    ** This function is OK
>    */
>    const char **pp1;
>    const char **pp2;
>
>    pp1 = p1;
>    pp2 = p2;

gcc warns here.
new.c: In function 'cmpstringp_2':
new.c:20: warning: assignment discards qualifiers from pointer target type
new.c:21: warning: assignment discards qualifiers from pointer target type

It didn't even need -Wall to produce those warnings. They're pretty severe.
And they're right. After the assignments, *pp1 = "oops" would be allowed
according to the type of pp1, but it's pointing to something that the caller
of the function didn't give you permission to modify.

>
>    return strcmp(*pp1, *pp2);
>}
>
>int
>cmpstringp_3(const void *p1, const void *p2)
>{
>    /*
>    ** This function generates warnings
>    */
>    char *const *pp1;
>    char *const *pp2;
>
>    pp1 = p1;
>    pp2 = p2;
>    /*
>    ** (35) : warning C4090: '=' : different 'const' qualifiers
>    ** (36) : warning C4090: '=' : different 'const' qualifiers
>    */
>    return strcmp(*pp1, *pp2);
>}
>
>/* END new.c */

gcc doesn't find anything wrong with cmpstringp_3 even with more warnings
enabled. Could you try your compiler with typedefs for the inner pointer?

typedef char *string;
typedef const char *fixedstring;

int
cmpstringp_4(const void *p1, const void *p2)
{
    fixedstring *pp1;
    fixedstring *pp2;

    pp1 = p1;
    pp2 = p2;

    return strcmp(*pp1, *pp2);
}

int
cmpstringp_5(const void *p1, const void *p2)
{
    const string *pp1;
    const string *pp2;

    pp1 = p1;
    pp2 = p2;
    return strcmp(*pp1, *pp2);
}

cmpstringp_4 and cmpstringp_5 should be exactly equivalent to cmpstringp_2
and cmpstringp_3 respectively, unless I messed up. gcc treats them the same.
Warnings on cmpstringp_4, none on cmpstringp_5.

[toc] | [prev] | [next] | [standalone]

#23664

pacman@kosh.dhis.org (Alan Curry) writes:

> In article <500E0B1B.653C@mindspring.com>,
> pete  <pfiland@mindspring.com> wrote:
>>
>>I don't know.
>>Maybe I am being wrongly influenced by the warnings
>>generated by the compiler that I am using.
>>
>>When I rewrite and compile cmpstringp to do the type conversions 
>>through assignment to intermediate objects onstead of by casts, 
>>I get warnings when the intermediate objects are of the same type 
>>as the cast from the original version of cmpstringp, (char *const *).
>
> That's strange.

I echo that.  gcc 4.6.3 gives the warnings for cmpstringp_2 as one would
expect and not for cmpstringp_3 (again as one would expect).

> The assignments aren't any worse than the cast. I think
> they're slightly better because they're more constrained (the cast will
> convert any pointer to any other pointer; the assignment requires compatible
> types or void).

With the extra flexibility (over plain compatibility) that:

  "the type pointed to by the left has all the qualifiers of the type
  pointed to by the right"

There should be a name for this -- maybe "assignment compatible".  It
applies to plain assignment and to argument passing which happens "as if
by assignment".

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23703

Ben Bacarisse wrote:
> 
> pacman@kosh.dhis.org (Alan Curry) writes:
> 
> > In article <500E0B1B.653C@mindspring.com>,
> > pete  <pfiland@mindspring.com> wrote:

> >>Maybe I am being wrongly influenced by the warnings
> >>generated by the compiler that I am using.

> > That's strange.
> 
> I echo that. 
> gcc 4.6.3 gives the warnings for cmpstringp_2 as one would
> expect and not for cmpstringp_3 (again as one would expect).

Thank you. 
It appears that I *have* 
been wrongly influenced by the compiler that I'm using.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#26074

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> pete <pfiland@mindspring.com> writes:
>
>> Ben Bacarisse wrote:
>>> 
>>> Bill Cunningham <billcun@suddenlink.net> writes:
> <snip>
>>> > #include <stdio.h>
>>> > #include <stdlib.h>
>>> > #include <string.h>
>>> > static int
>>> > cmpstringp(const void *p1, const void *p2)
>>> > {
>>> >     /* The actual arguments to this function are "pointers to
>>> >        pointers to char", but strcmp(3) arguments are "pointers
>>> >        to char", hence the following cast plus dereference */
>>> >     return strcmp(* (char * const *) p1, * (char * const *) p2);
>>> > }
>>
>> I think that the way that the const keyword
>> is used in the return statement,
>> shows some confusion on the part of the author.
>>
>> It causes the result of the dereference
>> in the strcmp function call, to be const qualified,
>> which is neither required nor consistent
>> with the parameters of strcmp
>> being pointers to const qualified types.
>
> I am not so sure.  The const that is there is a Good Const.  Omitting it
> might cause a warning (gcc will oblige) about "casting away" const.  The
> question as to whether there should be another:
>
>    *(const char *const *)p1
>
> is not clear cut to me.  The cast, as written, is a correct reflection
> of the object being sorted, and there is some documentary merit in doing
> that -- cast only to the type of the thing being sorted.   [snip]

It is a correct reflection of the object being _compared_.
It is not a correct reflection of the object being _sorted_,
which must be writable so it can be moved within the larger
array.

[toc] | [prev] | [next] | [standalone]

#23644

Bill Cunningham wrote:
> 
> This is from the qsort man page. I don't quite understand why there is
> a comment here saying that arguments to this generic function to pass
> to qsort is a pointer to pointer.
> It looks to me like cmpstringp takes
> a generic pointer. Not pointer to pointer. Why does the comment say
> pointer to pointer? 

Because the argument that qsort will pass to cmpstringp,
when qsort calls cmpstringp,
is a pointer to a pointer.

> This is confusing me also with the strcmp
> parameters which are cast as a pointer to pointer and dereferenced.

The argument that qsort will pass to cmpstringp,
when qsort calls cmpstringp,
is a pointer to a pointer.

> static int
> cmpstringp(const void *p1, const void *p2)
> {
>     /* The actual arguments to this function are "pointers to
>        pointers to char", but strcmp(3) arguments are "pointers
>        to char", hence the following cast plus dereference */
>     return strcmp(* (char * const *) p1, * (char * const *) p2);
> }



-- 
pete

[toc] | [prev] | [next] | [standalone]

#23648

pete wrote:
> 
> Bill Cunningham wrote:
> >
> > This is from the qsort man page. I don't quite understand why there is
> > a comment here saying that arguments to this generic function to pass
> > to qsort is a pointer to pointer.
> > It looks to me like cmpstringp takes
> > a generic pointer. Not pointer to pointer. Why does the comment say
> > pointer to pointer?
> 
> Because the argument that qsort will pass to cmpstringp,
> when qsort calls cmpstringp,
> is a pointer to a pointer.

The actual pointers passed by qsort could be of any type,
but the elements of the array being sorted are pointers,
and the pointers passed to cmpstringp from qsort,
will point to those pointer elements.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#23699

On Jul 21, 10:14 pm, Bill Cunningham <bill...@suddenlink.net> wrote:
> This is from the qsort man page. I don't quite understand why there is
> a comment here saying that arguments to this generic function to pass
> to qsort is a pointer to pointer. It looks to me like cmpstringp takes
> a generic pointer. Not pointer to pointer. Why does the comment say
> pointer to pointer?  This is confusing me also with the strcmp
> parameters which are cast as a pointer to pointer and dereferenced. I
> hope I'm clear. THanks.

Just answer me this: Are you trolling, or are you just an incredibly
slow learner? I mean you have been posting questions of a confused
beginner for as far as I can remember.

Note: Any answer that you give, including none, will obviously answer
my question.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web