git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).