[PATCH] parsers: fix typing and sign issues

Matt Mackall mpm at selenic.com
Wed Sep 10 15:19:42 CDT 2014


On Wed, 2014-09-10 at 08:34 +0200, Henrik Stuart wrote:
> On 2014-09-09 22:58, Matt Mackall wrote:
> > On Sat, 2014-09-06 at 22:25 +0200, Henrik Stuart wrote:
> >> # HG changeset patch
> >> # User Henrik Stuart <hg at hstuart.dk>
> >> # Date 1410029932 -7200
> >> #      Sat Sep 06 20:58:52 2014 +0200
> >> # Node ID 41abcba2e5d08ac00abf2df5f6cbe2fe3a7e2e6e
> >> # Parent  c5df4af17110838b713d6c9ec3b824fb0b6c1b33
> >> parsers: fix typing and sign issues
> >>
> >> Normalized the use of types in the parser to avoid signed/unsigned 
> >> mismatches
> >> and normalized const-ness call to free to omit warnings with both 
> >> gcc and
> >> Microsoft Visual C++.
> >
> >> -		free(self->offsets);
> >> +		free((char**)self->offsets);
> >
> > Bleck. I can't get GCC to give a warning about this, can you?
> 
> Not for const char**, but it'll happily warn about it with const char*, 
> strangely
> enough. I believe gcc is wrong in this regard.

Well, there's an old philosophical argument about whether the const-ness
of an argument ends when its lifetime ends (ie when you call free). C
definitely falls on the "no" side of the debate, based on the way the
standard specifies const and free[1]. The free() call will itself
probably modify the contents of pointer so it's considered to violate
the const semantics and thus takes an unqualified void * (even though
behavior of pointer accesses after entry to free is definitely in
"undefined" territory).

C++ falls on the "yes" side of the debate: you can both initialize and
destroy const object and const-ness begins when the constructor ends and
ends when the destructor begins.

[1] Though there are things like kfree(const void *) in the Linux kernel
that take a different view.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list