Forum: Compiler & IDEs SDCC: warning 158: overflow in implicit constant conversion


von Ralph S. (jjflash)


Lesenswert?

Warum produziert mir der SDCC mit folgendem Code ein

warning 158: overflow in implicit constant conversion

der arm-none-eabi-gcc hingegen nicht ?
1
  #define delay_flag 0x80
2
3
  static const uint8_t  init_seq[] =
4
  {
5
    0x3a, 1 + delay_flag, 0x05,10
6
  }

Mir ist natürlich klar, dass das delay_flag eben keinen Cast auf uint8_t 
hat, aber erklärt das, warum ein Compiler eine Warnung ausgibt, ein 
anderer hingegen nicht.

Außerdem:

Ein:
1
  0x3a, 1 | delay_flag, 0x05,10

bringt die Warnung zum "schweigen", aber irgendwie gefällt mir die 
Darstellung deswegen nicht, weil wie im obigen Beispiel die 1 die Anzahl 
der folgenden Parameter ist und das letzte Byte im Array eine 
Verzoegerungszeit. Das delay_flag sagt hier nur, dass nach Abschluss 
eines Datenframes eine Wartezeit einzuhalten ist. Ich bin der Meinung, 
dass 1 + delay_flag einfach besser lesbar ist (und wie gesagt, der GCC 
bringt diese Warnung nicht).

Würdet ihr die Warnung ignorieren wenn ihr genau wüßtet was damit 
gemeint ist (vor allen Dingen dann, wenn der Code weitergegeben wird) 
oder doch die logische ODER-Verknüpfung verwenden ?

: Verschoben durch User
von leo (Gast)


Lesenswert?

Ralph S. schrieb:
> #define delay_flag 0x80

Hilft
1
#define delay_flag 0x80U

leo

von Ralph S. (jjflash)


Lesenswert?

leo schrieb:
> Hilft#define delay_flag 0x80U
>
> leo

Funktioniert !

Aaaaaber, das erklärt mir noch nicht, warum GCC da keine Warnung 
ausgibt. Ist der GCC einfach nur "schlauer" und "erkennt" was gemeint 
ist ?

von leo (Gast)


Lesenswert?

Ralph S. schrieb:
> Funktioniert !
>
> Aaaaaber, das erklärt mir noch nicht, warum GCC da keine Warnung
> ausgibt. Ist der GCC einfach nur "schlauer" und "erkennt" was gemeint
> ist ?

Super - Ich hab keinen SDCC hier zum Vergleich, aber ich denke mal, dass 
der GCC viel weiter in der Entwicklung ist und das erkennt, ja.

leo

von Dr. Sommer (Gast)


Lesenswert?

Ralph S. schrieb:
> Ist der GCC einfach nur "schlauer" und "erkennt" was gemeint ist ?

Ich  vermute der SDCC verhält sich hier nicht C-Standard Konform. Die 
Integer Literale (0x80 und 1) sollten mit Integer-präzision berechnet 
werden, d.h. mit mindestens 16bit. Dann macht die Warnung aber keinen 
Sinn. Benutzt der SDCC unerlaubterweise int=8bit?

von Ralph S. (jjflash)


Lesenswert?

Dr. Sommer schrieb:
> Benutzt der SDCC unerlaubterweise int=8bit?

Na ja, das delay_flag ist ja in einem uint8_t-Array eingefügt. Ob das so 
"unerlaubt" ist ?!?

Ich habe mich mit Compilerbau schon sehr sehr lange nicht mehr 
beschäftigt.

von Dr. Sommer (Gast)


Lesenswert?

Ralph S. schrieb:
> Na ja, das delay_flag ist ja in einem uint8_t-Array eingefügt. Ob das so
> "unerlaubt" ist ?!?

Wo das Literal dann eingesetzt wird, spielt keine Rolle. Ein Ausdruck 1 
oder 0x80 hat in C erstmal vom Typ "int" zu sein und mindestens 16bit zu 
haben. Vielleicht ist es auch ein Bug in SDCC, denn laut Google benutzt 
SDCC korrekterweise 16bit-Integer.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Der SDCC scheint es mit den Integer-Typen nicht so drauf zu haben.

Beispiele:

1
sizeof (char)       -> 1  richtig
2
sizeof (int)        -> 2  richtig
3
sizeof 0            -> 2  richtig
4
sizeof (0 + 0)      -> 1  falsch
5
sizeof (0xff + 0)   -> 1  falsch
6
sizeof (0xff + 1)   -> 2  richtig
7
sizeof (0 - 0x80)   -> 1  falsch
8
sizeof (0 - 0x81)   -> 2  richtig

Da darf man sich nicht wundern, wenn da mal eine nicht nachvollziehbare
Overflow-Warnung ausgegeben wird.

von Ralph S. (jjflash)


Lesenswert?

na ja, primziiel bin ich froh, dass es den SDCC gibt, weil es meines 
Wissens der einzige Open-Source Compiler für STM8 ist, den es gibt. Ich 
wollte nur wissen, ob ich jetut zu doof bin oder ob das ein Bug ist.

Für obiges Problem werde ich halt in Zukunft nixht mehr 0x80+2 sondern 
0x80 | 2 schreiben.

Es hatte mich halt nur irritiert.

von Philipp Klaus K. (pkk)


Lesenswert?

Ralph S. schrieb:
> Ich
> wollte nur wissen, ob ich jetut zu doof bin oder ob das ein Bug ist.

https://sourceforge.net/p/sdcc/bugs/2733/

von Ralph S. (jjflash)


Lesenswert?

Danke für den Lunk

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.