libc++ does not throw an exception where libstdc++ does

Clang Frontend
1

Hello. I'm using Kubuntu Raring 64 bit with libstdc++ 4.8.1 (from the
ubuntu-toolchain-r PPA) and Clang 3.2 (default Raring package). I have
now built and installed libc++ from latest SVN revision 185264 against
libsupc++ as per the instructions at libcxx.llvm.org.

I find that the attached simple code prints the "out_of_range was
thrown" message from within the catch block when compiled with
libstdc++ but when compiled with libc++ it is not printed. Curiously,
if the cout<< line (which I have commented out) in the try block is
executed, then the exception is thrown and the message printed.
Commenting out the cout<< line again makes the exception go away.

I encountered this problem yesterday with some other code in my
project but I wasn't able to provide a minimal example but this code
is pretty minimal so I hope the problem can be identified easily and
fixed.

Thank you for Clang and libc++ -- it has already caught two instances
of non-standards-compliance in my code which libstdc++ didn't.

cvector.cpp (1.91 KB)

2

Your cyclic flag is uninitialized.

3

Thanks for your reply -- so I guess if it doesn't get implicitly
defaulted to false, then the exception may not be thrown, but this
does not explain why the cout<< behaviour I outline above happens.

I agree however that if I initialize the cyclic flag to false, the
exception is always thrown.

4

... and I thought whether such scalar values are given some default
values are not will be decided by the compiler implementation and not
by the standard library that is being used. What if I did not use the
standard library at all? Wouldn't the default init behaviour be same
since I'm using the same compiler?

5

Thanks for your reply -- so I guess if it doesn't get implicitly
defaulted to false, then the exception may not be thrown, but this
does not explain why the cout<< behaviour I outline above happens.

That's just luck of the draw. The compiler is supposed to make sure
well-defined programs behave as they should but is free to do whatever
it wants to ones with undefined behaviour.

My very vague guess is that the extra cout calls sit in between the
uninitialised variable and its use, making the optimiser think that
something may be setting it properly in there. Without those calls it
could be aggressively pruning code based on, well, anything really.
Some test that makes sense on a well-defined value but not an
uninitialised one, probably -- but it could be doing it merely for the
shits and giggles.

... and I thought whether such scalar values are given some default
values are not will be decided by the compiler implementation and not
by the standard library that is being used. What if I did not use the
standard library at all?

It's uninitialised in all cases, but what effect that has can hinge on
tiny changes to the code pulled in by the library. Perhaps one version
writes "if (cond)" and the other writes "if (!cond)" and LLVM treats
them differently.

Actually, in my experience bools are even more prone to this than
other types. At least an unitinitialised area of memory pointing at an
int has *some* value. Bool memory can be in a state that really means
nothing since they take up 8 bits (usually) and only values 0 and 1
are used (usually). Of course, that may not be what's happening here
and things will go wrong with uninitialised values of other types as
well, it's just one more type of error for bools.

Tim.