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

[Corinna Vinschen <vinschen at redhat dot com>]

On Dec 18 10:15, Corinna Vinschen wrote:
> 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.

Btw., this does not affect the other ungetc calls.  A comment in the code
(which I only found a few minutes ago) explicitely states:

  Use of ungetc here and below assumes ASCII encoding; we are only
  pushing back 7-bit characters, so casting to unsigned char is
  not necessary.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgpRyLWEOZYlt.pgp
Description: PGP signature