Use std:: on symbols declared in C++-style C headers.

Use std:: on symbols declared in C++-style C headers.

Some libraries (e.g. Dinkumware) perform strict checks on whether
the symbols defined in classic C library headers (e.g. <stdio.h>),
or in C++-style C library headers (e.g. <cmath>) are used correctly
(respectively, in the global namespace, or in namespace std).

BUG=
R=danno@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=18578

[c.truta, 2014-01-06 15:38:58]

Hello, and thank you very much for reviewing and landing the first
QNX-supporting patch for me.

I will submit a series of other patches. This one is a C++ compliance fix that
allows us to build V8 with the Dinkumware library.

I noticed there was a deliberate change from <math.h> to <cmath> a few months
ago, so I kept that. On the other headers, I haven't noticed any particular
pattern, so I ended up keeping <stdio.h> (not <cstdio) and fopen (not
std::fopen).

In case I've got any of these backwards, I will make the changes accordingly.

[Benedikt Meurer, 2014-01-07 08:20:27]

I'm fine with the change personally, but I'd like to hear other peoples opinion
on this.

However, I think we should go for C++-style <cXXX> includes instead of the
C-style <XXX.h> includes.

https://codereview.chromium.org/121303005/diff/30001/src/assembler.cc
File src/assembler.cc (right):

https://codereview.chromium.org/121303005/diff/30001/src/assembler.cc#newcode...
src/assembler.cc:1466: if (modf(y, &f) != 0.0) return ((x == 0.0) ^ (y > 0)) ?
V8_INFINITY : 0;
std::modf

https://codereview.chromium.org/121303005/diff/30001/src/assembler.cc#newcode...
src/assembler.cc:1471: if (y == y_int) return ldexp(1.0, y_int);
std::ldexp

https://codereview.chromium.org/121303005/diff/30001/src/cpu.cc
File src/cpu.cc (right):

https://codereview.chromium.org/121303005/diff/30001/src/cpu.cc#newcode41
src/cpu.cc:41: #include <limits.h>
Why can't we keep the C++ headers here?

https://codereview.chromium.org/121303005/diff/30001/src/d8-readline.cc
File src/d8-readline.cc (right):

https://codereview.chromium.org/121303005/diff/30001/src/d8-readline.cc#newco...
src/d8-readline.cc:28: #include <stdio.h>  // NOLINT
Why use stdio.h instead of cstdio?

[c.truta, 2014-01-07 08:59:33]

Thank you, Benedikt.

I missed std::modf and std::ldexp because they were #ifdef'ed inside MinGW64
code, so our compiler didn't complain.

I can move wholesale to the C++ headers instead. The patch will be bigger, as
there are many std:: missing in many places. That's why I had initially
considered that the C++ headers are not really that important in this project:
their purpose is to clean up the global namespace and put everything in std::
instead, yet the V8 code uses C library calls unqualified in the global
namespace anyway.

This is a matter of standard C++ library implementation. The C++98 standard
mandates that the global namespace be kept clean when including, say, <cstdio>,
and everything should be in namespace std only. To my knowledge, only Dinkumware
C++ and Watcom C++ library implemented it correctly. Most importantly, GNU
libstdc++ did not, because it's a pain. So they did the "normal" thing, i.e.
#include <stdio.h> from <cstdio>, then hoist everything in namespace std with
using directives. In GNU libstdc++, both fopen and std::fopen are available from
<cstdio>.

That original C++98 restriction was relaxed in C++11 because it was too painful
to obey, and now it's "implementation-defined" whether to put things in the
global namespace or not. That effectively validates the previously-noncompliant
implementations, including GNU libstdc++.

Back to this patch: I can understand if some people aren't comfortable with this
change, either to the C-style direction, or the C++-style direction. We can work
around it with a hack inside our own qnx-headers.h if you so prefer, and leave
the rest of the code alone. We already did something similar in qnx-math.h, with
std::lrint (that thing itself being a necessary workaround because std::lrint is
normally available from <cmath> in C++11 mode only).

[danno, 2014-01-13 10:05:28]

LGTM, I'm fine with this large-scale semi-mechanical change since it solves a
real, concrete problem.

[Benedikt Meurer, 2014-01-13 11:19:42]

Ok, I'll land it.

[Benedikt Meurer, 2014-01-13 11:20:20]

Can you rebase this on bleeding_edge?

[c.truta, 2014-01-13 13:52:15]

Done, including the missing bits.

[c.truta, 2014-01-13 14:06:47]

Here's a thought: would it be too much (e.g. potential overall cpplint'ing
slowdown) if presubmit.py or cpplint could check the correct use of std:: on the
well-known standard C library symbols? I might try implementing that if I happen
to find some spare cycles, but I wanted to ask first, to be sure it's not a 100%
dumb idea.

[Sven Panne, 2014-01-13 14:35:06]

On 2014/01/13 14:06:47, cosmin.truta wrote:
> Here's a thought: would it be too much (e.g. potential overall cpplint'ing
> slowdown) if presubmit.py or cpplint could check the correct use of std:: on
the
> well-known standard C library symbols? I might try implementing that if I
happen
> to find some spare cycles, but I wanted to ask first, to be sure it's not a
100%
> dumb idea.

Doing that would require running a C++ compiler over all our source code,
because otherwise you can't resolve namespaces in any meaningful way. I don't
think we want that. Doing some regexp approximation will probably only be too
noisy.

The right way to approach this would be some QNX builder on the waterfall if
somebody thinks this is necessary.

[c.truta, 2014-01-13 17:23:03]

On 2014/01/13 14:35:06, Sven Panne wrote:
> Doing that would require running a C++ compiler over all our source code,
> [...]

Got it. Good to know.

> The right way to approach this would be some QNX builder on the waterfall if
> somebody thinks this is necessary.

If you wish to host the QNX build, that would be great! All that's needed from
our part is the publicly-downloadable QNX SDK, and a porting patch to ICU which
we haven't submitted yet (but we will).

Or, if you want us to run the buildbot and submit the results to you, we can do
that also. We can assign a build machine, with a fixed IP, accessible from any
outside server that we can whitelist.

BTW, I made one more CL upload, with a change to cctest/test-log.cc. (That
doesn't affect us, but I just discovered it and put it in, for the sake of
correctness.)

[Benedikt Meurer, 2014-01-14 09:57:31]

Committed patchset #4 manually as r18578 (presubmit successful).