[cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers

[Hal Finkel via cfe-dev]

----- Original Message -----

> From: "Martin J. O'Riordan" <martin.oriordan at movidius.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> 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>
> Sent: Saturday, January 23, 2016 4:23:21 PM
> Subject: RE: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper
> headers

> 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.
I'd have a difficult time calling such an author an expert C++ programmer, as such a person would clearly understand how easy it would be for some future maintainer to break their code by a seemingly-innocuous improvement in which headers are included, or by placing the code in a different environment (e.g. by someone copying-and-pasting the code into some other file). 

> The very fact that they chose the C header
But it is often not the choice of the original author, at least not intentionally. 

> 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.
I think your position is completely reasonable, but there happen to be strong practical advantages to the wording as-stated that are definitely worth considering (regardless of how we got here). 

-Hal 

> MartinO

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160123/f5f3aa12/attachment.html>