Re: Using alloca (or stmt exprs) as a function call argument is bad?

Re: Using alloca (or stmt exprs) as a function call argument is bad?

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > On Sun, Sep 23, 2001 at 10:55:43AM -0400, Kaveh R. Ghazi wrote:
 > > So have you any thoughts on how best to have gcc warn the user that
 > > they've just done something dangerous?
 > 
 > Dunno.  It'd probably be just as easy to fix it as to warn.
 > r~

What, fix alloca so that it doesn't conflict with function parameters
put on the stack?

Well, IIRC other cc compilers had this problem too as would all older
versions of gcc.  So it would be nice to still warn about it IMHO.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Using alloca (or stmt exprs) as a function call argument is bad?

[Richard Henderson]

On Mon, Sep 24, 2001 at 06:43:04PM -0400, Kaveh R. Ghazi wrote:
> What, fix alloca so that it doesn't conflict with function parameters
> put on the stack?

Yes.  You'd pre-process the CALL_EXPR, note the embedded alloca
invocation, un-nest the alloca, and replace the original argument
with a temporary.


r~

Re: Using alloca (or stmt exprs) as a function call argument is bad?

[Jan Hubicka]

> On Mon, Sep 24, 2001 at 06:43:04PM -0400, Kaveh R. Ghazi wrote:
> > What, fix alloca so that it doesn't conflict with function parameters
> > put on the stack?
> 
> Yes.  You'd pre-process the CALL_EXPR, note the embedded alloca
> invocation, un-nest the alloca, and replace the original argument
> with a temporary.
This is already done (or attempted to be done) in the call.c.

Honza
> 
> 
> r~

Re: Using alloca (or stmt exprs) as a function call argument is bad?

[Richard Henderson]

On Sun, Sep 23, 2001 at 10:55:43AM -0400, Kaveh R. Ghazi wrote:
> So have you any thoughts on how best to have gcc warn the user that
> they've just done something dangerous?

Dunno.  It'd probably be just as easy to fix it as to warn.


r~

Re: Using alloca (or stmt exprs) as a function call argument is bad?

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > On Mon, Sep 17, 2001 at 02:31:06PM -0400, Kaveh R. Ghazi wrote:
 > > And its presumably because alloca is diddling with
 > > the stack at the same time function parameters are being pushed there?
 > 
 > Yes.
 > r~

So have you any thoughts on how best to have gcc warn the user that
they've just done something dangerous?

E.g. gcc/c-typeck.c:error_init() line 4594...

I'd like to automate finding these cases.

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Using alloca (or stmt exprs) as a function call argument is bad?

[Richard Henderson]

On Mon, Sep 17, 2001 at 02:31:06PM -0400, Kaveh R. Ghazi wrote:
> And its presumably because alloca is diddling with
> the stack at the same time function parameters are being pushed there?

Yes.

> What about statement expressions?  E.g.
>  > #define foo(X) ({int bar = X; bar*bar+3;})
>  > baz(foo(3), foo(7))
> 
> Does that pose any stack problems on any target?

I don't think so.


r~

Using alloca (or stmt exprs) as a function call argument is bad?

[Kaveh R. Ghazi]

I seem to recall its not portable to use alloca as an argument to a
function call.  E.g.
 > #define strdupa(X) strcpy(alloca(strlen(X)+1),(X))

This is true even if you're only talking about gcc, let alone other
compilers, right?  And its presumably because alloca is diddling with
the stack at the same time function parameters are being pushed there?

What about statement expressions?  E.g.
 > #define foo(X) ({int bar = X; bar*bar+3;})
 > baz(foo(3), foo(7))

Does that pose any stack problems on any target?

If either is a bad idea, I suggest we issue a warning when the user
attempts it.  I've seen cases in gcc source where at least the former
is done.  I'm willing to give it a try if someone can point very
specifically where it should go.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions