🚀 go-pugleaf

This article supersedes version posted some hours ago, which omitted an
important step of reasoning.  Apologies if you already saw, or posted a
followup to, that article.  For the second time this week, my thanks go
to Jutta Degener for email pointing out my error.

				---

In another subthread, I wrote:

> Consider *this* code:
> 
> 	#include <comp/lang/c/FAQ-list.h> /* :-) */   /* for pstrcmp() */
> 
> 	char *list[N_ENTRIES];
> 		/* read n (<= N_ENTRIES) strings into list */
> 	qsort (list, sizeof (char *), n, pstrcmp);

In addition to being an argument of intent in the situation I was writing
about, this code also directs us to a similar argument in another matter,
where I think the standard is deficient.

Suppose you had implemented a qsort() in standard C, and it was invoked as
shown above.  Now consider the first argument.

Sections 3.2.2.3/6.2.3.3 and 3.3.4/6.3.4 allow a pointer to an arbitrary
object (here, the decayed "list", of type char **) to be converted to
either char * or void * and back without loss of information, so, in the
presence of prototypes, the invocation is legal in that respect.  However,
there is no specification in the standard of where the pointer resulting
from conversion to char * must point!

I think the standard should specify that the pointer so obtained points
to the FIRST byte of the object that the original (here, type char **)
pointer was pointing to (here, the first byte of list[0]).  Without such
a requirement, I can see no reasonable way for qsort() to be implemented
in standard C and not break such simple code as the above -- for how on
earth could it know where to find the elements of the array list, to do
the necessary operations on them?

Speaking of qsort() is only suggestive; there's no requirement in the
standard for qsort() to BE implementable in C.  But in fact the same
problem arises with ANY function that has to access an object "for its
bytes".  That is, any code that uses memcmp() or fread() or any of
several other such library functions, to access an object which is not
made up of elements of character type, faces a similar problem.

Since such code is commonplace today and there is often no other
reasonable way to write it, I must conclude that the standard-writers
intended that the conversion work as I said, but omitted to include
a requirement specifying this.


Note that this matter is entirely independent of the topic of the other
subthread where the above code formed an example; in this one, it doesn't
matter whether or not the objects in question are pointers.
-- 
Mark Brader            | "If you need features not found in any language,
SoftQuad Inc., Toronto |  you can try your hand at creating your own.
utzoo!sq!msb           | (Mind you, language design is incredibly difficult.
msb@sq.com             |  It is easy to create an unholy mess.)" -- Chris Torek

This article is in the public domain.