All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tautschnig <mt@debian.org>
To: Sven Eckelmann <sven@narfation.org>
Cc: 703540@bugs.debian.org, b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Bug#703540: Inconsistent use of _GNU_SOURCE
Date: Fri, 29 Mar 2013 11:48:16 +0000	[thread overview]
Message-ID: <20130329114816.GR798@l04.local> (raw)
In-Reply-To: <3212285.GF4Btbehao@sven-desktop>

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

Hi Sven, hi all,

[...]
> > Either all or no file should #define _GNU_SOURCE.
> 
> Please add information how to reproduce this the next time you are adding such 
> such a bug. Now I can just assume what you are writing is true (even when the 
> man page about sendto says otherwise). Not knowing how to reproduce it in the 
> best possible way just makes it harder for everyone to check the impact of the 
> problem.
> 

Just one question before I elaborate a bit: what information in the man page are
you referring to? I can't quite seem to see anything mentioning _GNU_SOURCE?

I fully understand your concerns and indeed it is a problem that I cannot quite
provide a concrete counterexample witnessing the problem. It may even be the
cast that, at present, this is only a potential problem and not a real one. It's
much like a compiler warning: ok to be ignored if you are doing it intentionally
and you are 100% sure you know what you are doing. In all other cases, however,
it is likely worth fixing, as the problem can only ever be found by link-time
type checking, which usual compilers can't do. Even if done, there is some
non-trivial effort required to tracing back the type inconsistency to
inconsistent order of #include or a missing #define.

The most I can provide right now is all the scripts that suffice to reproduce
the build results and error logs, to be found at
https://github.com/tautschnig/cprover-debian

> I've forwarded it to the upstream maintainer and attached the change for 
> Debian.
> 
[...]

Thanks!

Best,
Michael


[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2013-03-29 11:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130320175154.GT41481@l04.local>
2013-03-21  8:24 ` [B.A.T.M.A.N.] Bug#703540: Inconsistent use of _GNU_SOURCE Sven Eckelmann
2013-03-21 15:16   ` [B.A.T.M.A.N.] [PATCH] batmand: Either all or no source file should #define _GNU_SOURCE Elektra
2013-03-21 15:20     ` Elektra
2013-03-29 11:48   ` Michael Tautschnig [this message]
2013-03-29 12:37     ` [B.A.T.M.A.N.] Bug#703540: Inconsistent use of _GNU_SOURCE Antonio Quartulli
2013-04-02  9:10     ` Sven Eckelmann

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=20130329114816.GR798@l04.local \
    --to=mt@debian.org \
    --cc=703540@bugs.debian.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=sven@narfation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.