Re: [lmi] xanadu/remove-ISOC99_SOURCE-def

[Greg Chicares]

On 5/22/22 22:20, Vadim Zeitlin wrote:
> On Sun, 22 May 2022 20:33:24 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> The expm1() and log1p work I've recently done elsewhere suggests
> GC> to me that if an msvcrt function is known to be defective (whether
> GC> in the latest version or in some previous version that could still
> GC> be circulating in the wild), and we have a replacement that
> GC> demonstrably lacks those known defects, then it's better to favor
> GC> the replacement, forever.
> 
>  This is a perfectly understandable point of view, but OTOH MSVC CRT has
> significantly changed during the switch to the "universal CRT" (ucrt) and
> is now much more compliant than before (at the price of not being
> compatible with the expectations of the code written in the nineties any
> longer). So I think relying on snrpintf() to work correctly in it should be
> a much safer bet than relying on all digits of expm1() to be exact.

I'm not sure which bet is safer. It's easy in principle to prove that
expm1(double) is correct for all possible arguments, because there are
no more than 2^64 of them. I don't immediately see a line of attack
for an snprintf() correctness proof.

Theoretical considerations aside, I'm reminded of a programming joke
from decades ago, in the form of a flowchart for dealing with a
defect report:

  Did it work before?
     NO --> Blame it on the original programmer.
     YES
      |   [that should be an arrow pointing downward]
  Did you change it?
     NO --> Blame it on an operating-system upgrade.
     YES --> You idiot!

That principle
  "...makes us rather bear those ills we have
  Than fly to others that we know not of"
and that's why I'm more comfortable not changing what works.

> GC> If there's some silly code we could add to defeat the "tidy"
> GC> check
[...]
>  I'll give an even better solution below, but, as I wrote in my original
> message about clang-tidy, the general solution is to add
> 
>       // NOLINTNEXTLINE(bugprone-reserved-identifier)
> 
> before _ISOC99_SOURCE definition.

Perfect.

> And I'd still like to know if you'd
> accept adding such comments because there are definitely going to be other
> places where they would be needed. For example, I'd like to add [...]

Perfect, too.

>  But in the case of _ISOC99_SOURCE I realized that I did, in fact, have a
> pretty simple workaround: it's enough to simply define it on clang-tidy
> command line, i.e. add -D_ISOC99_SOURCE to it.

I'd rather use the "NOLINT" thing everywhere:
 - one class of problems --> one technique to forestall them all
 - it's easy to forget to use a command-line parameter

I'd be glad to apply a patch that uses "NOLINT" wherever
it's needed, as long as it's needed only in a reasonable
number of cases, of course.