[cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
Martin J. O'Riordan via cfe-dev
cfe-dev at lists.llvm.org
Sat Jan 23 14:23:21 PST 2016
From: Hal Finkel [mailto:hfinkel at anl.gov]
Sent: 23 January 2016 21:57
To: Martin ORiordan <Martin.ORiordan at Movidius.com>
Cc: Marshall Clow <mclow.lists at gmail.com>; Richard Smith <richard at metafoo.co.uk>; Clang Dev <cfe-dev at lists.llvm.org>; Eric Fiselier <eric at efcs.ca>
Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
The effective code subtly changes silently from:
int x = abs((int)aBar.operator double()); // choosing ‘int ::abs(int)’
to:
int x = (int)abs(aBar.operator double()); // choosing ‘double ::abs(double)’
Of all of your examples, this is the most important. The other changes result in a compilation failure, and are easy to fix. However, it is certainly my experience that, in almost all cases, the semantic change you highlight is actually a silent bug *fix*, as the author almost always intended the behavior we now have, not the behavior we provided previously. Obviously this will not be 100% true, but on balance, the change has seems positive. Either way, good compiler warnings are essential. As I recall, Clang does have a good warning for this.
-Hal
Hmm, yes and no. If they wanted different behaviour, they should have included ‘<cmath>’ and not ‘<math.h>’. It is not our place to assume to fix their possible intent. An expert C++ programmer might expect exactly the C behaviour. The very fact that they chose the C header and not the C++ prescribed equivalent makes it more evident to me that this is the realm of the static analyser’s diagnostics, and not the realm of the Standard library implementation to assume it knows what they might have meant.
MartinO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160123/e7e004e4/attachment.html>
More information about the cfe-dev
mailing list