This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] *scanf: Allow language-dependent radix character


On Dec 17 17:53, Craig Howland wrote:
> 
> On 12/17/2013 05:49 PM, Corinna Vinschen wrote:
> >On Dec 17 17:32, Craig Howland wrote:
> >>On 12/17/2013 04:54 PM, Corinna Vinschen wrote:
> >>>If you wonder about the (unsigned char) casts, these are necessary
> >>>because the variable 'c' is of type signed int, which breaks the
> >>>comparison for non-ASCII char values without the cast.
> >>>
> >>>The code creating the decpt value at the start of vfwscanf is the same
> >>>code as in vfwprintf.
> >>>
> >>>
> >>>Thanks for any review,
> >>>Corinna
> >>>
> >>>
> >>>	* vfscanf.c (__SVFSCANF_R): Handle radix char language-dependent
> >>>	per POSIX.
> >>>	(__SVFWSCANF_R): Ditto.
> >>>
> >>>
> >>>Index: libc/stdio/vfscanf.c
> >>>===================================================================
> >>>RCS file: /cvs/src/src/newlib/libc/stdio/vfscanf.c,v
> >>>retrieving revision 1.54
> >>>diff -u -p -r1.54 vfscanf.c
> >>>--- libc/stdio/vfscanf.c	29 Apr 2013 21:06:23 -0000	1.54
> >>>+++ libc/stdio/vfscanf.c	17 Dec 2013 21:51:21 -0000
> >>>@@ -162,6 +162,7 @@ Supporting OS subroutines required:
> >>>  #ifdef FLOATING_POINT
> >>>...
> >>>+		      if (decptpos > 0)
> >>>+			{
> >>>+			  /* We read part of a multibyte decimal point,
> >>>+			     but the rest is invalid or we're at EOF,
> >>>+			     so back off. */
> >>>+			  while (decptpos-- > 0)
> >>>+			    {
> >>>+			      _ungetc_r (rptr, decpt[decptpos], fp);
> >>Shouldn't it be (unsigned char) decpt[decptpos] here, too?  (The
> >>same probably goes for the other unget.  Our ungetc directly warns
> >>against giving back a signed char.)
> >Per POSIX, ungetc is supposed to do the cast to unsigned char by itself,
> >and newlib's _ungetc_r does that, so it's safe in this scenario.
> >
> >
> Well, it does later on, but not before a comparison against EOF at
> the start.  Is 0xFF a permitted byte value in multibyte?  (That
> would cause a problem.)

Good point, especially since multibyte includes singlebyte and
doublebyte charsets.  I'll fix that.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgpHv6oraSm7L.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]