However, you raised an interesting point. %s in printf expects a char *. Am
I
allowed to feed it unsigned char * or some such? What possible problems can
I
encounter there? Anyone?
Since the usual participants don't seem to want to rerun this debate,
which has been held several times, I will try to summarize.
C90 6.1.2.5 or C99 6.2.5p26 requires that "a pointer to *void* shall
have the same representation and alignment requirements as a pointer
to a character type". Although it isn't explicit, I'm sure that 'a'
is intended to be quantified as 'any', or 'each', not just 'some',
character type, and thus pointers to all three flavors of char must be
implemented the same. (And also to qualified versions thereof, by the
succeeding sentence.) And according to footnote 16 or 39,
"The same representation and alignment requirements are meant to imply
interchangeability as
arguments to functions, return values from functions, and members of
unions."
But footnotes are not normative. Plus it is not explicit if standard
library functions must use the same argument-passing mechanisms or
conventions as user-written functions, and in particular if they must
use (as-if) <stdargs.h> for variadic args which along with
unprototyped args must support this substitution, plus one for
corresponding signed/unsigned integers, explicitly in C99 6.5.2.2.
This is not just theoretical; all standard library functions are
permitted to be also implemented (shadowed) as macros, unless
#undef'ed or used in parens, and it is not too unusual for normal uses
of at least some of them (like memcpy) to be opencoded or otherwise
specially "tweaked" by the compiler. OTOH it must work to put the
address of a stdlib function in a correctly typed pointer and use that
to call it, just like for a user-written function.
So, in brief, it's not absolutely clear this particular case --
unsigned char * versus plain char * for %s -- is guaranteed. But it is
unlikely there is any sensible or even feasible way to meet all the
other things that *are* required without also doing this; and there is
such a large body of existing C code that is careless about pointers
to different flavors of char that an implementation that (perversely)
made them not work, even if arguably legal, would be unacceptable to
many many users. Certainly I have not seen anyone report here such an
implementation, and do not expect to encounter one.
If you really want to *look* for possible problems, you might try IBM
AS/400; I don't *think* its capabilities go down this fine, but ICeBW.
In years past Intel i432 and especially the several LISP machines
might be better bets, but in the unlikely case you can find one of
those still preserved/working, I'd predict its owner/user(s) don't
even *want* a C implementation.
- David.Thompson1 at worldnet.att.net
