git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [test failure] Re: t4114 binary file becomes symlink

From
Jeff King <peff@peff.net>
Date
Jul 20, 2009, 09:09 UTC
Message-ID
<20090720090937.GA20412@sigill.intra.peff.net>
In-Reply-To
<200907191301.15533.j6t@kdbg.org>
On Sun, Jul 19, 2009 at 01:01:15PM +0200, Johannes Sixt wrote:
Show 9 quoted lines
> 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
Previous: Johannes SixtNext: Johannes Sixt
Message 30 of 32 in “[test failure] t4114 binary file becomes symlink”
  1. Nicolas SebrechtJul 18, 2009
  2. Jeff KingJul 18, 2009
  3. [test failure] Re: t4114 binary file becomes symlinkNicolas Sebrecht, Jul 18, 2009
  4. Jeff KingJul 18, 2009
  5. Junio C HamanoJul 18, 2009
  6. [test failure] Re: t4114 binary file becomes symlinkNicolas Sebrecht, Jul 18, 2009
  7. Linus TorvaldsJul 18, 2009
  8. Johannes SixtJul 18, 2009
  9. [test failure] Re: t4114 binary file becomes symlinkNicolas Sebrecht, Jul 18, 2009
  10. [test failure] Re: t4114 binary file becomes symlinkNicolas Sebrecht, Jul 18, 2009
  11. ./configure misdetects SNPRINTF_RETURNS_BOGUS (was: [test failure] t4114 binary file becomes symlink)Jakub Narebski, Jul 19, 2009
  12. configure: use AC_SEARCH_LIBS instead of AC_CHECK_LIBNicolas Sebrecht, Jul 19, 2009
  13. Re: configure: use AC_SEARCH_LIBS instead of AC_CHECK_LIBNicolas Sebrecht, Jul 19, 2009
  14. Junio C HamanoJul 19, 2009
  15. Eric BlakeJul 19, 2009
  16. Brandon CaseyJul 21, 2009
  17. Brandon CaseyJul 21, 2009
  18. Paolo BonziniJul 21, 2009
  19. Brandon CaseyJul 21, 2009
  20. configure.ac: rework/fix the NEEDS_RESOLV and NEEDS_LIBGEN testsBrandon Casey, Jul 21, 2009
  21. Junio C HamanoJul 21, 2009
  22. Brandon CaseyJul 22, 2009
  23. config.mak.in: continue fixing NEEDS_LIBGEN autoconfigure featureBrandon Casey, Jul 22, 2009
  24. Junio C HamanoJul 22, 2009
  25. Brandon CaseyJul 23, 2009
  26. Johannes SixtJul 18, 2009
  27. Jeff KingJul 18, 2009
  28. [test failure] Re: t4114 binary file becomes symlinkNicolas Sebrecht, Jul 18, 2009
  29. Johannes SixtJul 19, 2009
  30. Jeff KingJul 20, 2009
  31. Johannes SixtJul 20, 2009
  32. Linus TorvaldsJul 20, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.