Integer mit einem Bit ?

Nix weltbewegendes,
habe mich eben nur gewundert über einen Warning

Code:

---

typedef volatile union
{
  struct  {
    unsigned int dat1 :  1; 
    signed  int dat2 :  1;  /* [Warning] : signed bitfield of length 1 */
            int dat3 :  1;
            int rest : 29;
  } bits;
  unsigned int value;
} TRegister;

---

Nun kam mir die Frage:
ist ein "signed int" nicht das selbe (gleiche) wie ein "int" ???
Eigentlich ist ein signed int ja "doppelt gemoppelt" und entsprechend unnötig.
Aber ich finde den Warning sogar sehr gut, denn dat2 hätte ja nichts weiter wie ein Vorzeichen, was wohl wenig Sinn macht.
Dann müste man aber alle "ein Bit" Daten als "unsigned int" erklären. Wäre zumindest sinnvoll.
Laut ANSI-C soll es aber ein "int" sein.
Nun wird man sich fragen, was will der Siro darauf für eine Antwort haben.
Keine, war nur eine Feststellung.
Ein schönes Wochenende wünsche ich.
Siro

Signed bedeutet ja mit Vorzeichen, und dieses verbraucht ja auch ein Bit. Ein 1-Bit-Signed-Int würde doch nur aus Vorzeichen bestehen, oder irre ich mich da? Wäre jedenfalls keine sinnvolle Zahl...

Hallo Geistesblitz,
das ist ja genau das, was ich meine.
Ich darf ein einzelnes Bit als "int" definieren. Das ist natürlich völliger Blödsinn.
Deshalb bin ich ja der Meinung, daß ein einzelnes Bit unweigerlich ein "unsigned" sein müste.
Aber bevor ich mich wieder mal negativ über "C" äussere, nehme ich das mal so hin......
Wär ich Compiler, würde ich meckern, Ein Bit kann kein Int sein :-)
Und das hat der Compiler ja auch richtig angemeckert als ich ihm einen "signed int" angeboten habe,
mal abgesehen davon, daß es diesen Typen wohl nicht gibt.

Siro

Bei einem Bitfeld bedeutet "int" NICHT automatisch "signed".
Ob bei einem Bitfeld ein "int" "signed" oder "unsigned" ist, ist "implementation-defined", wird also vom Compiler festgelegt. Und offenbar ist es bei dem von dir verwendeten Compiler "unsigned", denn sonst würde er ja auch bei "int dat3 : 1;" eine Warnung bringen.

Guten Morgen Sternst und die anderen...
Um deine Aussage zu prüfen, habe ich gleich mal folgendes probiert:

Code:

---

struct
{
  int          dat1 : 3;
  signed int  dat2 : 3;
} st;

int main(void)
{ int a;
 
  st.dat1 = -3;
  st.dat2 = -3;
 
  a = st.dat1;  /* a ist nun +5 !!!!!!!!! */
  a = st.dat2;  /* a ist nun -3 */ 

}

---

Und siehe da, Du hast vollkommen recht, der (mein) Compiler interpretiert bei Bit Definitionen den int tatsächlich "vorzeichenlos".
Dann ist also meine Frage garnicht so dumm gewsesen. Bei Bitdefinitionen ist es also sehr wohl erlaubt (bzw.) sogar Pflicht
dem int ein Vorzeichen aufzudrängeln, sonst verhält sich der Code unter Umständen nicht wie vorgesehen.
Ich hab den Satz mal fett gemacht, ich glaube das ist eine ganz wichtige Aussage.
Ich danke Dir, für die Info.
Siro

Zitat:

---

Zitat von Siro

Bei Bitdefinitionen ist es also sehr wohl erlaubt (bzw.) sogar Pflicht
dem int ein Vorzeichen aufzudrängeln, sonst verhält sich der Code unter Umständen nicht wie vorgesehen.
Ich hab den Satz mal fett gemacht, ich glaube das ist eine ganz wichtige Aussage.

---

Damit die Aussage für jemanden von Nutzen ist, müsstest du aber noch den Namen des verwendeten Compilers nennen ;)

Hallo Frank,
hast recht, der Vollständigkeit halber:

Der C-Compiler von IAR Embedded Workbench

interpretiert einen int bei Bitdefinitionen vorzeichenlos.

Möchte man eine Bitkombination mit Vorzeichen haben, muss man einen

signed int benutzen.

Eine offizelle Bestätigung habe ich heute von IAR erhalten mit einem Verweis auf die Online Dokumentation des C++ Compilers, Seite 290
Den Ausschnitt habe ich mal angehangen. Zudem gibt es eine #pragma bitfield directive, mit der man unter anderem die Bit Reihenfolge einstellen kann LSB / MSB first usw.

Siro