Re: error in hh length modifier when used with sscanf

James Kuyper wrote:
> Bill Bennett wrote:
> > "James Kuyper" <[EMAIL PROTECTED]> wrote in message
> > > CBFalconer <[EMAIL PROTECTED]> wrote in message
> > > > Bill Bennett wrote:
> > > > > "CBFalconer" <[EMAIL PROTECTED]> wrote in message
> > > > > > Bill Bennett wrote:
> > > > > > >
> > > > > > > unsigned char buffer[] = "$$$$$$$$";
> > > > > > > for (int i=0; i<8; i++) printf("%6x ", buffer[i]); printf("\n");
> > > > > > > sscanf("55", "%hhx", buffer+2);
> > > > > > > for (int i=0; i<8; i++) printf("%6x ", buffer[i]); printf("\n");
> > > > > > >
> > > > > > > I expect
> > > > > > >     24     24     24     24     24     24     24     24
> > > > > > >     24     24     55     24     24     24     24     24
> > > > > > > but I get
> > > > > > >     24     24     24     24     24     24     24     24
> > > > > > >     24     24     55       0       0       0     24     24
> > > > > > >
> > > > > > > In other words, I expected one byte to be stored but instead 4
> > > > > > > are stored, trampling adjacent bytes.
> > > > > > >
> > > > > > > Using %hx instead of %hhx has the correct result, only 2 bytes
> > > > > > > are stored.
> > > > > > >
> > > > > > > Seems like an error in how the hh is handled, right?
> > > > > >
> > > > > > WRONG.  You got what you asked for.  Look up the meaning of hh in
> > > > > > C99 (it is new since C90).  You are lucky you didn't get some sort
> > > > > > of bus alignment violation, so it would appear you are using
> > > > > > something x86 based, with sizeof(int) == 4 and sizeof(short) == 2
> > > > > > that stores integers low byte first.
> > > ...
> > > > > In the ISO/IEC 9899 C spec it says specifically for fscanf:
> > > > >
> > > > > hh   Specifies that a following d , i , o , u , x , X , or n
> > > > > conversion specifier applies to an argument with type pointer
> > > > > to signed char or unsigned char.
> > > >
> > > > There appears to be a conflict here between N869 and the summaries
> > > > on <http://www.dinkumware.com>.  This may be an error in N869 that
> > > > has been revised in the actual standard.  The proper place to
> > > > thrash this out is on comp.lang.c and comp.std.c.  followups and
> > > > cross-posts set.
> > >
> > > As far as I can see, both n869.pdf and the final standard say the
> > > same thing, that "%hhx" is for reading in a single unsigned char in
> > > hexadecimal format. How are you reading them to allow four bytes to
> > > get trashed?
> >
> > Re: How are you reading them to allow four bytes to get trashed?
> >
> > The exact example that shows the problem is near the top of this
> > thread, and of this post.
> 
> Yes, I've seen that example of legal code that is producing results
> that seem to be inconsistent with the requirements for C99. I've also
> read responses which implied that there is some way to read n896 so
> that it allows such behavior. I'm asking for an explanation of that
> way of reading it. As far as I can see, the quoted text from n869
> matches the text from C99 that mandates different behavior. Of
> course, there's the problem that, technically, it uses the wrong
> format code for the printf()'s, but I doubt that correcting that
> error would change the puzzelling results.

I have deliberately not snipped anything from this discussion.  I
agree than the standard and N869 seem to dictate a read into a
single byte with the hhx specifier.  I would hope to see someone
from dinkumware weigh in here, as my earliest reply was based on
their summary of the C99 meaning.

-- 
Chuck F ([EMAIL PROTECTED]) ([EMAIL PROTECTED])
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!