From: Johannes Sixt <j.sixt@viscovery.net>
To: Michal Rokos <michal.rokos@nextsoft.cz>
Cc: GIT <git@vger.kernel.org>
Subject: Re: [PATCH] Add compat/vsnprintf.c for systems that returns -1 on maxsize reached
Date: Wed, 05 Mar 2008 15:28:48 +0100 [thread overview]
Message-ID: <47CEAE20.1030707@viscovery.net> (raw)
In-Reply-To: <200803051455.57148.michal.rokos@nextsoft.cz>
Michal Rokos schrieb:
> On Wednesday 05 March 2008 10:18:10 Johannes Sixt wrote:
>> It's not the same on Windows, which returns:
>> case1: -1
>> case2: 5
>> case3: 5
>> case4: 5
>>
>> BTW, this is not only an issue of vsnprintf, but also of snprintf!
>
> Hmm, HPUX has the same issue for snprint() as is for vsnprintf().
>
> Do you think that following patch suffices your needs. Please note that it
> actually copies data to str.
... in the case where the buffer is too small? This won't be a problem for
our users.
> +# Define SNPRINTF_RETURNS_BOGUS if your are on a system which snprintf()
> +# returns -1 instead of number of characters which would have been written
> +# to the final string if enough space had been available.
> +#
> +# Define VSNPRINTF_RETURNS_BOGUS if your are on a system which vsnprintf()
> +# returns -1 instead of number of characters which would have been written
> +# to the final string if enough space had been available.
We don't need two configuration variables. I think we can assume that if
vsnprintf is broken, then snprintf will be broken, too:
# Define SNPRINTF_RETURNS_BOGUS if your are on a system which snprintf()
# and vsnprintf() return -1 instead of number of characters that would
# have been written to the final string if enough space had been
# available.
> +AC_CACHE_CHECK([whether snprintf() returns bogus],
> + [ac_cv_snprintf_returns_bogus],
> +[
> +AC_RUN_IFELSE(
> + [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT],
> + [[char buf[1];
> + if (snprintf(bug, 1, "%s", "12345") != 5) return 1]])],
^^^
buf?
Are you trying to test for the second bogus behavior on Windows? Don't do
it! I've thought about it for 5 minutes, but I can't come up with a simple
test that would detect its odd behavior.
> diff --git a/dev/null b/compat/snprintf.c
> new file mode 100644
> index 0000000..bc0d37c
> --- /dev/null
> +++ b/compat/snprintf.c
> @@ -0,0 +1,37 @@
> +#include "../git-compat-util.h"
> +
> +#undef vsnprintf
> +int git_vsnprintf(char *str, size_t maxsize, const char *format, va_list ap)
> +{
> + char *s;
> + int size;
> +
> + int ret = vsnprintf(str, maxsize, format, ap);
> + if (ret != -1 ) return ret;
'return' goes on its own line. Indentation is one tabstop, not two spaces.
Thank you.
> +
> + s = NULL;
You could reuse str here.
> + size = maxsize;
We are trying to find a suitably long buffer in a loop. We should spend as
few cycles as possible. Therefore, my implementation used a minimum of
250*4 for the first try just in case the caller had a long string to
construct. (And it protects against maxsize == 0.)
> + while ( ret == -1 )
> + {
> + size *= 4;
> + s = realloc(s, size);
> + if (! s) return -1;
Could you avoid the memory leak on this error path?
> + ret = vsnprintf(s, size, format, ap);
> + }
> + if (str && maxsize > 0) memcpy(str, s, maxsize);
Why this?
> + free(s);
> + return ret;
> +}
-- Hannes
next prev parent reply other threads:[~2008-03-05 14:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-04 13:59 [PATCH] Add compat/vsnprintf.c for systems that returns -1 on maxsize reached Michal Rokos
2008-03-04 14:09 ` Johannes Schindelin
2008-03-04 14:09 ` Finn Arne Gangstad
2008-03-04 16:19 ` Johannes Sixt
2008-03-04 14:12 ` Morten Welinder
2008-03-04 16:28 ` Johannes Sixt
2008-03-04 23:51 ` Wayne Davison
2008-03-05 8:37 ` Michal Rokos
2008-03-05 8:44 ` Jeff King
2008-03-05 9:18 ` Johannes Sixt
2008-03-05 13:55 ` Michal Rokos
2008-03-05 14:28 ` Johannes Sixt [this message]
2008-03-05 15:00 ` Michal Rokos
2008-03-05 15:22 ` Johannes Sixt
2008-03-05 15:48 ` Michal Rokos
2008-03-05 15:54 ` Wayne Davison
2008-03-05 16:04 ` Johannes Sixt
2008-03-05 22:33 ` Wayne Davison
2008-03-05 21:05 ` Junio C Hamano
2008-03-05 9:22 ` Mike Ralphson
2008-03-05 10:35 ` Robert Haines
2008-03-05 13:58 ` Michal Rokos
2008-03-10 8:59 ` Michal Rokos
2008-03-10 9:28 ` Johannes Sixt
2008-03-10 9:47 ` Michal Rokos
2008-03-10 10:05 ` Johannes Sixt
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=47CEAE20.1030707@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@vger.kernel.org \
--cc=michal.rokos@nextsoft.cz \
/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).