http://bugs.winehq.org/show_bug.cgi?id=25273 Summary: svcrt/misc.ok I10_OUTPUT long double crash with winetest.exe, not make test Product: Wine Version: 1.3.7 Platform: x86 OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net msvcrt/misc.ok crashes with winetest.exe (or the msvcrt_test.exe therein), but not with make test. It seems that the format of "long double" does not match what's expected. A trace with make test yields a correct trace: msvcrt:MSVCRT_I10_OUTPUT (0.000000 10 0 0x32fd14) winetest.exe leads instead to: msvcrt:MSVCRT_I10_OUTPUT (0.000000 0 64fd20 0x64) Unhandled exception: page fault on write access to 0x00000066 in 32-bit code (0x4034add6). 0x4034add6 _MSVCRT_I10_OUTPUT+0x66 in msvcrt: movb $0x20,0x2(%edi) This could be: - a bug in gcc on MacOS X 10.5.8 i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566) What do other Mac users experience? - MacOS'gcc "long double" format not matching the MS one (or another parameter passing convention)? - MSVCRT__LDOUBLE not defined correctly on MacOS? long double parameters might behave differently than struct { long double; } (test/misc.c test calls long double, while msvcrt/string.c operates on struct?) - the .spec file unable to deal with the format @ cdecl -norelay $I10_OUTPUT(double long long long ptr) MSVCRT_I10_OUTPUT is not distinguishable from a (double, int, int, void*) function. - ...? It seems that msvcrt/misc/I10_OUTPUT_test is solely affected because it's the only test involving the long double format. BTW, line #9, which tests 0.0, 10, 1 logs msvcrt:MSVCRT_I10_OUTPUT (0.000000 1 64fd20 0x64) I.e. the third parameter appears in second position. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.