Kai,

Everything you said about the code is correct.  It's a simple 10 line hack to 
demonstrate the problem that in no way resembles any production code I have 
that is currently failing.  If it is working properly, the exit value should be 
183.  So your toolchain does not exhibit the problem I'm describing.  Yes, any 
(system error code % 256) == 183 would be a false positive.  I'm also not 
assuming that GetLastError doesn't return 0.  It should return 183 
(ERROR_ALREADY_EXISTS).  In an effort to make the example as concise as 
possible, I removed the print statements (although I now see I failed to remove 
the #includes) and just used the value as the exit value.  The issue is that 
mingw-w64 (or at least Ruben's latest build of it), clears the system error 
code while unwinding the stack.

What host are you running on and is your gcc configured with win32 or the posix 
thread api?   These are the settings for my current toolchain that fails under 
32-bit Windows XP:
C:\Temp>c:\MinGW.ruben\bin\gcc -v
Using built-in specs.
COLLECT_GCC=c:\MinGW.ruben\bin\gcc
COLLECT_LTO_WRAPPER=c:/mingw.ruben/bin/../libexec/gcc/i686-w64-mingw32/4.7.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure 
--host=i686-w64-mingw32 --build=x86_64-linux-gnu --target=i686-w64-mingw32 
--with-sysr
oot=/home/ruben/mingw-w64/toolchain/mingw32mingw32/mingw32 
--prefix=/home/ruben/mingw-w64/toolchain/mingw32mingw32/mingw32 
--with-libiconv-prefix=/home/r
uben/mingw-w64/toolchain/mingw32mingw32/prereq_install 
--with-gmp=/home/ruben/mingw-w64/toolchain/mingw32mingw32/prereq_install 
--with-mpfr=/home/ruben/m
ingw-w64/toolchain/mingw32mingw32/prereq_install 
--with-mpc=/home/ruben/mingw-w64/toolchain/mingw32mingw32/prereq_install 
--with-ppl=/home/ruben/mingw-w6
4/toolchain/mingw32mingw32/prereq_install 
--with-cloog=/home/ruben/mingw-w64/toolchain/mingw32mingw32/prereq_install 
--enable-cloog-backend=isl --with-ho
st-libstdcxx='-static -lstdc++ -lm' --enable-shared --enable-static 
--enable-threads=posix --disable-multilib 
--enable-languages=c,lto,c++,objc,obj-c++,f
ortran,java --enable-libgomp --enable-libstdcxx-debug --enable-sjlj-exceptions 
--enable-fully-dynamic-string --disable-nls --disable-werror --enable-chec
king=release --disable-win32-registry --disable-rpath --disable-werror 
CFLAGS='-O2 -mtune=corei7 -fomit-frame-pointer -momit-leaf-frame-pointer 
-fgraphit
e-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS=
Thread model: posix
gcc version 4.7.0 20120311 (prerelease) (GCC) 

The only thing that stands out to me is maybe the enabled extensions for using 
the POSIX thread model has something to do with it.  Previously, I've only used 
builds that use the win32 thread model.

Thanks,
Josh

-----Original Message-----
From: Kai Tietz [mailto:[email protected]] 
Sent: Sunday, March 18, 2012 4:35 AM
To: [email protected]
Subject: EXTERNAL: Re: [Mingw-w64-public] GetLastError doesn't work reliably in 
mingw-w32 w/ gcc 4.7

Hello Josh,

this code you have shown makes one wrong assumption.  You assume that on a 
successful call of an API the GetLastError() would have result of 0.  This 
isn't true.  If you want to enforce that, you need to use before this call an 
explicit 'SetLastError (0);'  before calling the create-directory function.

I tested it with my current 4.7.0 toolchain for 32-bit and 64-bit, and I can't 
reproduce that the result would be 0 for it on second call.
The error-code returned on second call is 183 for me.  Nevertheless this is 
another wrong assumption you have within your code.  You assume that process 
exit code has width of 32-bit.  That's not true.
The exit-code has range of 0-255 by C-runtime.  Therefore, if you want to have 
exit-codes out-side this range, then you need to call explicit TerminateProcess.

Regards,
Kai

2012/3/18 Davidson, Josh <[email protected]>:
> I installed Ruben's latest win32 build of mingw-w32 this afternoon and 
> immediately ran it runtime issues with third party libraries (one of which is 
> boost) that I'm using in my application.  After some analysis, the root of 
> the issue is that the Windows's system error code is cleared upon a function 
> return.  This has not been the behavior for previous releases MinGW.  Below 
> is a simple program that creates a directory.  If you run it twice (or create 
> c:\temp\zomg prior to running) it should exit with a return code of 183.  
> Using Ruben's latest mingw-w32 with gcc 4.7, it exits with 0, since the error 
> code is cleared upon returning from the function create.  If you move the 
> code in that function to "main" everything works as intended.
>
> Is this going to be the way gcc 4.7 works (I know the return semantics have 
> changed slightly)?  Or is this a problem with the current state of mingw-w32 
> and/or Ruben's build?  As far as I know, Ruben's build is the only 
> functioning win32 host build for mingw-w32  w/ gcc 4.7 (the CRT bundled with 
> the automated builds is missing symbols).
>
> [code]
> #include <Windows.h>
>
> #include <iostream>
> using namespace std;
>
> void create(const char* name) {
>    SECURITY_DESCRIPTOR sd;
>    InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION);
>    SetSecurityDescriptorDacl(&sd, true, 0, false);
>    SECURITY_ATTRIBUTES sa;
>    sa.nLength = sizeof(SECURITY_ATTRIBUTES);
>    sa.lpSecurityDescriptor = &sd;
>    sa.bInheritHandle = false;
>
>   int val = CreateDirectoryA(name, &sa); }
>
> int main() {
>    const char* name = "C:\\Temp\\zomg";
>    create(name);
>    return GetLastError();
> }
> [/code]
>
> ----------------------------------------------------------------------
> --------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure 
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure 
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to