mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum produziert mir der SDCC mit folgendem Code ein

warning 158: overflow in implicit constant conversion

der arm-none-eabi-gcc hingegen nicht ?
  #define delay_flag 0x80

  static const uint8_t  init_seq[] =
  {
    0x3a, 1 + delay_flag, 0x05,10
  }

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:
  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 Moderator
Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph S. schrieb:
> #define delay_flag 0x80

Hilft
#define delay_flag 0x80U

leo

Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht 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 ?

Autor: leo (Gast)
Datum:

Bewertung
1 lesenswert
nicht 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

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Ralph S. (jjflash)
Datum:

Bewertung
-1 lesenswert
nicht 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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht 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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

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

Beispiele:

sizeof (char)       -> 1  richtig
sizeof (int)        -> 2  richtig
sizeof 0            -> 2  richtig
sizeof (0 + 0)      -> 1  falsch
sizeof (0xff + 0)   -> 1  falsch
sizeof (0xff + 1)   -> 2  richtig
sizeof (0 - 0x80)   -> 1  falsch
sizeof (0 - 0x81)   -> 2  richtig

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

Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
1 lesenswert
nicht 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/

Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Lunk

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.