[6/7] malloc/obstack.h: Remove long obsolete NeXT gcc conditional
diff mbox

Message ID 1395059004-20960-6-git-send-email-will.newton@linaro.org
State New
Headers show

Commit Message

Will Newton March 17, 2014, 12:23 p.m. UTC
This fixes a warning introduced with -Wundef, but in general there
is no point supporting this long obsolete configuration.

2014-03-17  Will Newton  <will.newton@linaro.org>

	* malloc/obstack.h: Remove conditional for supporting
	ancient NeXT gcc version.
---
 malloc/obstack.h | 7 -------
 1 file changed, 7 deletions(-)

Comments

Joseph Myers March 17, 2014, 12:32 p.m. UTC | #1
On Mon, 17 Mar 2014, Will Newton wrote:

> This fixes a warning introduced with -Wundef, but in general there
> is no point supporting this long obsolete configuration.

Have you confirmed that it's outside the scope of what gnulib tries to 
support (since this code is shared with gnulib - the only reason for glibc 
headers to support GCC versions before 2.7, as they didn't support any 
platforms now supported by glibc)?
Will Newton March 17, 2014, 12:55 p.m. UTC | #2
On 17 March 2014 12:32, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Mon, 17 Mar 2014, Will Newton wrote:
>
>> This fixes a warning introduced with -Wundef, but in general there
>> is no point supporting this long obsolete configuration.
>
> Have you confirmed that it's outside the scope of what gnulib tries to
> support (since this code is shared with gnulib - the only reason for glibc
> headers to support GCC versions before 2.7, as they didn't support any
> platforms now supported by glibc)?

It's not clear to me exactly which platforms gnulib supports but
NeXTStep is not in the list of target platforms in the gnulib docs.
How are changes to this code handled? It doesn't appear that there is
a regular sync of code in either direction.
Joseph Myers March 17, 2014, 2:36 p.m. UTC | #3
On Mon, 17 Mar 2014, Will Newton wrote:

> On 17 March 2014 12:32, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > On Mon, 17 Mar 2014, Will Newton wrote:
> >
> >> This fixes a warning introduced with -Wundef, but in general there
> >> is no point supporting this long obsolete configuration.
> >
> > Have you confirmed that it's outside the scope of what gnulib tries to
> > support (since this code is shared with gnulib - the only reason for glibc
> > headers to support GCC versions before 2.7, as they didn't support any
> > platforms now supported by glibc)?
> 
> It's not clear to me exactly which platforms gnulib supports but
> NeXTStep is not in the list of target platforms in the gnulib docs.
> How are changes to this code handled? It doesn't appear that there is
> a regular sync of code in either direction.

In principle, code from glibc should be updated in gnulib via 
srclist-update.  In practice, all the $LIBCSRC entries in srclist.txt are 
commented out at present - and there are many files in gnulib with 
comments stating "This file is part of the GNU C Library." (or similar, 
possibly with the phrase "GNU C Library" split over two lines - something 
to watch out for when identifying such files) and no mention in 
srclist.txt at all.  It would be a useful project to identify all gnulib 
files based on glibc and merge the individual logical changes to those 
files in gnulib back to glibc, so that the files can be fully in sync 
again.  Where the changes clearly do not affect builds as part of glibc, 
getting them into glibc shouldn't involve more than a routine coding style 
review.

Patch
diff mbox

diff --git a/malloc/obstack.h b/malloc/obstack.h
index 85472f9..0fd623e 100644
--- a/malloc/obstack.h
+++ b/malloc/obstack.h
@@ -249,13 +249,6 @@  extern int obstack_exit_failure;
 #define obstack_memory_used(h) _obstack_memory_used (h)
 
 #if defined __GNUC__
-/* NextStep 2.0 cc is really gcc 1.93 but it defines __GNUC__ = 2 and
-   does not implement __extension__.  But that compiler doesn't define
-   __GNUC_MINOR__.  */
-# if __GNUC__ < 2 || (__NeXT__ && !__GNUC_MINOR__)
-#  define __extension__
-# endif
-
 /* For GNU C, if not -traditional,
    we can define these macros to compute all args only once
    without using a global variable.