«

Bill Bennett wrote:
> "CBFalconer" <> 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 "standard C library" documentation provided with lcc, there is no
> separate description of the format spec for input vs output, so you have to
> guess a bit. But it says "hh means unsigned char or signed char" which would
> lead me to believe that when used in scanf only one byte is stored (assuming
> a char is one byte on the machine you're compiling to).
>
> 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.

Please do not send direct mail when discussions belong in the
newsgroup. Please do not top-post (fixed).

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

Only one byte should have been modified by that sscanf.

CBFalconer <> wrote in message news:<>...
> Bill Bennett wrote:
> > "CBFalconer" <> 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?

In < > (James Kuyper) writes:

>CBFalconer <> wrote in message news:<>...
>> Bill Bennett wrote:
>> > "CBFalconer" <> 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?

The undefined behaviour in the printf calls can explain *anything*,
doesn't it? %x expects unsigned int, while buffer[i] most likely gets
promoted to signed int.

There would have been a lot less traps in the C language if *all* the
shorter unsigned types got promoted to unsigned int. Preserving both
value and signedness makes a lot more sense than preserving value only.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email:

"James Kuyper" <> wrote in message
news: om...
> CBFalconer <> wrote in message
news:<>...
> > Bill Bennett wrote:
> > > "CBFalconer" <> 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.

Bill Bennett wrote:
>
> "James Kuyper" <> wrote in message
> news: om...
> > CBFalconer <> wrote in message
> news:<>...
> > > Bill Bennett wrote:
> > > > "CBFalconer" <> 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.

James Kuyper wrote:
> Bill Bennett wrote:
> > "James Kuyper" <> wrote in message
> > > CBFalconer <> wrote in message
> > > > Bill Bennett wrote:
> > > > > "CBFalconer" <> 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 () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!