the fix is not as simple as "add mbstate_t to fpos_t"
we need to look at all of the stdio and sfio functions
to determine if/how the underlying sfio is affected
e.g., there are essentially 5 stream types
unassigned
binary byte
binary wide
text byte
text char
with "shalls" on
how the type is affected
how the type affects calls incompatible with the type
how the the application can change the type
also the referenced document is a C 201X *draft*
we get some time to assess the affects on ast
so no, not for the next beta, and probably not for the next official release
On Thu, 28 Apr 2011 11:53:45 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= wrote:
> Glenn, are you going to fix this for the next beta?
> Olga
> 2011/3/22 ÏÌØÇÁ ËÒÙÖÁÎÏ×ÓËÁÑ <[email protected]>:
> > Glenn, have a look at the C1X spec below. Does this mean that AST
> > fpos_t needs a mbstate_t?
> >
> > Olga
> >
> > ---------- Forwarded message ----------
> > From: Takehiko NOZAKI <[email protected]>
> > Date: Mon, Mar 21, 2011 at 7:50 PM
> > Subject: Proposal: fpos_t and funopen(3) API change
> > To: [email protected]
> >
> >
> > hi, all.
> >
> > according to src/lib/libc/shlib_version, following TODO remain before
> > libc major bump:
> >
> > - libc/stdio: make fpos_t larger. see BUGS section in fgetpos(3).
> > probably s/fpos_t/off_t/ in __sFILE and __sseek(). it involves
> > funopen(3) api change.
> >
> > (http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/shlib_version)
> >
> >
> > C1X spec says:
> >
> > 7.21.2.6
> > Each wide-oriented stream has an associated mbstate_t object that
> > stores the current
> > parse state of the stream. A successful call to fgetpos stores a
> > representation of the
> > value of this mbstate_t object as part of the value of the fpos_t
> > object. A later
> > successful call to fsetpos using the same stored fpos_t value restores
> > the value of
> >
> > (http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1539.pdf)
> >
> > so i wrote patch for this
> >
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/tnozaki/patch-fpos_t
> >
> > any comment?
> >
> >
> > very truly yours.
> > --
> > Takehiko NOZAKI <[email protected]>
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
