Hello Ruben! On Sun, Nov 6, 2011 at 7:47 AM, Ruben Van Boxem <[email protected]> wrote: > 2011/11/6 K. Frank <[email protected]> >> >> Hi Ruben (and Kai)! >> >> On Sat, Nov 5, 2011 at 6:35 PM, Ruben Van Boxem >> <[email protected]> wrote: >> > Op 5 nov. 2011 22:58 schreef "K. Frank" <[email protected]> het >> > volgende: >> >> ... >> >> On Sat, Nov 5, 2011 at 3:20 PM, Kai Tietz <[email protected]> >> >> wrote: >> >> > 2011/11/5 K. Frank <[email protected]>: >> >> >> Hello Everyone! >> >> >> >> >> >> I see the same behavior on a couple of other mingw-w64 versions. >> >> >> ... >> >> >> Okay, I tried this on two more compiler versions, and I get the same >> >> >> result, namely that the loop seems to "exit" early. >> >> >> >> >> >> These are two Ozkan Sezer builds: 4.4.5 and 4.5.2: >> >> >> >> >> >> g++ (GCC) 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] >> >> >> g++ (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902 - >> >> >> mingw-w64/oz] >> >> >> ... >> >> >> K. Frank >> >> > >> >> > The only thing it might could be here, is that erase-call raises an >> >> > exception, but why you see the goodbye message here than? >> >> >> >> Yes, I had thought of the exception possibility (although, as you say, >> >> it doesn't really make sense because of the goodbye message). So >> >> I actually put a try block in my test program (in main): >> >> ... >> >> The try wraps the calls to operator<< that trigger the calls to xsputn, >> >> so this would seem to show that no exception is being thrown (as no >> >> "exception caught" message is being printed out). >> > >> > I would take this to stackoverflow.com, try to reduce the code a bit >> > further... There's a lot of language lawyers there that should be able >> > to >> > formulate a correct answer if asked the right question. Be concise but >> > complete ;-) >> > >> > Ruben >> >> ... >> >> K. Frank >> >> I was thinking that because the bug shows up on a number of different >> mingw-w64 g++ versions, perhaps the bug is not mingw-w64-specific, >> but rather in the upstream (64-bit) g++. >> >> I don't have access to a 64-bit linux platform, but I wonder whether the >> same bug would show up when compiling and running the test program >> on linux with 64-bit g++. >> >> Also, I tired compiling the test code with the Comeau online compiler >> and it gave no errors or warnings. (The Comeau online compiler compiles >> code but doesn't link or run it.) (However, if there is some 32-bit / >> 64-bit >> conversion error in the code, and Comeau lives in a 32-bit world, then >> maybe it wouldn't see the problem.) >> >> I've tried to isolate the bug in simpler code, but haven't been able to >> yet. >> I've tried "top down" taking stuff out of the test program. It seems I >> need >> both the xsputn stuff and the while loop with the if statement inside. If >> I >> take too much out, the error goes away. >> >> I've also tried "bottom up" setting up a while loop / if statement, and >> that >> has the same signed / unsigned conversions, and I can't reproduce the >> error that way. (I can get the infinite loop, which is what I believe the >> correct behavior is.) >> >> Any thoughts as to whether this can be reproduced on linux? > > Try ideone.com,
Okay, I gave ideone a try. (On the one hand, it's probably less useful than Comeau, because they're running g++ under the hood (rather than a totally independent compiler); on the other hand, it's more useful, because they actually run your code and give you the output.) On both settings (C++ (gcc-4.3.4), and C++0x (gcc-4.5.1)) the code compiles and run correctly, giving the following output: hello... xsputn: top of loop, pos = 0 Message 1 (with '\n')... xsputn: bottom of loop, pos = 24 xsputn: top of loop, pos = 24 xsputn: bottom of loop, pos = -1 xsputn: before return, n = 25, pos = -1 xsputn: top of loop, pos = 0 Message 2 (with '\n')... xsputn: bottom of loop, pos = 24 xsputn: top of loop, pos = 24 xsputn: bottom of loop, pos = -1 xsputn: before return, n = 25, pos = -1 goodbye! However, this test is probably not very informative, because it appears that ideone is using 32-bit g++. For example, ideone's size_t is 32 bits. > and I would like to urge you to put it up on SO nonetheless. > Specify platform (size of long, size_t), what you think should happen, and > what happens, and just ask for an explanation of he behavior. It's a nice > question IMHO, and chances are you'll get your answer fast. Okay, we'll give the experts a crack at this. I've posted the question to comp.lang.c++, rather than Stack Overflow, but we should be able to find some experts there, as well. > Ruben > > PS: send me a link to the question once posted, so I can fix it up a bit if > necessary and give you an upvote ;) > ... Okay, here's a link: groups.google.com/group/comp.lang.c++/browse_thread/thread/ce2528bce8c29935 (Again, it's comp.lang.c++, rather than Stack Overflow.) Thanks again. K. Frank ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
