[Gc] returning stack address without a warning
Eric.Deplagne at wanadoo.fr
Thu Oct 26 05:09:16 PDT 2006
On Thu, 26 Oct 2006 12:31:24 +0100, Andrew Haley wrote:
> Eric Deplagne writes:
> > On Thu, 26 Oct 2006 11:33:20 +0100, Andrew Haley wrote:
> > > Eric Deplagne writes:
> > > > > My goal with -Wall and similar is to at least document any remaining
> > > > > warnings in the source. The collector inherently does a few things that
> > > > > should generate warnings in "normal" code, e.g. it returns the address
> > > > > of a local to get an upper bound on the stack pointer. This also really
> > > > > applies only to gc7.
> > > >
> > > > If there's nothing clever I didn't notice on the way, using an helper
> > > > function is enough to prevent the compiler from noticing what we're doing
> > > > to that poor local variable...
> > >
> > > No, that's a bad idea. Later versions of the compiler may well see
> > > through this trick and you'll get the warning again. It is better
> > > either to use a properly supported way to the the stack address or to
> > > live with the warning than to go through such contortions.
> > Well... The first part of your "or" statement is obviouly false,
> > there is no supported way to get the stack address...
> Well, I'm talking about gcc. There is no official ISO way of doing
> it, true, but what is being done here isn't portable in any case. (Of
> course there cannot be an ISO way of doing it, since ISO C doesn't
> even mandate the use of a stack.) So, if you're using gcc you might
> as well do it in a properly supported way, and leave the warning for
> other compilers.
Is there a supported way in gcc ?
> > As for a compiler noticing this trick, it might happen, but I really
> > doubt it, as long as the helper function doesn't get inlined...
> Bingo. It's perfectly reasonable for the compiler to inline very
> small functions.
Yes... But it's doubtful it will do it without an "inline" statement...
And it might even do it with some -O option, and not check this kind
of things at that time...
> > IMHO one more function away is not such a "contortion" that it's not worth it...
> > And for the case a compiler was clever enough to still bark, I guess I would then
> > cope with the warning, having done what is possible to avoid it...
> So, if you are prepared to cope with a warning at some time in the
> future, why not simply cope with it now? Contorting code to avoid
> compiler warnings is, as they say, "the tail wagging the dog".
The point is that the single function stackptr_v1() is in itself "odd"...
Instead, each of the two functions stackptr_v2() and stackptr_v2_helper(),
is perfectly ok... It's their interraction that does the odd thing...
That should keep the compiler away from noticing in most cases...
And in the case it does notice, then I have enough respect for that to cope
with the warning...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20061026/f7335d38/attachment.pgp
More information about the Gc