From: Jeff King <peff@peff.net>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [test failure] Re: t4114 binary file becomes symlink
Date: Mon, 20 Jul 2009 05:09:38 -0400 [thread overview]
Message-ID: <20090720090937.GA20412@sigill.intra.peff.net> (raw)
In-Reply-To: <200907191301.15533.j6t@kdbg.org>
On Sun, Jul 19, 2009 at 01:01:15PM +0200, Johannes Sixt wrote:
> Problem is, snprintf was made for very old systems, which typically do
> not have va_copy. (E.g. Windows, but there the situation *might* have
> changed with the switch to gcc 4.)
>
> The rationale not to use va_copy is that this function is to be used
> *only* if necessary, i.e. portability is already lacking, and if it
> can be verified that this function works as is. Portability and
> correct-by-the-law C code are *not* a goal here. If the function does
> not work as is, don't use it.
OK, I guess I can buy the "don't use this unless you need it" rationale.
But two questions:
1. _Are_ we sure it works under Windows? That is, do we know for a
fact that using a va_list twice is OK there, or are we just going
on the fact that nobody has reported the bug?
If we're not sure, then you might want to try running the recipe
below which consistently produces a segfault for me on Linux amd64
(but not i386, which seems to use a different representation for
va_lists).
2. In this case, using SNPRINTF_RETURNS_BOGUS was a mistake. But
unfortunately using it erroneously doesn't simply cause the
compilation to barf, or to use a slower implementation; instead it
introduces a very subtle and hard to diagnose bug on some
platforms. Is there anything simple we can do to protect people
from that?
I can't really think of anything simple, because such a mechanism
would basically involve compiling a test program and seeing if it
segfaults.
Anyway, bug-reproducing recipe is below.
-- >8 --
cat <<'EOF' >test-vsnprintf.c
#define SNPRINTF_RETURNS_BOGUS
#include "git-compat-util.h"
int main() {
char buf[16];
/* this 8 may need to be tweaked depending on
* the system's vsnprintf return value; the goal
* is to get git_vsnprintf to have to look at
* it's va_list twice */
git_snprintf(buf, 8, "%s %s", "foo", "bar");
return 0;
}
EOF
make test-vsnprintf.o compat/snprintf.o
gcc -o test-vsnprintf test-vsnprintf.o compat/snprintf.o
./test-vsnprintf ;# or valgrind test-vsnprintf
next prev parent reply other threads:[~2009-07-20 9:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-18 13:45 [test failure] t4114 binary file becomes symlink Nicolas Sebrecht
2009-07-18 13:56 ` Jeff King
2009-07-18 14:16 ` [test failure] " Nicolas Sebrecht
2009-07-18 15:31 ` Jeff King
2009-07-18 18:46 ` Junio C Hamano
2009-07-18 20:39 ` Nicolas Sebrecht
2009-07-18 23:18 ` Linus Torvalds
2009-07-18 19:06 ` Johannes Sixt
2009-07-18 20:17 ` Nicolas Sebrecht
2009-07-18 21:13 ` Nicolas Sebrecht
2009-07-19 10:33 ` ./configure misdetects SNPRINTF_RETURNS_BOGUS (was: [test failure] t4114 binary file becomes symlink) Jakub Narebski
2009-07-19 12:48 ` [PATCH] configure: use AC_SEARCH_LIBS instead of AC_CHECK_LIB Nicolas Sebrecht
2009-07-19 13:14 ` [PATCH] " Nicolas Sebrecht
2009-07-19 16:13 ` Junio C Hamano
2009-07-19 22:53 ` Eric Blake
2009-07-21 15:04 ` [PATCH] " Brandon Casey
2009-07-21 15:12 ` Brandon Casey
2009-07-21 15:20 ` Paolo Bonzini
2009-07-21 15:34 ` Brandon Casey
2009-07-21 20:23 ` [PATCH] configure.ac: rework/fix the NEEDS_RESOLV and NEEDS_LIBGEN tests Brandon Casey
2009-07-21 20:33 ` Junio C Hamano
2009-07-22 14:59 ` Brandon Casey
2009-07-22 22:15 ` [PATCH] config.mak.in: continue fixing NEEDS_LIBGEN autoconfigure feature Brandon Casey
2009-07-22 22:35 ` Junio C Hamano
2009-07-23 16:22 ` Brandon Casey
2009-07-18 22:03 ` [test failure] Re: t4114 binary file becomes symlink Johannes Sixt
2009-07-18 22:29 ` Jeff King
2009-07-18 22:51 ` Nicolas Sebrecht
2009-07-19 11:01 ` Johannes Sixt
2009-07-20 9:09 ` Jeff King [this message]
2009-07-20 20:51 ` Johannes Sixt
2009-07-20 21:56 ` Linus Torvalds
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=20090720090937.GA20412@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=nicolas.s.dev@gmx.fr \
/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 NNTP newsgroup(s).