This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/16421] IN6_IS_ADDR_UNSPECIFIED can use undefined s6_addr32


https://sourceware.org/bugzilla/show_bug.cgi?id=16421

--- Comment #12 from Octavio Alvarez <alvarezp at alvarezp dot ods.org> ---
Thank you. Today I have learned about statement expressions and how they are
GCC extensions.

If we add an #ifdef __GNUC__ we would also have to add an #else that avoids the
usage of non-ISO C extensions anyway so Clang do not throw any warnings or
compilers that don't define __GNUC__ still have IN6_* macros available. Again,
two implementations. Now I understand why was the original code in that form.

If the goal is to have a universal implementation it's no use to have it
wrapped in #ifdef __GNUC__. It just stops being universal.

Given the above, there is no use on exposing __in6_u.__u6_addr32 for the
purpose of fixing this bug, then.

Either we go back to patch #1, which keeps both implementations and just adds
the test for definition of __USE_GNU and __USE_MISC macros and does not break
strict compilers, or we remove the #ifdef __GNUC__ implementation altogether
and leave only the #else implementation unconditionally.

Sample of the #else implementation:
# define IN6_IS_ADDR_UNSPECIFIED(a) \
        (((const uint32_t *) (a))[0] == 0                                     \
         && ((const uint32_t *) (a))[1] == 0                                  \
         && ((const uint32_t *) (a))[2] == 0                                  \
         && ((const uint32_t *) (a))[3] == 0)

I will gladly attach a patch with just the #else implementation for your
review, but I still think the best bet to use the original patch.

Git commit aff2453d [1] (Dec 2011) shows that originally, only the #else
implementation existed but Ulrich Drepper added a GCC-specific implementation,
apparently to avoid warnings. Later, in commit a784e502 [2] (Jan 2012), he
changed the usage of __const to plain const, removing pre-ISO C
implementations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]