From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Christopher Li <sparse@chrisli.org>,
Sparse Mailing-list <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH 3/5] Fix some "unknown format" warnings
Date: Sat, 25 May 2013 20:26:47 +0100 [thread overview]
Message-ID: <51A11077.2000605@ramsay1.demon.co.uk> (raw)
In-Reply-To: <20130522225410.GA12285@jtriplet-mobl1>
Josh Triplett wrote:
> On Wed, May 22, 2013 at 11:01:21PM +0100, Ramsay Jones wrote:
>> Josh Triplett wrote:
>>> On Tue, May 21, 2013 at 08:17:37PM +0100, Ramsay Jones wrote:
>> The current "compat" layer has an string_to_ld() function, so maybe
>> there should be an ld_to_string()? dunno.
>
> That seems like the best plan, if you can find a portable one to
> include.
Hmm, I'm not sure I understand; in this case, ld_to_string() would just
cast to double in order to sprintf. ;-)
>>>> @@ -463,7 +468,7 @@ const char *show_instruction(struct instruction *insn)
>>>> }
>>>>
>>>> if (buf >= buffer + sizeof(buffer))
>>>> - die("instruction buffer overflowed %td\n", buf - buffer);
>>>> + die("instruction buffer overflowed %d\n", (int)(buf - buffer));
>>>
>>> No, ptrdiff_t does not portably fit in int; it generally has the same
>>> size as size_t (64-bit on 64-bit platforms). Cast to "long long" and
>>> use PRId64 if you must.
>>
>> Yes, for the same reason, git does:
>>
>> printf("...%" PRIuMAX "...", (uintmax_t)(buf - buffer));
>>
>> so I'll do that in the re-roll.
>
> uintmax_t works; I suspect it might be overkill, but it'll work.
Oh, I think int is probably overkill (on 32-bit systems), but this
should cater for all future needs. ;-)
>>>> --- a/pre-process.c
>>>> +++ b/pre-process.c
>>>> @@ -158,12 +158,17 @@ static int expand_one_symbol(struct token **list)
>>>> } else if (token->ident == &__DATE___ident) {
>>>> if (!t)
>>>> time(&t);
>>>> +#if !defined(__MINGW32__)
>>>> strftime(buffer, 12, "%b %e %Y", localtime(&t));
>>>> +#else
>>>> + strftime(buffer, 12, "%b %d %Y", localtime(&t));
>>>> + if (buffer[4] == '0') buffer[4] = ' ';
>>>> +#endif
>>> To the best of my knowledge, nothing guarantees the length of %b, so the
>>> [4] here seems wrong.
>>
>> Yes, this was just a quick hack to compensate for the lack of the
>> "%e" format specifier in the msvc strftime(). (elsewhere the lack
>> of "%T" was easier to replace). I will have to think about this.
>> Any ideas?
>
> strftime returns the number of characters it generated; just format the
> "%b " separately so you have the offset needed for the %d and the
> modification.
Yep, I'll look into it. Having said that, I'm not sure we need to make
this string identical on all systems. dunno.
>>>> --- a/tokenize.c
>>>> +++ b/tokenize.c
>>>> @@ -547,8 +547,8 @@ static int get_one_number(int c, int next, stream_t *stream)
>>>> }
>>>>
>>>> if (p == buffer_end) {
>>>> - sparse_error(stream_pos(stream), "number token exceeds %td characters",
>>>> - buffer_end - buffer);
>>>> + sparse_error(stream_pos(stream), "number token exceeds %d characters",
>>>> + (int)(buffer_end - buffer));
>>>
>>> Same comment as above regarding ptrdiff_t.
>>>
>>> - Josh Triplett
>>
>> Thanks Josh. You hit every part of the patch that I wanted to
>> tidy up! :-D
>
> No problem; thanks for working on this! I'd love to see sparse used for
> Windows compilation.
>
> Have you managed to use it with a mingw cross-compiler, by any chance?
No, I'm afraid not. :(
ATB,
Ramsay Jones
next prev parent reply other threads:[~2013-05-25 20:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-21 19:17 [PATCH 3/5] Fix some "unknown format" warnings Ramsay Jones
2013-05-21 22:05 ` Josh Triplett
2013-05-22 22:01 ` Ramsay Jones
2013-05-22 22:54 ` Josh Triplett
2013-05-25 19:26 ` Ramsay Jones [this message]
2013-05-25 20:30 ` Josh Triplett
2013-05-23 15:42 ` Christopher Li
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=51A11077.2000605@ramsay1.demon.co.uk \
--to=ramsay@ramsay1.demon.co.uk \
--cc=josh@joshtriplett.org \
--cc=linux-sparse@vger.kernel.org \
--cc=sparse@chrisli.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.