[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

------- Comment #25 from rogerio at rilhas dot com  2010-08-11 19:51 -------
(In reply to comment #24)
> (In reply to comment #22)
> > 
> > If GCC supports cdecl on a x86 plaform then it must support the packing of
> > parameters as defined for x86 (it is not standardize that I know of, but it is
> > well defined). I sugest reading
> > http://en.wikipedia.org/wiki/X86_calling_conventions for a number of references
> > on this parameter packing in the stack, one of my favorites is
> > "http://sco.com./developers/devspecs/abi386-4.pdf" where you can read in
> > "Figure 3-48: C Stack Frame" how the parameters should be placed on the stack.
> That's a good reference. Did you see page 70?
> If you're not interested in writing portable code, don't blame the compiler.
> > Anyway, that enough for me, I already spent way too much energy and time 
> At least we can agree on that.

The reason for the reference of page 70 is exactly because of compilers like
GCC which claim to be cdecl compliant and are not. If GCC would do what it
claims to do and be cdecl compliant I would not blame the compiler and my code
(and code from many others) would be portable.

In other words my code is not portable because GCC is not doing what it should.
GCC causes code not to be portable a lot of times, like in the following case
(which does not compile because of GCC's shortcommings):

class Temp {
public:
Temp(int b);
Temp(Temp& t);
void operator=(Temp& t);
};

void func(int a, class Temp& b, int c);

func(10, Temp(20), 30); // error

This code does not compile in GCC, and so is not portable. That's shortcomming
of GCC that makes my code be not portable, not me. Its GCC's fault that code
that invokes Temp(20) as a parameter is not portable, not the programmer's
fault.

Unfortunately, conversations like this one show that GCC will never be perfect,
because people like you will insist that the compiler doesn't need to do what I
said it should (even when facing the obvious references that I've posted), and
prove that page 70 is right about warning programmers not to rely on compilers
to do correct parameter placements.

My personal experience is that GCC is the cause for such portability problems.
You still insist that GCC doesn't need to improve in this respect, and that
shows why GCC will never be as good as other compilers. Microsoft, for example,
appreciates comments like mine because it helps them improve the product, but
you just want to dismiss it as bad code on my part. I know Microsoft's people
get paid to do so, but, still, I'm talking about the right mind set.

Note that you have not stated why you think my reply #22 is wrong, and I'm
pretty sure that's because you can't. All my arguments are solidly backed up,
but you just looked at page 70, interpreted it incorrectly (because you didn't
realize that compilers like GCC are the ones responsible for that remark), and
didn't bother to see that I'm right about my arguments. You just say that I
can't do it, but I have shown why I should be able to do it. You just dismissed
it, I think is a loss for GCC, but whatever.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249