[bug #68042] gnulib compilation warnings

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

Update of bug #68042 (group octave):

                  Status:                    None => Wont Fix
             Open/Closed:                    Open => Closed

    _______________________________________________________

Follow-up Comment #1:

Here is the response from gnulib upstream:

1. The tautological comparison is Won't Fix. The code in gnulib is as
follows:

  extern signed char const base64_to_int[256];

  BASE64_INLINE bool
  isubase64 (unsigned char ch)
  {
    return ch < sizeof base64_to_int && 0 <= base64_to_int[ch];
  }

The first comparison in the return statement is to guard against the size
being too small, but since the compiler has figured out the size of that array
and realized it is a tautology in this case, it is issuing the warning. It
would not be a tautology if the size of the array were (accidentally) declared
to be smaller than 256, so that comparison is going to be retained by gnulib
to guard against that possibility. Individual users can add
"-Wno-tautological-constant-out-of-range-compare" to compilation flags to
avoid that warning (this flag is enabled by gnulib but disabled by Octave
itself as part of "-Wall", so when Octave includes a gnulib header like in
this case, that warning shows up.)

2. The const qualifier warning has been fixed by gnulib and won't show up for
future versions of gnulib that are included by Octave.

3. The warning about "-Wformat-security" comes down to a difference between
gcc and clang on how each compiler processes "gettext": gcc hides such
warnings when it sees that the function is gettext(), and clang does not do
such special-case suppression. This leads to clang issuing more warnings than
gcc for the same code. This is a Won't Fix for gnulib. We could submit a bug
report upstream to LLVM to handle gettext like how gcc handles it, but no
behavior change is guaranteed.

Link to upstream discussion thread:
https://lists.gnu.org/archive/html/bug-gnulib/2026-02/msg00070.html

Closing this report as Won't Fix (it's 1/3 fixed and 2/3 won't fix).


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68042>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCaY5gLAAKCRCqLAuaBUf3
TiRlAP4jHb0oMm0EJo/rLRSmhpyDlfFJ5zTHvU69mLRD0nAK7wD/e6NmYti9vM67
A5aGcJkg8C2TA5reKrdYq5JmmO95Fws=
=gJ2f
-----END PGP SIGNATURE-----