Re: bug in mbrtowc?

View: New views
2 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: bug in mbrtowc?

by Dave Korn-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Corinna Vinschen wrote:
>
> That's a bug in the newlib function __utf8_mbtowc.  I'm really surprised
> that this bug has never been reported before since it's in the code for
> years, probably since it has been introduced in 2002.

  I'm not terribly surprised.  How much use for i18n is there in the typical
embedded microcontroller?  We're probably the first project to really use this
code in anger(*); cf. also how we still shake out the odd longstanding
floating point bug in newlib, another area that is significantly less-used in
tiny embedded apps than on desktop workstations.


    cheers,
      DaveK
--
(*) - Yes, I know about newlib-based linux.  I don't suppose anyone logging
into a single board embedded linux dev kit bothers to set their LC_ALL either!

Re: bug in mbrtowc?

by Corinna Vinschen-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Jul 28 11:37, Dave Korn wrote:
> Corinna Vinschen wrote:
> >
> > That's a bug in the newlib function __utf8_mbtowc.  I'm really surprised
> > that this bug has never been reported before since it's in the code for
> > years, probably since it has been introduced in 2002.
>
>   I'm not terribly surprised.  How much use for i18n is there in the typical
> embedded microcontroller?  We're probably the first project to really use this
> code in anger(*);

After having sent my mail I started to wonder as well.  Unicode and
wide-char support in a 64K RAM board sounds like waste.  I had expected
that RTEMS is using this a bit more, though.

>  cf. also how we still shake out the odd longstanding
> floating point bug in newlib, another area that is significantly less-used in
> tiny embedded apps than on desktop workstations.

plus the entirely missing area of long double support.


Corinna