Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!tut.cis.ohio-state.edu!iguana.cis.ohio-state.edu!meranda
From: meranda@iguana.cis.ohio-state.edu (deron meranda)
Newsgroups: comp.std.c
Subject: Re: ANSI C standard library
Message-ID: <116105@tut.cis.ohio-state.edu>
Date: 3 May 91 16:49:47 GMT
References: <695@taumet.com> <114913@tut.cis.ohio-state.edu> <1991May1.170750.19222@zoo.toronto.edu>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University, Department of Computer and Information Science
Lines: 67

Concerning strchr() and const char *'s...

In article <1991May1.170750.19222@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <114913@tut.cis.ohio-state.edu> meranda@iguana.cis.ohio-state.edu I write:
>>For example, consider the function strchr (section 4.11.5.2).  Clearly
>>if it were implemented entirely in C, it has to produce a plain char *
>>from a const char *.  Although most compilers will allow this with a
>>warning, it is not strictly-conforming C.
>
>Uh, where did you get that idea?  Please cite chapter and verse.  Some
>earlier drafts of ANSI C restricted pointer conversions so that this sort
>of conversion was not strictly conforming; the result was loud protests
>and the problem was fixed.
>
>It is true that you have to beware of alignment in such conversions, but
>that is not an issue here.  It is also true that if you use such a converted
>pointer to attempt to modify a "const char" variable, all bets are off.  But
>the conversion itself is strictly conforming.

It appears as if you are correct.  The Rationale 3.3.4 clearly
states that a (const char *) may be typecast to a (char *).
However, it also appears that one can not even dereference the
resulting pointer, whether or not the object is modified
(actually the behavior is undefined).  Furthermore, as you note,
alignment is no problem, not only because we are dealing with
chars, but also because qualifiers make no difference in
alignment (3.1.2.5 p25 line22).

I was confused because section 3.2.2.3 states that a plain
char * may be "automatically" converted into a const char *.
On the contrary, the Rationale 3.1.4 makes a quick statement
that the assignment of a const char * to a plain char * is
illegal.  However, (misunderstood by me) both of these
statements are within the context of having no explicit type
casts present.


Now, back to the question about implementing strchr() entirely
in strictly conforming C.  If it is not possible to convert a
const char * to a plain char *, without loosing to ability to
dereference the resulting pointer (without a cast), then at
best, strchr() can only return a pointer which can not be
directly dereferenced.

From this, it then appears to me that the following program
segment becomes illegal (or at least undefined):

   char Array [5] = { 'a', 'b', 'c', 'd', '\0' };
   char * c;

   c = strchr( Array, 'd' );
   if( c ) printf("character is %c", *c );

Clearly this should be legal under a conforming implementation
of strchr().  Therefore, am I correct in saying that strchr
can not correctly be written entirely in strictly conforming C?
I confess, that this should work on almost every possible
implementation environment, but the behavior is still undefined
as far as the standard goes --- if you follow the rules!

I would appreciate anyone's comments on this.  This behavior
seems awfully strange to me, and I am probably misreading
something rather obvious.  Even if the above was well-defined,
the mechanism is at best rather barbaric.


Deron E. Meranda  ( meranda@cis.ohio-state.edu )