Warning: overflow in implicit constant conversion [-Woverflow]

Ich nehme an, buf[] hat einen 8-Bit-Datentyp (uint8_t oder dergleichen).
Da stellt sich die Frage, was du mit der Anweisung überhaupt bezwecken
möchtest, denn sie ist äquivalent zu

1

buf[4] = 0;

Ansonsten sehe ich in dem Code kein Problem, denn das Ergebnis ist nach
Standard genau definiert. Du kannst die Warnung dadurch unterdrücken,
dass du 0xff durch 0xffu ersetzt.

Der Compiler scheint eine etwas seltsame Logik zu verfolgen, wann er
diese Warnung ausgibt und wann nicht:

1

  uint8_t u8;

2

3

  u8 &= 0x000; // keine Warnung

4

  u8 &= 0x0ff; // keine Warnung

5

  u8 &= 0x100; // Warnung

6

  u8 &= 0x101; // keine Warnung

7

  u8 &= 0x1ff; // keine Warnung

8

  u8 &= 0x200; // Warnung

Die Warnung scheint also immer dann ausgegeben zu werden, wenn der
rechte Operand nicht in 8 Bit darstellbar ist und zugleich die untersten
8 Bit alle 0 sind. Ich vermute, dass der Compiler erst nachschaut, ob
der Ausdruck optimiert werden kann (unterste 8 Bit alle 0) und danach
(in zwei verschiedenen Programmzweigen) den Überlauf prüft. Diese
Überlaufprüfung erfolgt in den zwei Programmzweigen wohl auf
unterschiedliche Weise.

Thorsten schrieb:
> Buf ist ein Array aus Bytes bzw ein Zeiger auf das Array.

Damit stellt sich allerdings in der Tat die Frage, was dein Code
bezweckt.  Den könntest du deutlich verständlicher schreiben:

1

buf[4] = 0;

Wie geschrieben: wenn die Elemente von buf[] nur Bytes sind, dann
ist der Effekt von „buf[x] &= ~0xff“ eine verklausulierte Form,
statt gleich „buf[x] = 0“ zu schreiben: 0xFF bitweise negiert
(Operator „~“) ist nun einmal 0x00, und Null bleibt Null, egal wie
oft man sie (oder gar nicht) dann noch nach links schiebt.  Ein
Byte, verUNDet mit lauter Bits, die 0 sind, bekommt folglich den
Wert 0.

Wenn die Elemente von buf[] natürlich jemals größer als ein Byte sein
können, sieht die Sache anders aus.

Jörg, der Code ist von einem Awk-Skript generiert worden und kopiert
irgendwelche Werte an beliebige Bitpositionen innerhalb eines
Byte-Puffers. Ist die Bitposition ein Vielfaches von 8, kommen eben
solche – für das menschliche Auge seltsam anmutende – Konstrukte heraus.

Yalu X. schrieb:
> Ist die Bitposition ein Vielfaches von 8, kommen eben
> solche – für das menschliche Auge seltsam anmutende – Konstrukte heraus.

Wobei die Frage wäre, ob der Script diese Situation nicht erkennen
könnte und dann das Löschen der Bits durch Nullsetzen ersetzen kann
(besser: gleich das nächste ODER durch eine Zuweisung ersetzen).

Ich finde im Script aber nichts, was dieses ~(XX << Y) produzieren
würde.

Jörg W. schrieb:
> 0xFF bitweise negiert
> (Operator „~“) ist nun einmal 0x00,

Nein, 0xff ist eine Konstante vom Type int und ist bitwise negiert nicht 
0 sondern je nachdem wie groß int ist 0xffffff00 (32 bit ints) oder 
0xff00 (16 bits ints). Auf dem XMC Dave dürfte es 0xffffff00 sein (wegen 
Cortex MCU).

Die problematische Zeile ist also äquivalent zu:

buf[4] &= (int)0xffffff00;

Jörg W. schrieb:
> Wobei die Frage wäre, ob der Script diese Situation nicht erkennen
> könnte und dann das Löschen der Bits durch Nullsetzen ersetzen kann
> (besser: gleich das nächste ODER durch eine Zuweisung ersetzen).

Naja, wenn sich der Skriptschreiber sicher ist, dass der Compiler das
optimiert (der GCC zumindest tut das), kann er sich selber auf die faule
Haut legen ;-)

> Ich finde im Script aber nichts, was dieses ~(XX << Y) produzieren
> würde.

Es ist das Skript dbc2.awk in Verbindung mit dem Template
sig_setbuf.tpl, das in das Skript eingebunden wird.

Luther B. schrieb:
> Nein, 0xff ist eine Konstante vom Type int und ist bitwise negiert nicht
> 0

Du hast meine Vorbedingung weggelassen: „wenn buf[N] ein Byte ist“.

Allerdings scheint es in diesen Makros stets nur um Bytefolgen zu
gehen.

Sicherer wäre es natürlich, inline-Funktionen zu zimmern, die genau
diese Randbedingung dann explizit festhalten können.  Ein Makro kann
das nicht, weil seine Argumente nicht typisiert werden können.