Hello Kai and Ruben!

On Sat, Nov 5, 2011 at 11:43 AM, Kai Tietz <[email protected]> wrote:
> Errm,  well, this seems not to be my day.  Sure it is promoted to wider 
> scalar.
>
> Small test-program run under Windows 64-bit (using gcc 4.7) shows
>
> #include <stdio.h>
>
> static const size_t npos1 = -1;
> static const size_t npos2 = static_cast<size_t>(-1);
>
> int main ()
> {
>  unsigned int p = ~0U;
>  printf ("npos1 = 0x%I64X\n", npos1);
>  printf ("npos2 = 0x%I64X\n", npos2);
>
>  printf ("(unsigned int) p is 0x%X\n", p);
>  printf ("p == npos1 is %s\n", (p == npos1 ? "true" : "false"));
>  printf ("p == npos2 is %s\n", (p == npos2 ? "true" : "false"));
>  return 0;
> }
>
> as output
>
> $ ./tst.exe
> npos1 = 0xFFFFFFFFFFFFFFFF
> npos2 = 0xFFFFFFFFFFFFFFFF
> (unsigned int) p is 0xFFFFFFFF
> p == npos1 is false
> p == npos2 is false
>
> And this is the expected output.  So maybe a wrong code bug in gcc, indeed.
>
> Kai

With all due respect, I think the issues of how std::string::npos is defined
and how signed / unsigned or narrower / wider conversions are supposed
to work are red herrings.

Depending on those details, the test code should either go into an infinite
loop, or loop a couple of times.

But in any event, if the "top of loop" (line 36):

   printf ("xsputn: top of loop, pos = %d\n", pos);

is executed, then the "bottom of loop" (line 44):

   printf ("xsputn: bottom of loop, pos = %d\n", pos);

should also be executed.  But it's not.  Here's the output of the program:

   C:\>stdout_stream_error
   hello...
   xsputn: top of loop, pos = 0
   Message 1 (with '\n')...
   xsputn: bottom of loop, pos = 24
   xsputn: top of loop, pos = 24
   goodbye!

The second time through the loop, the loop doesn't complete, and line
44 does not get executed.

Something seems wrong with the generated code, regardless of whether
or not we properly understand std::string::npos and the details of integral
conversions.

(I should emphasize that this is not an "issue" for me.  I have my code
working properly.  I'm just trying to point out what seems to be a bug
in the compiler if anybody "upstream" cares.)

Thanks for taking a look at this.


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

Reply via email to