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




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