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


Groups > comp.lang.c > #42320

Re: mbrtoc32 in MinGW-w64 buggy?

From Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups comp.lang.c
Subject Re: mbrtoc32 in MinGW-w64 buggy?
Date 2014-03-29 17:44 -0400
Organization A noiseless patient Spider
Message-ID <lh7er5$tsk$1@dont-email.me> (permalink)
References <lh6diu$c35$1@newsreader4.netcologne.de> <lh6gkd$sq5$1@dont-email.me> <ln8ursk7mf.fsf@nuthaus.mib.org>

Show all headers | View raw


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

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web