> I always say it sucks to reply to myself but I keep doing it.
>
> These lines are from src/mingw/mingwex/pformat.c :
> #ifdef _WIN32
> /* TODO: make this unconditional in final release...
> * (see note at head of associated `#else' block.
> */
> #include "gdtoa.h"
>
> static
> char *__pformat_
I always say it sucks to reply to myself but I keep doing it.
These lines are from src/mingw/mingwex/pformat.c :
#ifdef _WIN32
/* TODO: make this unconditional in final release...
* (see note at head of associated `#else' block.
*/
#include "gdtoa.h"
static
char *__pformat_cvt( int mode, __pfor
Help ! :-)
I'm not convinced that alignment by the compiler is the issue. Test
program attached. This produces output such as this :
Addr of __local_argv is 2613F9C4
2613F9B0 DC 12 01 00 44 90 01 00 00 00 00 00 FB FF FF FF
2613F9C0 FF 00 00 00 30 00 14 26 C0 F9 13 26 0C 00 00 00
2613F9D0 14 FA 13
> Thanks for the analisys. Could you open up a bug report, so we
> don't forget about this?
Okay, done. For reference:
http://sourceforge.net/tracker/?func=detail&aid=2782228&group_id=173455&atid=865514
--
Pierre Ynard
--
On Wednesday 22 April 2009 15:47:05, Pierre Ynard wrote:
>
> > We have talked about double alignment before, could this be the
> > problem? Doubles must be 8 byte aligned on CE. Maybe va_arg doesn't to
> > align properly to the next 8 byte boundary when it's retrieving a
> > double? Either that, o
> We have talked about double alignment before, could this be the
> problem? Doubles must be 8 byte aligned on CE. Maybe va_arg doesn't to
> align properly to the next 8 byte boundary when it's retrieving a
> double? Either that, or the double isn't even stored with an 8 byte
> alignment when pas
On Tue, Apr 21, 2009 at 21:31, Danny Backx wrote:
> I don't think it's a printf issue.
>
> The statement
> fprintf(f, "foo %d %f %d\n", 34, 12.0, 67);
>
> prints
> foo 34 0.00 1076363264
>
> so I'm inclined to think that the varargs handling is off after a %f.
> Don't know what c
I don't think it's a printf issue.
The statement
fprintf(f, "foo %d %f %d\n", 34, 12.0, 67);
prints
foo 34 0.00 1076363264
so I'm inclined to think that the varargs handling is off after a %f.
Don't know what could cause this though.
Does anyone have a clue ?
Danny
> But it works well if you leave out the -D__USE_MINGW_ANSI_STDIO=1 flag.
>
> So why are you trying to do this ?
Without this flag, this program is dynamically linked against MSVCRT *printf
functions, and those present a number of bugs, shortcomings (like, no support
of %z modifiers) and weird
But it works well if you leave out the -D__USE_MINGW_ANSI_STDIO=1 flag.
So why are you trying to do this ?
Danny
On Mon, 2009-04-20 at 17:24 +0200, Pierre Ynard wrote:
> Hello,
>
> I'm working on the Windows CE port of the VLC media player, and after
> running into numerous portability
Hello,
I'm working on the Windows CE port of the VLC media player, and after
running into numerous portability problems with printf modifiers, we're
trying to use built-in mingw replacements, which seem to work fine.
However, %f specifiers don't work properly. For example, the following
program:
11 matches
Mail list logo
