NOT-Operator mit unsigned ints

RyoShinzo

Hallo,

ich möchte folgenden Code ausführen:

unsigned short VarA = ...;
unsigned short VarB = ...;

VarA &= ~VarB;

Mein Problem ist nun, dass VarB in ein signed short gewandelt wird. Deswegen bekomme ich eine Warnung, da der neue signed-Wert in einer unsigned-Variable gespeichert werden soll.

Gibt es eine Möglichkeit, eine NOT-Operation auszuführen, die die Variable nicht von unsigned in signed ändert?

Gruß

Ryo

MFK

Gib mal den genauen Wortlaut der Warnung, nicht deine Interpretation.

RyoShinzo

An integer expression with a value that is definitely negative is being converted to an unsigned type.

Das Analyse-Tool weiß, dass es ein negativer Wert ist, da folgende if-Bedingung vor der eigentlichen Code-Zeile kommt:

if ( 0x0001 == VarB )
{
  VarA &= ~VarB;
}

volkard

RyoShinzo schrieb:

An integer expression with a value that is definitely negative is being converted to an unsigned type.

Das Analyse-Tool weiß, dass es ein negativer Wert ist, da folgende if-Bedingung vor der eigentlichen Code-Zeile kommt:
if ( 0x0001 == VarB )
{
  VarA &= ~VarB;
}

Ach, ein Analysetool.
Dachte, es sei was Ernsthaftes.
Die Tools bringen eigentlich nur Ungemach.

if ( 0x0001 == VarB )
{
  VarA &= (unsigned)~VarB;//so?
}

RyoShinzo

Nein, der cast hilft leider auch nicht. Ich habe auch schon folgendes probiert:

VarA = (uint16)(VarA & (~VarB));

Das führt dann allerdings zu einer anderen Meldung:

Bitwise operations on signed data will give implementation defined results.

volkard

Lass uns mal bei VarA und VarB bleiben.
Hab Null Bock, bei Xzy_KraTxReqPendFlags alle Zeichen zu vergleichen mit dem anderen Bezeichner.
Kannst ja kaum ernsthaft

VarA=VarA&~Vara

geschrieben haben. Seh aber auf Anhieb nicht, welcher Buchstabe sich unterscheidet.

--Bezeichner auf Bitte von OP geändert in Xzy_KraTxReqPendFlags

MFK

Wie sind denn Xzy_KraTxReqFlags und Xzy_KraTxReqPendFlags definiert? Sicher, dass die unsigned sind?

---Variablennamen auf Bitte OP umgeändert

volkard

Ist dann herumprobieren, wo das Tool ausnahmsweise keinen Bug hat.

if ( 0x0001 == VarB ) 
{ 
  VarA &= ~VarB; 
}

if ( 0x0001 == VarB ) 
{ 
  VarA &= ~0x0001; 
}

if ( 0x0001 == VarB ) 
{ 
  VarA &= 0xfffe; 
}

if ( 0x0001 == VarB ) 
{ 
  if ( VarA & 1 )
    --VarA;
}

volkard

RyoShinzo schrieb:

Nein, der cast hilft leider auch nicht. Ich habe auch schon folgendes probiert:
VarA = (uint16)(VarA & (~VarB));
Das führt dann allerdings zu einer anderen Meldung:

Bitwise operations on signed data will give implementation defined results.

Da kommt der Cast eigentlich zu spät.
Ich würde noch dran denken, den Kram aufzusplitten, um rauszufinden was genau davon dem Analysetool wehtut.

if ( 0x0001 == VarB ) {
   VarA = (uint16)(VarA & (~VarB));

if ( 0x0001 == VarB ) {
   uint16 tmp1=~VarB;
   VarA = (uint16)(VarA & tmp1);

if ( 0x0001 == VarB ) {
   uint16 tmp1=~VarB;
   uint16 tmp2=VarA & tmp1;
   VarA = tmp2;

Wutz

RyoShinzo schrieb:

unsigned short VarA = ...;
unsigned short VarB = ...;

VarA &= ~VarB;
Mein Problem ist nun, dass VarB in ein signed short gewandelt wird.

Quatsch.
unsigned short typisierte Ausdrücke werden niemals bei arithmetischen Operationen in signed short umgewandelt, sie werden in signed int und wenn der Wert hier nicht reinpasst in unsigned int gewandelt.
Ein C Compiler rechnet (standardkonform) niemals mit rangniederen Typen als signed int/unsigned int.