Verständnisfrage zu sprintf und der Ausgabe negativer Zahlen

Scherzkeks.  uint8 inst unsigned --> hat Werte von 0...255.

"%d" erwartet einen int; da alle Argumente von varargs mindestens zu int 
promotet werden, wird also 255 (als signed 16 Bit) ausgegeben.

Wenn du -1 haben willst dann mach die Variable signed, z.B. int8_t.

Wobei man einen String wohl am ehesten als

1

char data[260];

deklarieren würde. Faustregel:
-wenn es 8 Bit und kein Vorzeichen haben soll, nimm uint8_t
-wenn es 8 Bit haben und vorzeichenbehaftet sein soll, nimm int8_t
-wenn es ein Zeichen bzw. eine Zeichenkette sein soll, nimm char.

Kevin Maurer schrieb:
> Ich verstehe das nicht. Woran liegt das genau?

An einem kleinen, unscheinbaren Tierchen namens "integer promotion".

sprintf() (und printf()) sind Funktionen mit variabler Argumentliste.

Dort lebt dieses Tierchen und sorgt dafür, daß alles, was diesen 
Funktionen als Parameter übergeben wird und von der Bitgröße her kleiner 
ist als das, was auf der entsprechenden Plattform einem int entspräche, 
automatisch vorzeichenrichtig auf die "int-Größe" erweitert wird.

Aus einem uint8_t 0xff wird also 0x00ff und aus einem int8_t 0xff -> 
0xffff.

Man kann also an sprintf() und seine Kollegen gar keine 8-Bit Typen 
übergeben bzw. sie kommen dort nicht als 8-Bit Typen an.

In der Konsequenz bedeutet das z.B., daß wenn man ein Feld aus int8_t's 
hexadezimal ausgeben möchte, immer eine Feldlänge mit angeben muß, weil 
negative Zahlen sonst vierstellig werden.

Es lohnt sich, mal über integer promotion nachzulesen, weil sie auch 
noch an ein paar anderen Stellen eine Rolle spielt (arithmetische 
Operationen).

Dort bewirkt sie beispielsweise, daß man eine 8 Bit breite Variable ohne 
Warnung um mehr als sieben Bit shiften kann. Die Warnung kommt erst, 
wenn man weiter schiebt, als ein int breit ist.

Der Compiler darf integer promotion wegoptimieren, muß aber dafür 
sorgen, daß das Ergebnis dasselbe bleibt.

Kevin Maurer schrieb:
> Was ich dann aber immer noch nicht so ganz verstehe,

Das "Problem" hat jetzt mit integer promotion nichts mehr zu tun.

Das ist streng genommen erst mal ein Programmierfehler. Mit der 
Deklaration als uint versicherst Du dem Compiler, daß die Zahl nie 
negativ werden kann/soll. Wenn Du sie dann (absichtlich oder 
unabsichtlich) negativ machst, ist das wohl ein Fehler, bzw. es wird 
nicht das rauskommen, was Du erwartest.

-1 als unsigned 16-Bit Zahl ist keine -1 (und auch nicht 255), sondern 
halt 65535. Und das würde auch ausgegeben, wenn Du die Zahl im 
Formatstring - wie's richtig wäre - als unsigned (Format-Specifier = 
"%u") behandeln würdest. Dort behauptest Du aber plötzlich wieder, es 
handle sich um ein signed int (Format-Specifier = "%d"), also wird eben 
-1 ausgegeben.

Bronco schrieb:

> Variable Argumente werden als Liste von ints auf dem Stack abgelegt.

Mit dieser Aussage bin ich nicht wirklich glücklich. In C ist genau 
festgelegt, wie in diesem Fall vorgegangen wird.

> Wenn Du ein uint8_t übergibst, wird dieses in einem int auf dem Stack
> abgelegt. Wenn Du einen String übergibst, wird dessen Adresse als int
> auf dem Stack abgelegt.

Und mit dem letzten Teilsatz ... no. Das kann man so nicht sagen. Das 
ist grob sinnentstellend. Nirgends in C ist festgelegt, das sizeog(int) 
== sizeof(void*) sein muss. Das hier zu einem "wird als int" übergeben, 
ist einfach nur missverständlich.

> Wenn Du einen größeren Datentyp als int
> übergibts, wird dieser in Form von mehreren ints hintereinander auf dem
> Stack abgelegt (wobei man wieder das Endian beachten muß).

Auch das kann man so nicht sagen.


Alles in allem: Verlasse diese Schiene des 'alles wird auf int 
runtergebrochen' wieder. Das ist keine zielführende Sichtweise und 
bestenfalls grob vereinfacht. Es erklärt zb nicht, wie ein float über 
eine variadische Schnittstelle gebracht wird und warum bei einem printf 
das Formatierzeichen "%lf" überflüssig ist.

Bronco schrieb:
> Woher soll jetzt der Compiler beim compilieren wissen, welche Datentypen
> da übergeben werden? Er kann es nicht wissen, daher packet er jeden
> Parameter in ein oder mehrere "int".

Falsch.

Der Compiler weiß auf der Aufruferseite (die bei so gut wie allen ABI's 
auch für's anschließende Aufräumen zuständig ist) sehr genau, welche und 
wieviele Parameter da übergeben wurden, er hat's ja schließlich grade 
eben erst selbst gemacht. Also sollte der Aufrufer auch sehr wohl wissen 
wieviele und welche Parameter er wieder "abräumen" soll - das wird (und 
muss) er sich über den Funktionsaufruf hinweg doch wohl noch merken 
können.

Die aufgerufene Funktion weiß das hingegen nicht und ist darauf 
angewiesen, daß ihr das auf irgendeine Weise (z.B. in einem 
Formatstring) als "nicht variadisches" Argument mitgeteilt wird. Dann 
kann sie über va_arg() die einzelnen Parameter referenzieren. Dabei 
setzt va_start() einen internen Zeiger auf den Anfang der 
Parameterliste, va_arg() holt das nächste Argument und schiebt den 
Zeiger weiter. Wie weit va_arg() den Zeiger jeweils weiterschiebt, ist 
prinzipiell Wurscht, das könnte auch mal (zumindest auf Plattformen, die 
ungerade Stackadressen erlauben) nur 8 Bit weit oder grundsätzlich und 
immer 128 Bit weit sein.

Ein va_end() ist eigentlich nur für die (wenigen) Plattformen notwendig, 
bei denen der Aufgerufene für's Aufräumen zuständig ist.

Die "integer promotion" wäre an dieser Stelle - zumindest bei den 
gängigen ABIs - streng genommen gar nicht notwendig. Ein va_arg(arglist, 
char) z.B. könnte völlig problemlos auch ein char Argument vom Stack 
holen.

Ich nehme an, die C-Erfinder wollten sich Probleme mit unaligned Stacks 
ersparen und sind davon ausgegangen, daß die Parameterübergabe 
unabhängig von der Plattform per "natural type size" (= sizeof(int)) am 
einfachsten und effizientesten zu implementieren ist.

Da ist ja auch was dran...

Markus F. schrieb:
> Wie weit va_arg() den Zeiger jeweils weiterschiebt, ist prinzipiell
> Wurscht, das könnte auch mal (zumindest auf Plattformen, die ungerade
> Stackadressen erlauben) nur 8 Bit weit oder grundsätzlich und immer 128
> Bit weit sein.

Wie im Nachbarthread schon geschrieben, muss es auch gar nicht auf
dem Stack sein: (Ultra-)SPARC beispielsweise benutzt für die ersten
(auch variadischen) Argumente Register.  Irgendwie muss sich va_arg()
auch das dann merken.

Jörg Wunsch schrieb:
> Markus F. schrieb:
> Wie im Nachbarthread schon geschrieben, muss es auch gar nicht auf
> dem Stack sein: (Ultra-)SPARC beispielsweise benutzt für die ersten
> (auch variadischen) Argumente Register.  Irgendwie muss sich va_arg()
> auch das dann merken.

Klar doch. Wenn Du meinen Beitrag genau studiert hast, hast Du sicher 
festgestellt, daß ich das Wort "Stack" bis auf diese eine Stelle 
sorgfältig vermieden habe.

In der wirklichen Welt sind viele (die meisten?) Architekturen aber eben 
nun mal so gestrickt, daß sie Funktionsparameter (zumindest die, die 
eine bestimmte Anzahl überschreiten) auf dem Stack übergeben und bei 
zumindest etlichen davon hat ebender besondere Einschränkungen, was das 
Alignment angeht. Deswegen war's wohl einfacher, parameter promotion für 
Variadische Funktionsparameter zu erzwingen.

Darauf wollte ich hier raus.

Markus F. schrieb:
> Deswegen war's wohl einfacher, parameter promotion für Variadische
> Funktionsparameter zu erzwingen.

Das Ur-C kannte ja keine Prototypen und musste dadurch immer
die promotion benutzen.  Das hat man bei C89 für variadische
Funktionen übernommen.  Ein "Rationale" dafür habe ich nicht im
Netz gesehen, kann mir aber vorstellen, dass es damals besonders
wichtig erschien, dass beide Varianten (Prototyp und "K&R style")
nebeneinander existieren können und binärkompatibel sind.

Hört sich an wie ein vernünftiges Argument ;).

Jörg Wunsch schrieb:
> Das Ur-C kannte ja keine Prototypen und musste dadurch immer
> die promotion benutzen.

Hätte es deswegen nicht unbedingt müssen, hat aber sicher viele 
Programmfehler (bzw. viele hässliche casts) vermieden.

Jörg Wunsch schrieb:
> (Ultra-)SPARC beispielsweise benutzt für die ersten
> (auch variadischen) Argumente Register.

Kann die Register indirekt adressieren?  Ansonsten geben Bedinungen 
ziemlich üblen Code weil man abhängig von argp jedes Register abtesten 
muss:

1

va_list argp;

2

...

3

if (bedingung_1)

4

  var1 = va_arg (argp, typ1);

5

if (bedingung_2)

6

  var2 = va_arg (argp, typ2);

7

...

das ist bei x86_64 übrigens nicht wesentlich anders. va_list ist dann 
eben kein Zeiger, sondern ein struct, der beschreibt wo und wie die 
Argumente zu finden sind.

Johann L. schrieb:
> Kann die Register indirekt adressieren?

Ich glaub' schon, müsste mir die Details aber auch wieder anlesen.

Fand das eine interessante CPU-Architektur, hat sich eben nur leider
nicht durchgesetzt.