Datentypen C zu GCC

ja bei unsigned long solltest du auch UL dranhängen, ist ja C.
uint8_t ist wirklich 8 bit breit. unsigned char ist architekturabhängig, 
meistens 8bit, muss aber nicht

> ich habe zwei kleine Fragen, worin sich C und GCC womöglich
> unterscheiden.

Wo drin unterscheiden sich denn Hammer und Werkzeug?

user schrieb:
> ja bei unsigned long solltest du auch UL dranhängen, ist ja C.

angenommen ich verwende uint32_t als Datentyp. Muss ich dennoch dann UL 
anhängen oder ist das durch diese Definition hinfällig?

Bei einer einfachen Zuweisung ists eh wurscht. Für die Konstante nimmt 
der Compiler einen Datentyp, in dem er die jeweilige Konstante 
darstellen kann, und vor der Zuweisung in die Variable wird (implizit) 
in deren Typ gecastet werden.

Einen Unterschied macht das "UL" eigentlich nur, wenn man rechnet, wie

1

unsigned long dings = 10 * 30000; // gibt nicht (!) 300000

Mein letztes Beispiel bezieht sich natürlich auf (uC-) Plattformen, auf 
denen ein int 16 Bit hat.

> angenommen ich verwende uint32_t als Datentyp. Muss ich dennoch dann UL
> anhängen oder ist das durch diese Definition hinfällig?

Für die Typen aus stdint.h gibt es Makros, die das gleiche tun wie ein 
UL
für unsigned long. Für uint32_t könntest du schreiben:

1

uint32_t  beispiel = UINT32_C(1000000);

Sind Hex-Zahlen-Konstanten immer erstmal unsigned?

Wer hat sich das nur ausgedacht... ;)

Jörg Wunsch schrieb:
> Und um die Verwirrung weiter zu treiben: 0x9c40 ist zwar zahlenmäßig
> der gleiche Wert wie 40000, ist aber auch auf einer Plattform mit
> 16-bit-"int" vom Typ "unsigned int".

Lustig wird's aber erst bei -0x9c40. Das ist nämlich auch vom Typ 
unsigned int. Wenn man dann schreibt:

1

long x = -0x9c40;

dann steht da nachher nicht etwa -40000 in x.

Karl heinz Buchegger schrieb:
> und sind Spätfolgen aufgetreten :-)

Ja, zum Beispiel gerade eben in diesem Forum ;-)