Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: mbrtoc32 in MinGW-w64 buggy? |
| Date | 2014-03-31 10:54 -0400 |
| Organization | Self |
| Message-ID | <533981B3.3040705@verizon.net> (permalink) |
| References | <lh6diu$c35$1@newsreader4.netcologne.de> <lh6gkd$sq5$1@dont-email.me> <ln8ursk7mf.fsf@nuthaus.mib.org> <lh7er5$tsk$1@dont-email.me> <lnioqwimxp.fsf@nuthaus.mib.org> |
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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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