HEX-Zahlen mit scanf einlesen

[Da Mo (Gast)]

Warum kann ich mit folgendem "Programm", nicht zwei HEX-Zahlen einlesen?

#include <stdio.h>

int main(void)
{
  unsigned char a, b;

  printf("Erste HEX-Zahl(max. FF): 0x");
  scanf("%x", &a);
  printf("Zweite HEX-Zahl(max. FF): 0x");
  scanf("%x", &b);

  printf("%x, %x",a ,b);

  system("PAUSE");
  return 0;
}

Wenn ich die beiden scanf-Anweisungen vertausche, dann geht es!? Muss 
ich das einfach akzeptieren?

Grüße
Austrianer

[Klaus W. (mfgkw)]

Mit %x wird eine unsigned int gelesen, du hast aber unsigned char.

Dominik M. schrieb:
> Wenn ich die beiden scanf-Anweisungen vertausche, dann geht es!?

Zufall?
a und b mögen stimmen - du überschreibst dafür ein anderes Byte, und 
merkst es nur nicht.

> Muss ich das einfach akzeptieren?

Musst du nicht.
Man muss nur akzeptieren, daß ein falsches Programm nicht richtig läuft. 
:-)

[Da Mo (Gast)]

Kann man keine HEX-Zahl einlesen?

[Klaus W. (mfgkw)]

Doch, natürlich.
Aber nach ANSI-Standard nicht in eine char, sondern in eine unsigned int 
(%x), unsigned long (%lx), unsigned short (%hx).

Beim gcc bzw. bei der glibc und m.W. auch nach C99 geht eine unsigned 
char mit %hhx.

Siehe man 3 printf.

[Klaus W. (mfgkw)]

...
CONFORMING TO
       The  fprintf(), printf(), sprintf(), vprintf(), vfprintf(),
       and vsprintf() func‐
       tions conform to C89 and C99.  The snprintf() and vsnprintf()
       functions  conform
       to C99.

       Concerning  the return value of snprintf(), SUSv2 and C99
       contradict each other:
       when snprintf() is called with  size=0  then  SUSv2
       stipulates  an  unspecified
       return  value  less  than  1,  while C99 allows str to be
       NULL in this case, and
       gives the return value (as always) as the number of
       characters that  would  have
       been written in case the output string has been large enough.

       Linux  libc4  knows  about the five C standard flags.
       It knows about the length
       modifiers h, l, L, and the conversions c, d, e, E, f, F, g,
       G, i, n, o, p, s, u,
       x,  and  X, where F is a synonym for f.  Additionally, it
       accepts D, O, and U as
       synonyms for ld, lo, and lu.  (This is bad, and caused
       serious bugs later,  when
       support for %D disappeared.)  No locale-dependent radix
       character, no thousands’
       separator, no NaN or infinity, no "%m$" and "*m$".

       Linux libc5 knows about the five C standard flags and the
       ' flag, locale,  "%m$"
       and  "*m$".  It knows about the length modifiers h, l, L,
       Z, iand q, but accepts
       L and q both for long double and for long long int
       (this  is  a  bug).   It  no
       longer  recognizes  F,  D,  O, and U, but adds the
       conversion character m, which
       outputs strerror(errno).

       glibc 2.0 adds conversion characters C and S.

       glibc 2.1 adds length modifiers hh, j, t, and  z  and
       conversion  characters  a
       andA.

       glibc 2.2 adds the conversion character F with C99
       semantics, and the flag char‐
       acter I.