All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
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 13:30:27 -0700	[thread overview]
Message-ID: <20130525203027.GA31179@leaf> (raw)
In-Reply-To: <51A11077.2000605@ramsay1.demon.co.uk>

On Sat, May 25, 2013 at 08:26:47PM +0100, Ramsay Jones wrote:
> 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. ;-)

I meant, you could find some code that actually knows how to turn a
long double into a string directly, and include that for compatibility.

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

It needs to exactly match what GCC would produce on the same system.

- Josh Triplett

  reply	other threads:[~2013-05-25 20:30 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
2013-05-25 20:30         ` Josh Triplett [this message]
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=20130525203027.GA31179@leaf \
    --to=josh@joshtriplett.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=ramsay@ramsay1.demon.co.uk \
    --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.