janssens-geert at telenet.be
Wed May 7 12:43:19 EDT 2014
On Wednesday 07 May 2014 12:30:42 Derek Atkins wrote:
> Geert Janssens <janssens-geert at telenet.be> writes:
> > On Friday 02 May 2014 14:55:42 John Ralls wrote:
> >> > > then I get the dreaded unrecognized “l” format error,
> >> >
> >> > What is the dreaded unrecognized "l" format error ? I have never
> >> > seen it on my WinXP test system. In which step do you get this ?
> >> It’s that the ancient msvcrt.dll used by MinGW doesn’t know about
> >> %lld for printing or scanning int64s. Back before Microsoft
> >> accepted the c99 standard (around 2006, IIRC) their printf()
> >> required using %I64d instead, and threw a "unknown conversion type
> >> character 'l' in format [-Wformat]” warning. The msvcrt.dll in
> >> MinGW is that old. There are a couple of workarounds, and
> >> -D__USE_MINGW_ANSI_STDIO is one of them.>
> > Ok. Just to clear it up completely for me: when you set that
> > directive mingw does understand %lld ?
> Note that %ld v %lld varies on Linux too. To print/scan a gint64 you
> need %lld on 32-bit linux but %ld on 64-bit linux (because long long
> is 64/128 bits respectively!) This is why we try to use
> G_INT64_FORMAT everywhere, because it will generally "do the right
What will happen when we move away from glib eventually ? Isn't
G_INT64_FORMAT a glib defined macro ?
> > Would that also work on Windows XP or not ? Hmm, Windows XP is
> > 32-bit
> > only so perhaps when building on WinXP you never see that directive.
> > Is it a problem only for 64-bit ?
> > Perhaps related: business users can define a number format for
> > invoices/bills via File->Properties->Business. I remember there also
> > this problem of %lld vs %I64d is rearing its ugly head. So if we
> > build gnucash with the above directive perhaps this problem would
> > go away as well ?
> IMHO this code should arguably rewritten so that it does not get
> passed directly to printf but instead we should design our own
> language (that could *look* like printf if we desired) to make it
> platform agnostic.
That certainly makes sense to me.
More information about the gnucash-devel