This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug network/16421] IN6_IS_ADDR_UNSPECIFIED can use undefined s6_addr32
- From: "alvarezp at alvarezp dot ods.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 04 Feb 2014 17:30:42 +0000
- Subject: [Bug network/16421] IN6_IS_ADDR_UNSPECIFIED can use undefined s6_addr32
- Auto-submitted: auto-generated
- References: <bug-16421-131 at http dot sourceware dot org/bugzilla/>
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.