Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #42278 > unrolled thread

mbrtoc32 in MinGW-w64 buggy?

Back to article view | Back to comp.lang.c

Contents

  mbrtoc32 in MinGW-w64 buggy? Werner Wenzel <werner.wenzel@netcologne.de> - 2014-03-29 13:16 +0100
    Re: mbrtoc32 in MinGW-w64 buggy? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-29 09:08 -0400
      Re: mbrtoc32 in MinGW-w64 buggy? Werner Wenzel <werner.wenzel@netcologne.de> - 2014-03-29 15:09 +0100
        Re: mbrtoc32 in MinGW-w64 buggy? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-29 10:27 -0400
      Re: mbrtoc32 in MinGW-w64 buggy? Keith Thompson <kst-u@mib.org> - 2014-03-29 14:38 -0700
        Re: mbrtoc32 in MinGW-w64 buggy? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-29 17:44 -0400
          Re: mbrtoc32 in MinGW-w64 buggy? Keith Thompson <kst-u@mib.org> - 2014-03-29 16:50 -0700
            Re: mbrtoc32 in MinGW-w64 buggy? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 10:54 -0400
    Re: mbrtoc32 in MinGW-w64 buggy? James Kuyper <jameskuyper@verizon.net> - 2014-03-29 09:17 -0400

#42278 — mbrtoc32 in MinGW-w64 buggy?

Running the following MinGW-w64-built code on Windows 7 64 bit crashes 
with me:

#include <stdio.h>
#include <uchar.h>

int main(void)
{
	mbstate_t mbstate;
	
	puts("So far okay ...");
	mbrtoc32(NULL, "", 1, &mbstate);
	puts("Not reached due to crash!");
	return 0;
}

It should not crash as the problematic line derives from ISO C11 (N1570) 
7.28.1.3p2.

As far as I can see this issue is caused by 
\mingw-builds\sources\mingw-w64-v3.1.0\mingw-w64-crt\misc\uchar_mbrtoc32.c, 
line 32, which--in this special case--dereferences NULL.

Is this thought correct or am I missing something?

Werner

[toc] | [next] | [standalone]

#42285

On 3/29/2014 8:16 AM, Werner Wenzel wrote:
> Running the following MinGW-w64-built code on Windows 7 64 bit crashes
> with me:
>
> #include <stdio.h>
> #include <uchar.h>
>
> int main(void)
> {
>      mbstate_t mbstate;
>
>      puts("So far okay ...");
>      mbrtoc32(NULL, "", 1, &mbstate);
>      puts("Not reached due to crash!");
>      return 0;
> }
>
> It should not crash as the problematic line derives from ISO C11 (N1570)
> 7.28.1.3p2.
>
> As far as I can see this issue is caused by
> \mingw-builds\sources\mingw-w64-v3.1.0\mingw-w64-crt\misc\uchar_mbrtoc32.c,
> line 32, which--in this special case--dereferences NULL.
>
> Is this thought correct or am I missing something?

     I am no expert on wide-character utilities and I have not looked
at the source code, but it looks to me like the `mbstate' variable
has never been initialized, and so may "contain garbage."  What
happens if you use `mbstate_t mbstate = { 0 };' instead?

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#42289

Am 29.03.2014 14:08, schrieb Eric Sosman:
> On 3/29/2014 8:16 AM, Werner Wenzel wrote:
>> Running the following MinGW-w64-built code on Windows 7 64 bit crashes
>> with me:
>>
>> #include <stdio.h>
>> #include <uchar.h>
>>
>> int main(void)
>> {
>>      mbstate_t mbstate;
>>
>>      puts("So far okay ...");
>>      mbrtoc32(NULL, "", 1, &mbstate);
>>      puts("Not reached due to crash!");
>>      return 0;
>> }
>>
>> It should not crash as the problematic line derives from ISO C11 (N1570)
>> 7.28.1.3p2.
>>
>> As far as I can see this issue is caused by
>> \mingw-builds\sources\mingw-w64-v3.1.0\mingw-w64-crt\misc\uchar_mbrtoc32.c,
>>
>> line 32, which--in this special case--dereferences NULL.
>>
>> Is this thought correct or am I missing something?
>
>      I am no expert on wide-character utilities and I have not looked
> at the source code, but it looks to me like the `mbstate' variable
> has never been initialized, and so may "contain garbage."  What
> happens if you use `mbstate_t mbstate = { 0 };' instead?
>

Actually, it still crashes with "mbstate_t mbstate = { 0 };".

The cited MinGW-w64 code reads as follows:

size_t mbrtoc32 (char32_t *__restrict__ pc32,
		 const char *__restrict__ s,
		 size_t n,
		 mbstate_t *__restrict__ __UNUSED_PARAM(ps))
{
     if (*s == 0)
     {
	*pc32 = 0;
	return 0;
     }
...

In this special case the empty string (2nd argument) triggers an 
assignment of 0 to where pc32 points to and pc32 points nowhere.

In my opinion the arguable code should read:

if (pc32) *pc32 = 0;

Werner

[toc] | [prev] | [next] | [standalone]

#42291

On 3/29/2014 10:09 AM, Werner Wenzel wrote:
> Am 29.03.2014 14:08, schrieb Eric Sosman:
>> On 3/29/2014 8:16 AM, Werner Wenzel wrote:
>>> Running the following MinGW-w64-built code on Windows 7 64 bit crashes
>>> with me:
>>>
>>> #include <stdio.h>
>>> #include <uchar.h>
>>>
>>> int main(void)
>>> {
>>>      mbstate_t mbstate;
>>>
>>>      puts("So far okay ...");
>>>      mbrtoc32(NULL, "", 1, &mbstate);
>>>      puts("Not reached due to crash!");
>>>      return 0;
>>> }
>>>
>>> It should not crash as the problematic line derives from ISO C11 (N1570)
>>> 7.28.1.3p2.
>>>
>>> As far as I can see this issue is caused by
>>> \mingw-builds\sources\mingw-w64-v3.1.0\mingw-w64-crt\misc\uchar_mbrtoc32.c,
>>>
>>>
>>> line 32, which--in this special case--dereferences NULL.
>>>
>>> Is this thought correct or am I missing something?
>>
>>      I am no expert on wide-character utilities and I have not looked
>> at the source code, but it looks to me like the `mbstate' variable
>> has never been initialized, and so may "contain garbage."  What
>> happens if you use `mbstate_t mbstate = { 0 };' instead?
>>
>
> Actually, it still crashes with "mbstate_t mbstate = { 0 };".
>
> The cited MinGW-w64 code reads as follows:
>
> size_t mbrtoc32 (char32_t *__restrict__ pc32,
>           const char *__restrict__ s,
>           size_t n,
>           mbstate_t *__restrict__ __UNUSED_PARAM(ps))
> {
>      if (*s == 0)
>      {
>      *pc32 = 0;
>      return 0;
>      }
> ...
>
> In this special case the empty string (2nd argument) triggers an
> assignment of 0 to where pc32 points to and pc32 points nowhere.
>
> In my opinion the arguable code should read:
>
> if (pc32) *pc32 = 0;

     That looks to me like a bug; you might want to report it
to the Mingols.

     It also seems to me your original code had a bug, which
didn't happen to make a difference with this implementation
of mbrtoc32() but might have made trouble with others.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#42318

Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 3/29/2014 8:16 AM, Werner Wenzel wrote:
>> Running the following MinGW-w64-built code on Windows 7 64 bit crashes
>> with me:
>>
>> #include <stdio.h>
>> #include <uchar.h>
>>
>> int main(void)
>> {
>>      mbstate_t mbstate;
>>
>>      puts("So far okay ...");
>>      mbrtoc32(NULL, "", 1, &mbstate);
>>      puts("Not reached due to crash!");
>>      return 0;
>> }
>>
>> It should not crash as the problematic line derives from ISO C11 (N1570)
>> 7.28.1.3p2.
>>
>> As far as I can see this issue is caused by
>> \mingw-builds\sources\mingw-w64-v3.1.0\mingw-w64-crt\misc\uchar_mbrtoc32.c,
>> line 32, which--in this special case--dereferences NULL.
>>
>> Is this thought correct or am I missing something?
>
>      I am no expert on wide-character utilities and I have not looked
> at the source code, but it looks to me like the `mbstate' variable
> has never been initialized, and so may "contain garbage."  What
> happens if you use `mbstate_t mbstate = { 0 };' instead?

mbstate is not initialized prior to the call, but that's not a problem.
Its address, not its value, is passed to mbrtoc32(), which updates
the pointed-to object.

N1570 7.28.1:

    These functions have a parameter, ps, of type pointer to mbstate_t
    that points to an object that can completely describe the current
    conversion state of the associated multibyte character sequence,
    which the functions alter as necessary.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#42320

On 3/29/2014 5:38 PM, Keith Thompson wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>> On 3/29/2014 8:16 AM, Werner Wenzel wrote:
>>> Running the following MinGW-w64-built code on Windows 7 64 bit crashes
>>> with me:
>>>
>>> #include <stdio.h>
>>> #include <uchar.h>
>>>
>>> int main(void)
>>> {
>>>       mbstate_t mbstate;
>>>
>>>       puts("So far okay ...");
>>>       mbrtoc32(NULL, "", 1, &mbstate);
>>>       puts("Not reached due to crash!");
>>>       return 0;
>>> }
>>>
>>> It should not crash as the problematic line derives from ISO C11 (N1570)
>>> 7.28.1.3p2.
>>>
>>> As far as I can see this issue is caused by
>>> \mingw-builds\sources\mingw-w64-v3.1.0\mingw-w64-crt\misc\uchar_mbrtoc32.c,
>>> line 32, which--in this special case--dereferences NULL.
>>>
>>> Is this thought correct or am I missing something?
>>
>>       I am no expert on wide-character utilities and I have not looked
>> at the source code, but it looks to me like the `mbstate' variable
>> has never been initialized, and so may "contain garbage."  What
>> happens if you use `mbstate_t mbstate = { 0 };' instead?
>
> mbstate is not initialized prior to the call, but that's not a problem.
> Its address, not its value, is passed to mbrtoc32(), which updates
> the pointed-to object.
>
> N1570 7.28.1:
>
>      These functions have a parameter, ps, of type pointer to mbstate_t
>      that points to an object that can completely describe the current
>      conversion state of the associated multibyte character sequence,
>      which the functions alter as necessary.

     Yabbut...  I understand this to mean that the pointed-to
mbstate_t object is both an output *and* an input to the function.
What would be the point of having one call report the state, and
then having the next ignore state changes encountered by the first?

     (Still, as I said before: "I am no expert.")

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#42337

Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 3/29/2014 5:38 PM, Keith Thompson wrote:
[...]
>> mbstate is not initialized prior to the call, but that's not a problem.
>> Its address, not its value, is passed to mbrtoc32(), which updates
>> the pointed-to object.
>>
>> N1570 7.28.1:
>>
>>      These functions have a parameter, ps, of type pointer to mbstate_t
>>      that points to an object that can completely describe the current
>>      conversion state of the associated multibyte character sequence,
>>      which the functions alter as necessary.
>
>      Yabbut...  I understand this to mean that the pointed-to
> mbstate_t object is both an output *and* an input to the function.
> What would be the point of having one call report the state, and
> then having the next ignore state changes encountered by the first?
>
>      (Still, as I said before: "I am no expert.")

I don't see anything in the quoted text that implies that the functions
read the value of the pointed-to mbstate_t object.

Still, you make a good point.  I guess I've got some reading to do.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#42399

On 03/29/2014 07:50 PM, Keith Thompson wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>> On 3/29/2014 5:38 PM, Keith Thompson wrote:
...
>>> N1570 7.28.1:
>>>
>>>      These functions have a parameter, ps, of type pointer to mbstate_t
>>>      that points to an object that can completely describe the current
>>>      conversion state of the associated multibyte character sequence,
>>>      which the functions alter as necessary.
>>
>>      Yabbut...  I understand this to mean that the pointed-to
>> mbstate_t object is both an output *and* an input to the function.
>> What would be the point of having one call report the state, and
>> then having the next ignore state changes encountered by the first?
>>
>>      (Still, as I said before: "I am no expert.")
> 
> I don't see anything in the quoted text that implies that the functions
> read the value of the pointed-to mbstate_t object.

"... can completely describe the current conversion state ... the
functions alter as necessary."
To me that at least suggests that the mbstate_t object should start out
correctly describing the current conversion state at the time the
function is called, even though it doesn't explicitly say so.

[toc] | [prev] | [next] | [standalone]

#42286

On 03/29/2014 08:16 AM, Werner Wenzel wrote:
> Running the following MinGW-w64-built code on Windows 7 64 bit crashes 
> with me:
> 
> #include <stdio.h>
> #include <uchar.h>
> 
> int main(void)
> {
> 	mbstate_t mbstate;
> 	
> 	puts("So far okay ...");
> 	mbrtoc32(NULL, "", 1, &mbstate);
> 	puts("Not reached due to crash!");
> 	return 0;
> }
> 
> It should not crash as the problematic line derives from ISO C11 (N1570) 
> 7.28.1.3p2.

I suspect that the problem is that your mbstate object is uninitialized.
mbstate_t objects can be zero-initialized, and zero is the only value
that the standard guarantees that they can be initialized with, so I'd
recommend using that. 7.28.1.3p2 doesn't address how the object pointed
at by ps was initialized.
-- 
James Kuyper

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web