155852 - gcc 3.1 compile warnings from #including new.h

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Brian Ryner (not reading)]

gcc 3.1 gives several of these types of warnings when building Mozilla:

In file included from /usr/include/g++-v3/backward/new.h:33,
                 from ../../../../dist/include/string/nsBufferHandleUtils.h:36,
                from ../../../../dist/include/string/nsSharableString.h:35,
                 from ../../../../dist/include/string/nsPromiseFlatString.h:28,
                from ../../../../dist/include/string/nsString2.h:70,
                 from ../../../../dist/include/string/nsString.h:54,
                 from ../../../../../js/src/xpconnect/src/xpcprivate.h:84,
                 from
../../../../../js/src/xpconnect/src/xpccallcontext.cpp:38:/usr/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.


So, we need to change <new.h> to <new> to get rid of this.  There are 17 places
in the codebase where we #include <new.h>.  My primary concern about just
changing it is, of course, that platforms will break.  Are there any compilers
that we support which don't support #include <new>?

Comment 1

[Brian Ryner (not reading)]

Attachment: change all occurrences of <new.h> to <new>

Only tested on gcc 3.1 on Linux so far.

Comment 2

[Brian Ryner (not reading)]

This also builds fine on Mac CFM, Mac Mach-O, and RedHat 6.2 (egcs 1.1.2).

Comment 3

[Brian Ryner (not reading)]

It also builds on Windows (MSVC 6.0) and Solaris (Sun Workshop 6).

Comment 4

[Brian Ryner (not reading)]

Basically, every platform except IRIX seems to support this (I just tested HP-UX
and True64 as well).

So, we could:

1. drop IRIX support
2. require IRIX users to install some supplemental package that provides these
headers (or even a script to generate them)
3. autoconf the <new> test, perhaps providing a macro so that you can do
#include <NEW_H>

Comment 5

[Brian Ryner (not reading)]

Chris, any thoughts on this?

Comment 6

[hacker formerly known as [e-mail]]

Antitux, can you check with your SGI contacts and see if we can get any compiler
upgrades which would address this problem?

Bryner, did you check AIX as well?  The macro seems like the lesser of the evila
so I guess we should go with that and wait for non-standard compilers to fade away.

Comment 7

[Brian Ryner (not reading)]

I didn't check AIX because I didn't see it on either the main tbox page or the
ports page.

Comment 8

[hacker formerly known as [e-mail]]

Hrm, good point.  Pinging jdunn as I didn't think that we dropped AIX support.

Comment 9

[Jim Dunn]

We didn't drop AIX support, just don't have a tbox.  :-(
I am adding Phil since I don't have an AIX box handy to try this out on.
(I am assuming however that AIX/xlC is happy with "#include <new>"

Irix contact should/might be Richard Hess <[e-mail]>

Comment 10

[Brian Ryner (not reading)]

mkaply tells me that OS/2 VACPP also doesn't like <new>.

Comment 11

[Philip K. Warren]

AIX works fine with <new> instead of <new.h>.

We have a Tinderbox up and running within IBM for AIX, but currently it is on 
the MozillaTest tree. I hope to move it to SeamonkeyPorts sometime in the next 
couple of days.

Comment 12

[Brian Ryner (not reading)]

Ok, so what do we want to do here?  We apparently can't just make the
substitution because of IRIX and OS/2.  Should we do a configure test and macro?

Comment 13

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

bryner: that sounds to me like the most reasonable course of action.

Comment 14

[hacker formerly known as [e-mail]]

One question wrt implementation: Do we want to completely hide the details from
the developers and use -DNEW_H=new (and possibly -DSSTREAM_H=sstream) or do we
want to set some define (-DREQUIRES_DEPRECATED_CPP_HEADERS) and require the
developers to ifdef accordingly?

 

Comment 15

[Brian Ryner (not reading)]

Attachment: use a NEW_H macro defined by configure

Comment 16

[Brian Ryner (not reading)]

Attachment: patch #2

Fixed the Mac definition of NEW_H.

Comment 17

[Brian Ryner (not reading)]

Attachment: patch #3

Define NEW_H to <new> for Windows, where we skip the normal header checks.

Comment 18

[hacker formerly known as [e-mail]]

Comment on attachment 95815 [details] [diff] [review]
patch #3

r=cls

Comment 19

[Brian Ryner (not reading)]

Checked in.

Comment 20

[Uros Bizjak]

There are similar problems with #include <iostream.h>:
http://lxr.mozilla.org/seamonkey/search?string=iostream.h

Comment 21

[Boris Zbarsky [:bzbarsky]]

This caused bug 311923