At Thu, 4 Mar 2010 02:22:35 +0000, David Holland
<dholland-sourcechanges%netbsd.org@localhost> wrote:
Subject: Re: CVS commit: src/share/man/man3
>
> On Wed, Mar 03, 2010 at 12:58:33PM -0500, Greg A. Woods wrote:
> > I believe that __UNCONST() in particular is _never_ absolutely necessary
> > -- it may sometimes save a very few cycles and a few bytes of storage,
> > but that's the best it can do.
>
> No such luck, at least not until C grows a stronger type system. See
> for example strchr(3).
I don't think a stronger type system would really change this issue
fundamentally unless it was one which was so radical as to change the
entire language -- All that may really be needed is a new kind of
qualifier, one that tells the compiler a return value (or other internal
variable) has the same "const" status as some given input parameter
("const_if_{parameter-name}_const" or some such similar nonsense).
While strchr()'s interface, and that of strrchr() of course, are indeed
excellent examples this issue, the use of __UNCONST() within their
implementation to hide silly warnings that might be encountered by
compiling their implementations doesn't really "fix" anything except the
silly warnings. The code _must_ do what it _should_ not do. :-) And so
I think what I said about __UNCONST() being unnecessary remains. The
warning it hides is really still valid. IMO it's just sad that all
users of those functions won't normally (i.e. by default, with the
ability to turn it off) see a similar warning when they use these
functions so as to be made aware of the limitations of their
declarations.
I.e. the users of strchr() and strrchr() must understand that their
return values really cannot be considered to point to writable storage,
regardless of the lack of a "const" qualifier on their return type
declarations.
As Harbison and Steele say, "The return value of these functions is a
pointer to non-const, but in fact the object designated will be const if
the first argument points to a const object. In that case, storing a
value into the object designated by the return pointer will result in
undefined behaviour." The const qualifier on the function's first
parameter is after all just a promise by strchr() that _it_ will not
modify what that pointer points at, and nothing more. Unfortunately
because of the choices made in the standard, the compiler cannot help
the user make similar promises about the use of the return value when
and if necessary.
A similar warning should probably appear in strchr(3) and strrchr(3) and
the manual pages of any other functions with similar limitations.
Similar kinds of discussion might also be appropriate in __UNCONST(3)
such that users defining functions with similar issues as strchr(3) et
al can also make appropriate choices.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpphqNDJQt7k.pgp
Description: PGP signature