I'm having a hard time with various __attribute__s which cause very
unpredictable behavior, namely with pure, warn_unused_result, and nonnull.
The only one I've gotten to work consistently is fastcall. The problem might
be related to the fact that I'm writing in C++, and much of the
documentation around __attribute__ doesn't appear to acknowledge that
language.
I've created a string class that tries to mimic STL's string, but has
some modification to suit my own purposes.
One good place to start, I guess, is with the non-member concatenation
operator:
astring operator+(const std::string &s, const astring &str) throw()
__attribute__((warn_unused_result,pure))
When I tried building the following code using -O0, the operator was skipped
over:
string s0 = "some stuff";
astring s1 = " summore stuff";
astring s = s0 + s1;
That last line was skipped over completely, and the program then seg faulted
when it tired to destroy s, which was never constructed.
>From what I've read about the pure attribute, this should not have happened.
Pure applies to functions who's only effect is based on the parameters, and
global memory (which, I assume, includes static member variables). In fact,
I would have put __attribute__((const)), but the docs say that you shouldn't
used const if one of the parameters is a pointer to memory. I assume that a
reference to a class is just as bad.
Is it different for operators? Never before are s0 and s1 sent to that
operator, so that operator call should not have been skipped. What's even
stranger is that I only had this problem when running in an X86_32
environment. When I built a 64-bit version for the AMD64, it ran quite
smoothly.
So I removed the pure attribute from the non-member operators, but then I
got all kinds of warnings about unused return values, which I didn't get
before. One such warning was over the following code:
astring s;
...
s = '1' + s;
Obviously this would be in connection with:
astring operator+(char c, const astring &str) throw()
__attribute__((warn_unused_result))
Why "unused"? The result from the operator is being assigned to s! I suspect
the reason the problem didn't occur when I had the pure attribute there, is
that this operator call was being skipped in all those places where I was
now getting warnings.
Finally, the nonnull attribute didn't appear to have any problems when it
was used on all the non-ctor methods in astring that had a const char * for
a parameters, but when I used nonnull on a ctor, then I got all kinds of
errors about NULL pointers. One such occurrence was over this code:
astring foo() {
char c[21];
...
return c;
}
How can C be NULL? It's allocated on the stack right there!
--
View this message in context: http://www.nabble.com/Bizarre-behavior-with-various-__attribute__s-tp14423020p14423020.html
Sent from the gcc - Help mailing list archive at Nabble.com.
