public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "alvarezp at alvarezp dot ods.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/16421] IN6_IS_ADDR_UNSPECIFIED can use undefined s6_addr32
Date: Tue, 04 Feb 2014 17:30:00 -0000	[thread overview]
Message-ID: <bug-16421-131-vkxBoOSPyG@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-16421-131@http.sourceware.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.


  parent reply	other threads:[~2014-02-04 17:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 12:46 [Bug network/16421] New: " kazssym at vx68k dot org
2014-01-10 19:58 ` [Bug network/16421] " bugdal at aerifal dot cx
2014-01-11  9:57 ` kazssym at vx68k dot org
2014-01-11 15:29 ` bugdal at aerifal dot cx
2014-02-04  4:09 ` carlos at redhat dot com
2014-02-04  4:11 ` carlos at redhat dot com
2014-02-04  4:12 ` carlos at redhat dot com
2014-02-04  4:14 ` alvarezp at alvarezp dot ods.org
2014-02-04  4:59 ` alvarezp at alvarezp dot ods.org
2014-02-04  5:11 ` alvarezp at alvarezp dot ods.org
2014-02-04 14:55 ` carlos at redhat dot com
2014-02-04 17:30 ` alvarezp at alvarezp dot ods.org [this message]
2014-02-04 17:46 ` carlos at redhat dot com
2014-02-04 18:08 ` alvarezp at alvarezp dot ods.org
2014-02-04 18:16 ` carlos at redhat dot com
2014-02-04 18:55 ` carlos at redhat dot com
2014-02-04 18:57 ` carlos at redhat dot com
2014-02-04 22:30 ` alvarezp at alvarezp dot ods.org
2014-02-04 22:38 ` alvarezp at alvarezp dot ods.org
2014-02-04 22:51 ` joseph at codesourcery dot com
2014-02-04 22:54 ` carlos at redhat dot com
2014-02-05  0:03 ` joseph at codesourcery dot com
2014-02-06 23:13 ` alvarezp at alvarezp dot ods.org
2014-02-28 20:47 ` alvarezp at alvarezp dot ods.org
2014-06-13  9:08 ` fweimer at redhat dot com
2015-04-23 13:41 ` alvarezp at alvarezp dot ods.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-16421-131-vkxBoOSPyG@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).