At Sun, 19 Jul 2009 20:00:56 +0000, David Holland
<dholland-tech%netbsd.org@localhost> wrote:
Subject: Re: why cast to char* through void*
>
> On Sat, Jul 04, 2009 at 02:13:06PM -0400, Greg A. Woods wrote:
> > Indeed that's also probably the real reason why lint and gcc are giving
> > different warnings here -- lint is sticking closer to the "strictly
> > undefined" side of the fence, and gcc (being the actual implementation)
> > is saying that the cast through (char*) is OK because it will do what's
> > expected here (i.e. this implementation has a well defined behaviour).
>
> Well, maybe it does. Is this behavior documented? Is it something the
> gcc folks expect/intend to support down the road? My guess is that it
> isn't.
That's a good question.
Typically my experience with compilers in general is that if we're
talking about a warning message that's simply not present in a given
implementation, and given that the code at question still actually has
the desired behaviour, then that is the sole necessary "documentation".
This is especially true for what we might call common classes of
implementations where they all define the strictly undefined behaviour
in exactly the same way.
In general in this kind of case I think we can also be particularly
certain that the LINTED comment is appropriate too since all too much of
the code in the whole system would likely break if the pointer
representation were to be changed in such a way that the behaviour of
this code would change. However if someone did want to port to a system
which does define some strictly undefined behaviour in a different way
then my next comment applies:
> > Lint(1) should probably have an option to ignore LINTED comments though
> > to aid those preparing a port to another environment. Perhaps '-p'
> > should do that by default.
> >
> > Dumbing down lint, and/or making it specific to only one dialect and/or
> > implementation, would be a bad thing.
>
> lint should be made smarter so as to require less LINTED markup.
In cases like this that's a contradiction of terms.
Yes, in general lint should be made as smart as possible, for some
definition of "smart".
However in this case lint is already trying to be smarter than the
compiler and it is warning that there could be problems if this code is
ported to an implementation that has different pointer representations.
The LINTED markup says to lint that it's OK, we know we're abusing a
strictly undefined behaviour of the implementation, and hopefully the
human-only comment part of that markup says that we know this because we
know that currently all the interesting implementations we will support
all fall into one class and they all actually define this case of
strictly undefined behaviour in the same way.
To that extent whomever said this code shouldn't be run through lint in
the first place was somewhat right. However I believe in running all
code through lint as often as possible, in front of as many eyes as
possible, and certainly after every change, and to that end some
compromise must be made between having lint catch every case where the
code is exploiting strictly undefined corners in the language
definition, and where lint is simply repeating all the same checks the
compiler itself and can actually do.
To that end the LINTED comment is making lint "smarter" -- with the help
of the human maintainer who can decide which cases are OK given the
current target implementation(s), and which cases are actually bugs.
With C there's always going to be a conflict between the strict language
definition with all it's demon-invoking clauses, and actual
implementations which give well defined meaning to almost all these
things; and there are always going to be programmers who will want to
exploit the defined behaviour of current, or common, implementations and
ignore the fact that the standard doesn't require all possible
conforming implementations to behave identically.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack
<woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Secrets of the Weird
<woods%weird.com@localhost>
Attachment:
pgpri0Dtx0FTr.pgp
Description: PGP signature