int8_t als uint8_t interpretieren

Chris Feller wrote:
> Danke schon mal, leider hats nix gebracht.
>
> @Peter: ich will an der Stelle doch auf kleiner 0 prüfen, daher brauch
> ich hier die signed Version.
>
> @holger: da hilft der Cast leider nicht weiter ...
>
> Trotzdem Danke für Mühe und Denkanstöße!

Wenn du statt u_variable[i] anders *(u_variable + i) schreibst meckern 
viele Compiler nicht  mehr... Ist aber eher unsauber.

Wenn du das öfter hin und her casten musst, kannst du dir unions 
ansehen.

Chris Feller wrote:
> @Peter: ich will an der Stelle doch auf kleiner 0 prüfen, daher brauch
> ich hier die signed Version.

Beim signed gilt: Variable ist < 0, wenn das höchstwertige Bit = 1 ist.

Ich kann mir nicht helfen.
Die Fehlermeldung passt einfach nicht zur gezeigten Codestelle.
Bist du sicher, dass dir der Compiler diese Zeile anmerkt?

(Ist keine Schande, ist mir auch schon passiert, dass ich an der 
falschen Stelle nachgesehen habe)

Hmm... wrote:
> Wieso denn? Wenn frameBuffer aus 'unsigned'-Elementen besteht so sind
> diese niemals kleiner Null bzw. negativ und der Ausdruck liefert
> entsprechend immer falsch.

Der Ausdruck besteht aber nicht aus 'unsigned' Elementen, sondern aus 
int8_t.
Was für GCC verwendet Ihr denn?

Mein arm-none-eabi-gcc.exe (Sourcery G++ Lite 2008q3-66) 4.3.2 gibt mir 
keine Fehlermeldung. Auch "ARM C/C++ Compiler, RVCT4.0 [Build 471]" und 
"RVCT3.1 [Build 942]" (aus Keil MDK) bersetzen das korrekt und ohne zu 
meckern.

Gruß
Marcus
http://www.doulos.com/arm/

Chris Feller wrote:

> Ich denke das genügt mir schon. Allerdings ist mir das eigentliche
> Problem dahinter immer noch unklar.

Da bist du nicht alleine.
Kannst du mal den kompletten Source Code posten + Originale 
Fehlermeldung (incl Zeilennummer)

Die Fehlermeldung passt überhaupt nicht zu dem Code-Ausschnitt den du 
gezeigt hast. Es sei denn irgendjemand hat sich einen Spass gemacht und 
ein

#define int8_t unsigned char

davor gesetzt (oder einen gleichwertigen typedef). Dann gehört er aber 
mit dem nassen Fetzen erschlagen :-)

Wenn andere Leute mit dem Problem umgehen sollen, dann muss es 
reproduzierbar sein. D.h. du solltest eine Minimalversion zurecht 
basteln, die genau das von dir als falsch angesehene Verhalten 
produziert, nichts überflüssiges enthält und so wie geliefert 
kompilierbar ist.

Nicht kompilierbarer Quellcode nützt praktisch nichts. Denn wenn bei 
signed char dies hier wirklich so zusammengehört

1

char * frameBuffer = ...;

2

if (frameBuffer[i] < 0)

3

// -> *warning: comparison is always false due to limited range of data type*

und char nicht zufällig auf "unsigned" gesetzt ist (z.B. mit 
-funsigned-char) dann handelt es sich um einen Compilerfehler, und um 
damit umgehen zu können wird ohnehin ein minimaler Testfall benötigt. 
Mit 100KB Quellcode und 30 Quellfiles fängt niemand etwas an.

Die exakte Version des Compilers wird auch benötigt.

Sven Pauli wrote:

> Guck mal nach der Definition von 'uint8_t' -- wenn die nur 'char' ist,
> dann ist sie kaputt (müsste 'signed char' sein).

uint8_t als "signed char"???

Chris Feller wrote:

>   unsignedFrameBuffer[0] = 255;
>   unsignedFrameBuffer[1] = 10;
>   frameBuffer[2] = -1;
>   frameBuffer[3] = -10;

> signed: 1    unsigned: 1
> signed: 10   unsigned: 10
> signed: -1   unsigned: 255
> signed: -10  unsigned: 246

Du bist ganz sicher, dass hier Code und Ausgabe zusammen gehören?  Denn 
255 ist weder signed noch unsigned gleich 1.

Chris Feller wrote:

>

1

// Auszug aus types.h die verwendet wird

2

> typedef char                  int8_t;

3

> typedef unsigned char         uint8_t;

4

>

Ah, da haben wir ihn ja.
Offenbar ist bei deinem Compiler der default für char ein unsigned char.
Ob du das jetzt über Commandline Switsches erzwungen hast oder nicht, 
spielt erst mal keine Rolle.

Du solltest einen Bug Report an den Entwickler dieses Compilers (oder 
wer auch immer das types.h wartet) schicken.

1

typedef signed char    int8_t;

Sven Pauli wrote:
>> uint8_t als "signed char"???
>
> Ja.
Wirklich? Warum heißt der wohl *u*int8_t?

A. K. wrote:
> Karl heinz Buchegger wrote:
>
>> Offenbar ist bei deinem Compiler der default für char ein unsigned char.
>
> Dann müssten aber bei dem obigen printf() immer nur positive Zahlen
> rauskommen, denn dann würde der Compiler die Parameter immer auf int
> 0-255 erweitern. Etwas wie das gezeigte "signed: -1 unsigned: 255" wäre
> dann nicht möglich.

Was weiß ich, vielleicht hat er ja im Makefile seines Projekts die 
unsigned char Forcierung drinnen. (Habs auch grade erst gesehen. Dieses 
Beispiel stammt von einem anderen Compiler)

Aber für sein ursprüngliches Posting, mit der Fehlermeldung UND dem 
Wissen dass in types.h  ein int8_t als plain vanilla char definiert ist, 
gibt es nur eine Schlussfolgerung:
Irgendjemand zwingt den Compiler einen char als unsigned aufzufassen.
Wie und wodurch, kann ich nicht sagen. Da müsste man jetzt die komplette 
Toolchain durchforsten.

Aber wie auch immer:
In types.h hat ein typedef für int8_t der auf plain vanilla char aufbaut 
ganz sicher nichts verloren.

Sven Pauli wrote:
> :-) Wollte sagen: Hauptsache da steht explizit was vor dem 'char',
> dadrauf kommts an...
Ach so, verstehe...;-)

Chris Feller wrote:
>

1

> typedef char                  int8_t;

2

>

Warum machst Du da nicht einfach ein signed char draus, wie es oben 
schon beschrieben wurde? Nochmal: char ist nicht eindeutig signed oder 
unsigned ("implementation defined"). Wenn Du einen vorzeichenbehafteten 
Wert haben möchtest, dann musst Du, um von irgendwelchen anderen 
Einstellungen unabhängig zu sein, explizit signed da hinschreiben.

Und wenn das sowieso ein GCC ist, warum benutzt Du dann nich die 
stdint.h, in der die Typen alle schön sauber definiert sind? Eigene 
Typen zu definieren (die dann auch noch die selben Namen haben wie die 
Bibliothekstypen) ist Unsinn.