🚀 go-pugleaf

In article <18965@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> In article <18928:Jan1916:26:3291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >No. Unless I'm mistaken, the objects being passed in are pointers to
> >arrays of char, while the objects expected are pointers to char. There
> >is no implicit conversion that justifies this, though undoubtedly it
> >works on most machines.
> How does a pointer to an unknown number of characters differ from a
> pointer to a known number of characters when passed as an argument?

It doesn't. It does, however, differ from a pointer to an *array* of
characters.

> qsort() invokes scmp() with the pointer to an array of UT_NAMESIZE
> characters.  scmp() is expecting a pointer to a character, which is
> coincidentally the same type object as "char a[UT_NAMESIZE]" since
> any "array of type X" type parameters are converted to "pointer to
> type X object" parameters.  I believe this is plainly specified
> both by ANSI-C and K&R-Classic.

scmp() does not get passed a char [UT_NAMESIZE]. It gets passed a
pointer to a char [UT_NAMESIZE]. You claim there is an equivalence
between pointer to array of char and pointer to char? You claim it's
spelled out in K&R? I don't believe you.

Of course, most implementations use the same type for all pointers
internally. But what would happen on a machine where pointers to words
are stored differently (say as the number of bytes divided by 4) while
pointers to characters are stored as byte indices? Then scmp() will
treat its arguments as byte indices, when in fact they could be a factor
of 4 off.

---Dan