home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c
- Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!uunet.ca!wildcan!sq!msb
- From: msb@sq.sq.com (Mark Brader)
- Subject: Conversion to char* or void* (was: Must an object remain ...)
- Message-ID: <1992Nov19.202750.5142@sq.sq.com>
- Summary: An error of omission in the standard; revised posting
- Supersedes: <1992Nov19.062712.13431@sq.sq.com>
- Organization: SoftQuad Inc., Toronto, Canada
- References: <1992Nov18.104542.8499@thunder.mcrcim.mcgill.edu> <1992Nov19.061601.13164@sq.sq.com>
- Date: Thu, 19 Nov 92 20:27:50 GMT
- Lines: 62
-
- 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.
-