SDCC: warning 158: overflow in implicit constant conversion

OP #5842495
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 ?
Gast #5842554
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
Gast #5842557
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?
Gast #5842584
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.
Moderator #5842731
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.
OP #5846039
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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren