Re: compiler warnings on AIX and Solaris

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Sat, 24 Jul 2021 10:55:19 -0700
>
> On Jul 23, 2021, at 4:11 PM, Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>
> > As it turns out, on Solaris 9 it is impossible to compile current
> > tcpdump with CFLAGS=-Werror because missing/getopt_long.c yields a few
> > warnings (attached). As far as the current revisions of this file go in
> > FreeBSD, NetBSD and OpenBSD, FreeBSD seems to be the closest and just a
> > bit newer than the current tcpdump copy (OpenBSD revision 1.22 -> 1.26).
> > However, it seems unlikely that porting the newer revision would make
> > the warnings go away, because, for example, permute_args() has not
> > changed at all.
>
> At least when it comes to not violating the promises made by the API definition, the BSD implementations of 
> getupt_long(), the GNU libc implementation of getopt_long(), and the Solaris implementation of getopt_long() are all 
> broken by design.
>
> The declaration is
>
>         int getopt_long(int argc, char * const *argv, const char *optstring, const struct option *longopts, int 
> *longindex);
>
> where "char * const *argv" means, to quote cdecl.org, "declare argv as pointer to const pointer to char", which means 
> that the pointer(s) to which argv points cannot be modified.  What the pointers point *to* - i.e., the argument strings 
> - can be modified, but the pointers in the argv array will not be modified.
>
> All three implementations could shuffle the arguments in argv[] (as per the name "permute_args" in the BSD 
> implementations) unless either 1) the option string begins with a "+" or 2) the POSIXLY_CORRECT environment variable is 
> set.
>
> This isn't an issue for us on systems that provide getopt_long() - it's an issue for whoever compiles the standard 
> library if they turn on "warn about casting away constness", but it's not an issue for *us*, as somebody else compiled 
> the standard library.  Thus, it doesn't show up on Linux (GNU libc), *BSD/macOS (BSD), or newer versions of Solaris 
> (they added getopt_long() to the library).
>
> It is, however, an issue for us if 1) the platform doesn't provide getopt_long() (presumably it was added to Solaris 
> after Solaris 9), so it has to be compiled as part of the tcpdump build process and 2) the compiler issues that warning.
>
> It's not currently an issue on Windows when compiling with MSVC, because either 1) MSVC never issues that warning or 2) 
> it can but we're not enabling it.
>
> So the only way to fix this is to turn off the warnings; change 39f09d68ce7ebe9e229c9bf5209bfc30a8f51064 adds macros to 
> disable and re-enable -Wcast-qual and wraps the offending code in getopt_long.c with those macros, so the problem 
> should be fixed on Solaris 9.
>
> > The same problem stands on AIX 7,
>
> AIX also doesn't appear to provide getopt_long(), at least as of AIX 7.2:
>
>         https://www.ibm.com/docs/en/aix/7.2?topic=reference-base-operating-system-bos-runtime-services
>
> so the same problem occurs; the change should fix that as well.
>
> > and in addition there is an issue
> > specific to XL C compiler, in that ./configure detects that the
> > compiler does not support -W, but then proceeds to flex every -Wxxxx
> > option anyway, which the compiler treats as a soft error,
>
> "The compiler treats [that] as a s soft error" is the problem - the configure script checks currently require that 
> unknown -W flags be a *hard* error, so that attempting to compile a small test program with that option fails.
>
> If there's a way to force XL C to treat it as a hard error, we need to update the 
> AC_LBL_CHECK_UNKNOWN_WARNING_OPTION_ERROR autoconf macro to set the compiler up to use it when testing whether compiler 
> options are supported.
>
> If there *isn't* a way to do that, the configure-script test also needs to scan the standard error of the compilation 
> and look for the warning, and treat that as an indication of lack of support as well.  (I think the equivalent test 
> provided as part of CMake may already do that.)
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers