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

["rogerio at rilhas dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #38 from rogerio at rilhas dot com  2010-08-11 22:35 -------
(In reply to comment #34)
> (In reply to comment #25)
> > 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
> ISO/IEC 14882:2003(E) 8.5.3 [dcl.init.ref] paragraph 5

Thanks for this. I didn't know why GCC was unable to compile such code and now
I know: GCC is unable to convert a initialization passed as parameter to an
lvalue. Microsoft's compiler does know how to do that - there is no problem in
getting the address of such temporary variables, right? Oh, wrong, GCC can't,
that's just too hard on the poor thing.

... oh well, let's just not call that a portability issue created by GCC,
because no one explained to its developers how to get the address of a
temporary variable. Let's just not initialize temporary variables and stick to
the lowest common denominator, which is GCC.

Really?? Was that rally the explanation you wanted to provide??? I think its
just embarassing. Note that I didn't open a bug for this issue because I can,
in fact, reduce to the lowest common denominator. So, I can live without
(although not as confortably).

> > 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.
> ibid.
> > 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.
> What a charming idea, that a compiler could become perfect by doing "what I
> said it should"

You must have missed something in the discussion because you failed to see that
"what I say" is what "C99+cdecl" say. Please forgive me for cutting sentences
short, I didn't think anyone would start making comments without reading the
whole conversation, my bad.

... is it still a charming idea after you read all the backups to my claims?


> > 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.
> Oh, how delightfully quaint!


It is, isn't it? And it makes sense too, doesn't it? I bet that thinking that
GCC needs not improve on the stuff I commented here is a sure way to get you
there fast. I'm sorry I even tried!


-- 


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