Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Jan 27, 2023, at 4:53 AM, Denis Ovsienko wrote: > On Fri, 27 Jan 2023 01:40:48 -0800 > Guy Harris wrote: > >> *don't* support C99 inline? If not, we could just remove the call >> from configure.ac and the definition from aclocal.m4. > > In 2002 in commit b1263c6 you wrote it was some HP C compiler that > Autoconf 2.13 could not drive. I have never seen HP-UX in the wild, but > assuming the amount of improvement made in Autoconf during the > subsequent 10 years (Autoconf 2.69 is from 2012) and the amount of > improvement made in HP-UX (which had the most recent release in 2022), > to me it would make the most sense to say the problem AC_LBL_C_INLINE > solved (HP C specifics) no longer exists unless proven otherwise, and > AC_LBL_C_INLINE should be removed with a good change log entry. That commit was commit b1263c69c58e58e326997ec8b2db81d6e3666bc6 Author: Guy Harris Date: Fri Jun 28 10:45:40 2002 + Some versions of the HP C compiler can handle inlines, but not if they return a structure pointer. Check whether the C compiler can handle inline functions that return a structure pointer, not whether they can handle inline functions that return an int, as at least some versions of autoconf's AC_C_INLINE do. I presume that, given the increased use of, and thus demand for, inline as a keyword in C, HP eventually fixed the problem (I *think* the problem was that the compiler rejected code that inlined structure-pointer-returning functions, rather than generating bad code for it). (If not, maybe the autoconf developers added a check for that.) If anybody still has such a problem, they have my sympathy, just as people stuck with, say, compilers that don't support function prototypes do, but I'm not sure they should have support for building tcpdump (or libpcap or tcpslice) on their machine with their current compiler. As far as I'm concerned, replacing it with AC_C_INLINE, as you did, is the right thing to do, at least for now. We could consider removing it in the future, given that we require C99 and C99 has inline as a keyword.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Fri, 27 Jan 2023 12:53:28 + Denis Ovsienko via tcpdump-workers wrote: [...] > I do not understand yet if AC_LBL_C_INLINE could just disappear safely > altogether instead of being replaced with AC_C_INLINE. In order to play safe, it has been replaced with an AC_C_INLINE in both tcpdump and libpcap. And the last copy of AC_LBL_CHECK_LIB has been removed from tcpdump. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Fri, 27 Jan 2023 01:40:48 -0800 Guy Harris wrote: > On Jan 22, 2023, at 9:59 AM, Denis Ovsienko via tcpdump-workers > wrote: > > > I have also removed AC_LBL_C_INLINE and a conditional substitute for > > Tru64 pfopen() from tcpslice. Interestingly, tcpslice and tcpdump, > > which don't call pfopen(), used to have this substitute, and > > libpcap, which does call pfopen(), does not have it. > > That dates back to tcpdump 3.4. I don't know why they decided to > compile pfopen() into tcpdump and tcpdslice if it's not in a system > library, rather than compiling it into libpcap if it's not in a > system library. Perhaps they wanted to be able to build versions of > libpcap that would work both on Tru64 UNIX versions in which pfopen() > is in a system library and versions in which it's not and all you > have is pfopen.c source code under /usr/examples. > > I don't know what older versions those might be, and I suspect we > have little if any reason to continue to make it possible to build > tcpdump or tcpslice on those older versions - it looks as if Tru64 > UNIX 4.x and 5.x have pfopen() in system libraries; according to > > https://en.wikipedia.org/wiki/Tru64_UNIX > > 4.0A through 4.0F all date back to the previous millennium. Thank you for confirming. > > In tcpdump it is a bit more entrenched, so I did not touch it yet. > > It looks as if you removed the pfopen() stuff from tcpdump's > configure script in 43670fb635503e69cdbf8055134a0befb94d2e15. Yes, the Autoconf problem/solution space has been getting smaller. On one hand, there is build logic that has been obsolete for a while, and on the other there is logic that is very much in the loop, but has not been converted to the 2.69 dialect yet. Quite a few more rounds of improvements remain to be done in both departments. Specifically, losing Ultrix props should be among the safest things to do. > The AC_LBL_C_INLINE stuff is still there, but doesn't look *that* > entrenched; are there any compilers that we need to support and that > *don't* support C99 inline? If not, we could just remove the call > from configure.ac and the definition from aclocal.m4. In 2002 in commit b1263c6 you wrote it was some HP C compiler that Autoconf 2.13 could not drive. I have never seen HP-UX in the wild, but assuming the amount of improvement made in Autoconf during the subsequent 10 years (Autoconf 2.69 is from 2012) and the amount of improvement made in HP-UX (which had the most recent release in 2022), to me it would make the most sense to say the problem AC_LBL_C_INLINE solved (HP C specifics) no longer exists unless proven otherwise, and AC_LBL_C_INLINE should be removed with a good change log entry. I do not understand yet if AC_LBL_C_INLINE could just disappear safely altogether instead of being replaced with AC_C_INLINE. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Jan 22, 2023, at 9:59 AM, Denis Ovsienko via tcpdump-workers wrote: > I have also removed AC_LBL_C_INLINE and a conditional substitute for > Tru64 pfopen() from tcpslice. Interestingly, tcpslice and tcpdump, > which don't call pfopen(), used to have this substitute, and libpcap, > which does call pfopen(), does not have it. That dates back to tcpdump 3.4. I don't know why they decided to compile pfopen() into tcpdump and tcpdslice if it's not in a system library, rather than compiling it into libpcap if it's not in a system library. Perhaps they wanted to be able to build versions of libpcap that would work both on Tru64 UNIX versions in which pfopen() is in a system library and versions in which it's not and all you have is pfopen.c source code under /usr/examples. I don't know what older versions those might be, and I suspect we have little if any reason to continue to make it possible to build tcpdump or tcpslice on those older versions - it looks as if Tru64 UNIX 4.x and 5.x have pfopen() in system libraries; according to https://en.wikipedia.org/wiki/Tru64_UNIX 4.0A through 4.0F all date back to the previous millennium. > In tcpdump it is a bit more entrenched, so I did not touch it yet. It looks as if you removed the pfopen() stuff from tcpdump's configure script in 43670fb635503e69cdbf8055134a0befb94d2e15. The AC_LBL_C_INLINE stuff is still there, but doesn't look *that* entrenched; are there any compilers that we need to support and that *don't* support C99 inline? If not, we could just remove the call from configure.ac and the definition from aclocal.m4.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- Hello all. I have removed some unused Autoconf macros here and there, including AC_LBL_CHECK_LIB in tcpslice and libpcap. This macro still remains in tcpdump, where it was a part of the initial git commit in 1999, and where it became unused in 2001 (commit d57c77a), with the current comment saying: dnl We keep it around for reference purposes in case it's ever dnl useful in the future. If it still a good reference? -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Thu, 19 Jan 2023 15:57:30 -0800 Guy Harris wrote: > On Jan 19, 2023, at 3:20 PM, Denis Ovsienko > wrote: > > > * AC_LBL_SSLEAY -- is there anything useful to take from here? > > No, it's been replaced by the "Check for OpenSSL/libressl libcrypto" > code in configure.ac. Thank you, removed. I have also removed AC_LBL_C_INLINE and a conditional substitute for Tru64 pfopen() from tcpslice. Interestingly, tcpslice and tcpdump, which don't call pfopen(), used to have this substitute, and libpcap, which does call pfopen(), does not have it. In tcpdump it is a bit more entrenched, so I did not touch it yet. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Jan 19, 2023, at 3:20 PM, Denis Ovsienko wrote: > * AC_LBL_SSLEAY -- is there anything useful to take from here? No, it's been replaced by the "Check for OpenSSL/libressl libcrypto" code in configure.ac.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Wed, 18 Jan 2023 15:53:21 -0800 Guy Harris wrote: > On Jan 18, 2023, at 3:32 PM, Denis Ovsienko via tcpdump-workers > wrote: > > > As it turns out, there is another unused macro > > (AC_LBL_HAVE_RUN_PATH), tcpslice became the first to lose this > > luggage. > > Unused in libpcap back to 0.4 and tcpdump back to 3.4, so it may be > another one used in some LBL projects but not libpcap or tcpdump. So, libpcap and tcpdump have lost a few unused macros as well. I did NOT touch the following unused AC_DEFUNs in tcpdump aclocal.m4: * AC_LBL_CHECK_64BIT_FORMAT -- this used to define the PRI[doux]64 conversion specifiers before C99 became required/presumed. I wonder if this presumption is subject to the same problem as the sizeof length modifier: the compiler might be C99, but the libc may be not. If trying to compensate for this [again] would be a waste of effort and the best move would be to delete the macro, at least the build system could verify that all the required printf() features are in place -- in fact, a single piece of C code could exercise as many printf() features as required in one go and fail if at least one of those failed. Or would it be over-engineering? * AC_LBL_SSLEAY -- is there anything useful to take from here? -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Jan 18, 2023, at 3:32 PM, Denis Ovsienko via tcpdump-workers wrote: > As it turns out, there is another unused macro (AC_LBL_HAVE_RUN_PATH), > tcpslice became the first to lose this luggage. Unused in libpcap back to 0.4 and tcpdump back to 3.4, so it may be another one used in some LBL projects but not libpcap or tcpdump.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Wed, 18 Jan 2023 09:22:28 -0500 Michael Richardson wrote: > I haven't heard a clear argument as to what autoconf/configure gets > us today over cmake, and maintaining both seems a huge waste of > energy. There's a comment buried in one of the build files: a release tarball with a configure script in it does not require Autoconf to build the source, whereas the same tarball with CMake files in it does require CMake to build the source. As it turns out, there is another unused macro (AC_LBL_HAVE_RUN_PATH), tcpslice became the first to lose this luggage. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Jan 18, 2023, at 1:07 AM, Denis Ovsienko wrote: > Thank you for explaining the context Guy, it is very educational. A significant part of what's in autoconf, and a significant part of what's in at least some configure scripts, dates back to old UN*Xes. ISO C and POSIX have, over time, rendered a lot of old-time tests unnecessary except for hobbyists and ancient "if it ain't broke don't fix it" systems: https://www.theregister.com/2001/04/12/missing_novell_server_discovered_after/ (although that one was Netware rather than UN*X, there may be old UN*X versions running on old hardware still out there). > Is AC_LBL_UNION_WAIT of a similar origin? Probably. > Neither tcpdump nor libpcap use it. I think BSD's "union wait" has been supplanted by various POSIX-specified macros to pull apart an exit status stored in an int, and, in the 3.4/0.4 timeframe, I don't think tcpdump or libpcap had any code to wait for a child process, and thus didn't need AC_LBL_UNION_WAIT.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message --- On Tue, 17 Jan 2023 18:35:58 -0800 Guy Harris wrote: > If you're curious what AC_LBL_FIXINCLUDES is for, and why most > platforms don't need it, continue reading. Thank you for explaining the context Guy, it is very educational. Is AC_LBL_UNION_WAIT of a similar origin? Neither tcpdump nor libpcap use it. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] AC_LBL_FIXINCLUDES does not make it into configure
--- Begin Message ---
On Jan 17, 2023, at 3:13 PM, Denis Ovsienko via tcpdump-workers
wrote:
> In tcpdump commit cee234c there are three messages changed in
> aclocal.m4, but only two messages changed in the resulting configure
> script. After a brief look it is clear that it is the third message
> (the one in AC_LBL_FIXINCLUDES) that does not make it to the script,
> but I don't understand whether this means a bug or just some dead code.
AC_LBL_FIXINCLUDES is defined in aclocal.m4 for tcpdump, but isn't used in
configure.ac for tcpdump.
This appears to date back to tcpdump 3.4 (the last LBL release).
So that code is, for tcpdump, not only merely dead, it's really most sincerely
dead.
I think aclocal.m4 may have started out as a library of LBL autoconf macros;
they may have copied them to both the tcpdump and libpcap releases, bringing
along macros not used by both packages (maybe some not used by either package).
They were identical in libpcap 0.4 and tcpdump 3.4.
They've since moved apart; given that it has not been used by tcpdump at least
since 3.4, we can probably just remove it from tcpdump's aclocal.m4.
And perhaps we could remove it, and the call to it, from libpcap's configure
script as well, as it may only be needed if you're configuring libpcap to build
on and for SunOS 3 and SunOS 4. If you're curious what AC_LBL_FIXINCLUDES is
for, and why most platforms don't need it, continue reading.
What AC_LBL_FIXINCLUDES does is "if using gcc, make sure we have ANSI ioctl
definitions".
Back when ANSI C compilers were rare, system header files back in the
mid-to-late 1980's had to work with pre-C89 compilers.
In V7 UNIX, ioctl codes were of the form (('c' << 8) | code), where 'c' was an
octet value, normally a printable character, indicating the type of object
(typically, a device) for which the ioctl was intended, and code was a
numerical value specifying a particular code. It was up to the individual
ioctl call in the kernel to move the argument from or to userland. V7 was
originally on a PDP-11, where an int is 16 bits, and an ioctl code was an int,
so that ate up all 16 bits.
4.2BSD, which ran on VAXes where an int is 32 bits, expanded the ioctl codes to
include an indication of whether the argument should be copied into the kernel,
copied out of the kernel, copied into the kernel and copied back out of the
kernel, or left up to the ioctl handler to process, and the size of the
argument in bytes. They introduced some macros:
_IO() - for ioctls where the kernel does no copying;
_IOR() - for ioctls where the kernel copies data out ("R" for "read",
i.e., the kernel provides data to userland);
_IOW() - for ioctls where the kernel copies data in ("W" for "write",
i.e., data is provide to the kernel by userland);
_IOWR() - for ioctls where the kernel copies data in and back out.
The 4.2BSD definitions for those are:
#define _IO(x,y)(IOC_VOID|('x'<<8)|y)
#define _IOR(x,y,t)
(IOC_OUT|((sizeof(t)_MASK)<<16)|('x'<<8)|y)
#define _IOW(x,y,t)
(IOC_IN|((sizeof(t)_MASK)<<16)|('x'<<8)|y)
/* this should be _IORW, but stdio got there first */
#define _IOWR(x,y,t)
(IOC_INOUT|((sizeof(t)_MASK)<<16)|('x'<<8)|y)
This relied on x, within 'x', being expanded by the C preprocessor; you'd write
an ioctl as something such as
#define TIOCGETD_IOR(t, 0, int) /* get line discipline
*/
As I remember, ANSI C indicated that it should *not* be expanded, which broke
that; the current definitions, in systems that use BSD-style ioctls, are
something such as the 4.4BSD definitions:
#define _IOC(inout,group,num,len) \
(inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num))
#define _IO(g,n)_IOC(IOC_VOID, (g), (n), 0)
#define _IOR(g,n,t) _IOC(IOC_OUT, (g), (n), sizeof(t))
#define _IOW(g,n,t) _IOC(IOC_IN,(g), (n), sizeof(t))
/* this should be _IORW, but stdio got there first */
#define _IOWR(g,n,t)_IOC(IOC_INOUT, (g), (n), sizeof(t))
and you'd write an ioctl as something such as
#define TIOCGETD _IOR('t', 26, int) /* get line discipline */
(yes, they changed the code).
This meant that an ANSI C compiler for a UN*X with BSD-style ioctls defined in
a non-ANSI-compatible style couldn't rely on the system include files'
definitions of ioctl - it would have to have its own header files.
GCC handled this with a script called fixincludes, which tweaked
non-ANSI-C-compatible things in header files. The purpose of
AC_LBL_FIXINCLUDES is to handle pre-ANSI UN*Xes with GCC, to make sure that the
compile is getting the fixincludes-modified header files. It tests for _IO not
handling a first argument that's a C character constant rather than a character
to be stuffed into a C character constant.
This was not an issue for tcpdump 3.4, as it didn't do any ioctls.
