Re: Anyone remember what AC_PROG_GCC_TRADITIONAL was testing for?

[Zack Weinberg]

On Sun, Apr 2, 2023, at 5:17 PM, Paul Eggert wrote:
> That macro dates back to /usr/include header files that would play 
> tricks like this
>
>   #define _IO(n, x) (('n'<<8)+x) 
>
>   #define TIOCFOO _IO(T, 1) 

Yeah, I thought it had to be something like that...

> AC_PROG_GCC_TRADITIONAL has not been needed for thirty years, and was 
> declared obsolescent in Autoconf 2.60 (2006-06-05). Also, the Autoconf 
> manual (as of the next version) states Autoconf assumes C89 or later. So 
> if there's any issue with AC_PROG_GCC_TRADITIONAL at all, I suggest 
> replacing its definition with:
>
>AU_DEFUN([AC_PROG_GCC_TRADITIONAL])

Done (more or less) in the patchset I just posted.

zw

Re: Anyone remember what AC_PROG_GCC_TRADITIONAL was testing for?

[Paul Eggert]

That macro dates back to /usr/include header files that would play 
tricks like this


 #define _IO(n, x) (('n'<<8)+x) 

 #define TIOCFOO _IO(T, 1) 



and would expect TIOCFOO to be equivalent to (('T'<<8)+1). This sort of 
trick worked with K C compilers but does not work with C89+. To work 
around the problem back in the day, you needed to use 'gcc -traditional'.


Using -traditional had obvious problems, though, so GCC soon changed its 
installation procedure "fixincludes" to make fixed copies of these 
K headers during installation, and to compile by including 
the fixed copies. This was around 1990. I was involved with some of that 
header-munging effort but have blessedly forgotten most of the details. 
A descendant of the fixincludes work is still in GCC's source code 
(which is where I got the above example).


AC_PROG_GCC_TRADITIONAL has not been needed for thirty years, and was 
declared obsolescent in Autoconf 2.60 (2006-06-05). Also, the Autoconf 
manual (as of the next version) states Autoconf assumes C89 or later. So 
if there's any issue with AC_PROG_GCC_TRADITIONAL at all, I suggest 
replacing its definition with:


  AU_DEFUN([AC_PROG_GCC_TRADITIONAL])

and updating documentation and tests and etc. accordingly.

Re: Anyone remember what AC_PROG_GCC_TRADITIONAL was testing for?

[Alexandre Oliva]

Hello, Zack,

I don't know the answer, but I have a hunch that may hopefully ring a
bell for someone who went through those pains: the included headers
relied heavily on ioctl macros, that, on early Unices, often abused
pre-std preprocessor macro quirks about quoting, in ways that would only
have the intended effect with -traditional preprocessing.  We have
(had?) fixinclude code for such pre-std ioctls in GCC.

I hope this helps,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Anyone remember what AC_PROG_GCC_TRADITIONAL was testing for?

[Zack Weinberg]

After the AC_TYPE_GETGROUPS patch I just sent and one more
I have stacked up locally, the very last use of AC_EGREP_CPP
and/or AC_EGREP_HEADER in a stock Autoconf macro will be in
AC_PROG_GCC_TRADITIONAL, which does this:

AC_DEFUN([AC_PROG_GCC_TRADITIONAL],
[AC_REQUIRE([AC_PROG_CC])dnl
if test $ac_cv_c_compiler_gnu = yes; then
AC_CACHE_CHECK(whether $CC needs -traditional,
  ac_cv_prog_gcc_traditional,
[  ac_pattern="Autoconf.*'x'"
  AC_EGREP_CPP($ac_pattern, [#include 
Autoconf TIOCGETP],
  ac_cv_prog_gcc_traditional=yes, ac_cv_prog_gcc_traditional=no)

  if test $ac_cv_prog_gcc_traditional = no; then
AC_EGREP_CPP($ac_pattern, [#include 
Autoconf TCGETA],
ac_cv_prog_gcc_traditional=yes)
  fi])
  if test $ac_cv_prog_gcc_traditional = yes; then
CC="$CC -traditional"
  fi
fi
])# AC_PROG_GCC_TRADITIONAL


This is logic from solidly before my time -- I only have personal
experience with the generation of Unixes including SunOS 4.1 and later.
However, it looks to me as though this is testing for a problem with
very old  and/or , which wouldn't define some of the
macros they were supposed to define if preprocessed by an ISO C -
compliant compiler.

Does anyone remember enough to know if that guess is accurate?  Do you
remember which systems were affected?  I presume they would've had
their own C compiler and this was in aid of using GCC as a third-
party compiler.

Given that we are officially dropping support for "traditional" C
compilers as of the planned 2.73, and also given that GCC hasn't
supported compilation in -traditional mode since, um, 2001 give
or take a year, IIRC... Should we just delete this entire thing,
or does it still serve a purpose somehow?

zw