#include <new.h> now causes a warning

#include <new.h> now causes a warning

[Craig Rodrigues]

Hi,

I am testing out recent gcc fix which solved
PR 3189.  I am using:

gcc version 3.1 20010808 (experimental)

The problem is solved, but elsewhere, I am getting
the following warning:


###########################################################################
g++ -W -Wall -Wpointer-arith -pipe -O3 -g -Wno-uninitialized -fno-implicit-templates   -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT -DACE_HAS_AIO_CALLS  -I/opt2/home/craigr/ACE_wrappers -DACE_HAS_RAPI -I/usr/include/rsvp -DACE_HAS_EXCEPTIONS  -c -fPIC -o .shobj/OS.o OS.cpp

In file included from /usr/local/include/g++-v3/backward/new.h:33,
                 from /opt2/home/craigr/ACE_wrappers/ace/OS.h:2950,
                 from OS.cpp:3:
/usr/local/include/g++-v3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please use the <X> header instead of <X.h> header for 'C++' includes and use the <cX> header instead of <X.h> header for 'C' includes. To disable this warning use -Wno-deprecated.

###########################################################################


This warning is caused because my code does:
#include <new.h>


Does this same warning occur on the 3.0.1 branch, or just the 3.1
branch?
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: #include <new.h> now causes a warning

[Joe Buck]

> gcc version 3.1 20010808 (experimental)
> 
> The problem is solved, but elsewhere, I am getting
> the following warning:

> ###########################################################################
> g++ -W -Wall -Wpointer-arith -pipe -O3 -g -Wno-uninitialized -fno-implicit-templates   -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT -DACE_HAS_AIO_CALLS  -I/opt2/home/craigr/ACE_wrappers -DACE_HAS_RAPI -I/usr/include/rsvp -DACE_HAS_EXCEPTIONS  -c -fPIC -o .shobj/OS.o OS.cpp
> 
> In file included from /usr/local/include/g++-v3/backward/new.h:33,
>                  from /opt2/home/craigr/ACE_wrappers/ace/OS.h:2950,
>                  from OS.cpp:3:
> /usr/local/include/g++-v3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please use the <X> header instead of <X.h> header for 'C++' includes and use the <cX> header instead of <X.h> header for 'C' includes. To disable this warning use -Wno-deprecated.
> 
> ###########################################################################

I think that -Wdeprecated should not be implied by -Wall, but should be
asked for explicitly.  Otherwise there is way too much perfectly valid,
standards-conformant code out there that will now issue a sea of warnings,
and since compilers that don't include all of the new headers are still
common, what this warning does is ask people to write less portable code
(that is, code that won't compile with compilers such as gcc-2.95.x, as
well as many proprietary compilers, that are still in wide use).

For example, it will tell people to turn <math.h> into <cmath>, resulting
in a program that won't compile with the current default compiler on any
GNU/Linux platform.

It will be safe to put -Wdeprecated into -Wall only when gcc 3.x has
almost completely displaced 2.95.x and egcs.

> This warning is caused because my code does:
> #include <new.h>
> 
> 
> Does this same warning occur on the 3.0.1 branch, or just the 3.1
> branch?

It's not in the 3.0.1 branch or in the released 3.0.

Re: #include <new.h> now causes a warning

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.COM> writes:

| > gcc version 3.1 20010808 (experimental)
| > 
| > The problem is solved, but elsewhere, I am getting
| > the following warning:
| 
| > ###########################################################################
| > g++ -W -Wall -Wpointer-arith -pipe -O3 -g -Wno-uninitialized -fno-implicit-templates   -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT -DACE_HAS_AIO_CALLS  -I/opt2/home/craigr/ACE_wrappers -DACE_HAS_RAPI -I/usr/include/rsvp -DACE_HAS_EXCEPTIONS  -c -fPIC -o .shobj/OS.o OS.cpp
| > 
| > In file included from /usr/local/include/g++-v3/backward/new.h:33,
| >                  from /opt2/home/craigr/ACE_wrappers/ace/OS.h:2950,
| >                  from OS.cpp:3:
| > /usr/local/include/g++-v3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please use the <X> header instead of <X.h> header for 'C++' includes and use the <cX> header instead of <X.h> header for 'C' includes. To disable this warning use -Wno-deprecated.
| > 
| > ###########################################################################
| 
| I think that -Wdeprecated should not be implied by -Wall, but should be
| asked for explicitly.

Joe,

  I have no opinion on that.  However, there ought to be a way to
educate users to move to standard headers as soon as possible.

|  Otherwise there is way too much perfectly valid,
| standards-conformant code out there that will now issue a sea of warnings,

There can't be any standard-conformant way to trigger those warnings.

[...]

| For example, it will tell people to turn <math.h> into <cmath>, resulting
| in a program that won't compile with the current default compiler on any
| GNU/Linux platform.

Is that *really* the case? 

C-headers are not backward headers and I don't see how they can
trigger that warning.

-- Gaby

Re: #include <new.h> now causes a warning

[Joe Buck]

I wrote:
> | I think that -Wdeprecated should not be implied by -Wall, but should be
> | asked for explicitly.

Gabrial Dos Reis writes:
>   I have no opinion on that.  However, there ought to be a way to
> educate users to move to standard headers as soon as possible.

> | For example, it will tell people to turn <math.h> into <cmath>, resulting
> | in a program that won't compile with the current default compiler on any
> | GNU/Linux platform.
> 
> Is that *really* the case? 
> 
> C-headers are not backward headers and I don't see how they can
> trigger that warning.

The original report claimed that this was so (that math.h would get a
warning), and I did not verify it myself as I've been testing the 3.0
branch, not the trunk.

So: Which headers issue the warning?

Are there any cases where the user is directed to use a header that
is not present in gcc 2.95.x?  

Re: #include <new.h> now causes a warning

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| I wrote:
| > | I think that -Wdeprecated should not be implied by -Wall, but should be
| > | asked for explicitly.
| 
| Gabrial Dos Reis writes:
| >   I have no opinion on that.  However, there ought to be a way to
| > educate users to move to standard headers as soon as possible.
| 
| > | For example, it will tell people to turn <math.h> into <cmath>, resulting
| > | in a program that won't compile with the current default compiler on any
| > | GNU/Linux platform.
| > 
| > Is that *really* the case? 
| > 
| > C-headers are not backward headers and I don't see how they can
| > trigger that warning.
| 
| The original report claimed that this was so (that math.h would get a
| warning), and I did not verify it myself as I've been testing the 3.0
| branch, not the trunk.

I think the orginal report was speaking of <new.h>:

   > 
   > In file included from /usr/local/include/g++-v3/backward/new.h:33,
   >                  from /opt2/home/craigr/ACE_wrappers/ace/OS.h:2950,
   >                  from OS.cpp:3:


| So: Which headers issue the warning?

The headers located in backward/ directory -- old form of classic
IOStreams and old HP/SGI-STL style headers.

| Are there any cases where the user is directed to use a header that
| is not present in gcc 2.95.x?  

Not that I'm aware of.  <sstream> was back-ported in 2.95.2 or 2.95.3.

But it depends on what you mean by "header": Is it just the spelling
or does the containt matter?

-- Gaby

Re: #include <new.h> now causes a warning

[Magnus Fromreide]

On 10 Aug 2001, Gabriel Dos Reis wrote:

> Not that I'm aware of.  <sstream> was back-ported in 2.95.2 or 2.95.3.

<sstream> was never accepted into the 2.95.3 branch, right now it is in
the repository on some kind of 2.95 mainline but not actual for inclusion
in any branch.

Re: #include <new.h> now causes a warning

[Gabriel Dos Reis]

Magnus Fromreide <magfr@lysator.liu.se> writes:

| On 10 Aug 2001, Gabriel Dos Reis wrote:
| 
| > Not that I'm aware of.  <sstream> was back-ported in 2.95.2 or 2.95.3.
| 
| <sstream> was never accepted into the 2.95.3 branch, right now it is in
| the repository on some kind of 2.95 mainline but not actual for inclusion
| in any branch.

Okey.

Any patch for inclusion in an eventual 2.95.x release is pre-approved.

-- Gaby

Re: #include <new.h> now causes a warning

[Craig Rodrigues]

On Fri, Aug 10, 2001 at 01:03:46PM -0700, Joe Buck wrote:
> The original report claimed that this was so (that math.h would get a
> warning), and I did not verify it myself as I've been testing the 3.0
> branch, not the trunk.

I never said that including math.h would trigger this warning.
Please re-read:
http://gcc.gnu.org/ml/gcc/2001-08/msg00588.html

> 
> So: Which headers issue the warning?

I saw this problem by including new.h.
Under gcc 3.1, I also see this warning triggered by
including iostream.h.  Basically, any header file 
in the "backward" directory will trigger this warning:
algo.h, fstream.h, iomanip.h, iostream.h, etc., etc.

For example, in gcc 3.1, new.h consists of the following:

#ifndef _CPP_BACKWARD_NEW_H
#define _CPP_BACKWARD_NEW_H 1
 
#include "backward_warning.h"
#include <new>
 
using std::bad_alloc;
using std::nothrow_t;
using std::nothrow;
using std::new_handler;
using std::set_new_handler;
 
#endif


Is this #include "backward_warning.h" present in the
header files in the 3.0.1 branch, or is only in the 3.1 branch?

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: #include <new.h> now causes a warning

[Gabriel Dos Reis]

Craig Rodrigues <rodrigc@mediaone.net> writes:

| Is this #include "backward_warning.h" present in the
| header files in the 3.0.1 branch, or is only in the 3.1 branch?

It is present in both 3.0.x and 3.x.  You can browse the sources.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com