[C] enum Warnungen

[Bauform B. (bauformb)]

Servus!

Eigentlich wollte ich fragen, ob der gcc vielleicht noch mehr 
enum-Warnungen liefern könnte. Das wäre nett, aber beim minimalen 
Testfall fehlt jetzt eine, die ich wirklich vermisse:

#include <stdio.h>
#include <time.h>

typedef enum foo_enum {
   FOO_NONE,
   FOO_A,
   FOO_B
} foo_enum;

int enum_test (foo_enum p1)
{
   int i32;

   printf ("%ld %ld\n", sizeof i32, sizeof (time_t));
   i32 = time (NULL);
   if (p1 == FOO_A) {
      p1 = time (NULL);
   }
   switch (p1) {
   case FOO_A:
      printf ("A\n");
      break;
   case 42:
      printf ("B\n");
      break;
   case FOO_NONE:
      printf ("Sorry.\n");
      break;
   }
   return 0;
}

enum_test.c: In function 'enum_test':
enum_test.c:16:10: warning: conversion from 'time_t' {aka 'long int'} to 'int' may change value [-Wconversion]
   16 |    i32 = time (NULL);
      |          ^~~~
enum_test.c:20:4: warning: enumeration value 'FOO_B' not handled in switch [-Wswitch]
   20 |    switch (p1) {
      |    ^~~~~~
enum_test.c:24:4: warning: case value '42' not in enumerated type 'foo_enum' [-Wswitch]
   24 |    case 42:
      |    ^~~~

Zeile 16: reine Routine, Zeile 20 und 24 finde sehr nützlich. Aber Zeile 
18 "p1 = time (NULL);" ist angeblich total ok?

Mein gcc kennt immerhin schon -std=c2x, der ist doch nicht völlig 
veraltet?

gcc (Debian 12.2.0-14+deb12u1) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.

Vor 20 Jahren bekam jemand eine Warnung vom IAR, wie ich sie auch gerne 
hätte:
Beitrag "Enum Warnung"

Edit: na klar, time() von heute = 1772093657, passt noch in int32_t ;)

[Harald K. (kirnbichler)]

Bauform B. schrieb:
> Aber Zeile
> 18 "p1 = time (NULL);" ist angeblich total ok?

Wie sieht der Prototyp der Funktion time aus? Hast Du mal in time.h 
nachgesehen?

Da dürfte was stehen wie

time_t time(time_t *);

Der Funktion einen Nullpointer zu übergeben ist legitim, den 
Rückgabewert einem int zuzuweisen, kann auch vollkommen legitim sein (je 
nachdem, wie in Deinem System time_t definiert ist).

Was erwartest Du?

[Daniel A. (daniel-a)]

Naja, die Sache ist halt, enum konstanten sind nicht vom sie 
definierenden enum typ, sondern (meistens) ein int. Und wenn man den Typ 
explizit angibt, wird der enum gleich ganz als solchen behandelt...

#include <stdio.h>

int main(){
    {
      enum a { A };
      printf("%s %s %s\n",
        _Generic(A, enum a: "enum", int: "int"),
        _Generic((enum a)A, enum a: "enum", int: "int"),
        _Generic(((enum a)A)+1, enum a: "enum", int: "int")
      );
    }

    /*
    { // error: '_Generic' specifies two compatible types
      enum a : int { A };
      printf("%s %s %s\n",
        _Generic(A, enum a: "enum", int: "int"),
        _Generic((enum a)A, enum a: "enum", int: "int"),
        _Generic(((enum a)A)+1, enum a: "enum", int: "int")
      );
    }
    */
}

Ausgabe: int enum enum

Also in anderen Worten, bei `enum a x = A;`, is A nicht vom Typ `enum 
a`, darum kann der Compiler da auch den Typ nicht checken.

[Niklas G. (erlkoenig)]

Code mit "g++" statt "gcc" kompilieren und "enum class" statt "enum" 
hinschreiben

[Bauform B. (bauformb)]

Harald K. schrieb:
> Der Funktion einen Nullpointer zu übergeben ist legitim, den
> Rückgabewert einem int zuzuweisen, kann auch vollkommen legitim sein (je
> nachdem, wie in Deinem System time_t definiert ist).
>
> Was erwartest Du?

Die gleiche Warnung wie für Zeile 16, da funktioniert es doch: 
"conversion from 'time_t' {aka 'long int'} to 'int'..." Da steht 'long 
int' und mein enum sollte wirklich nicht long sein.

OK, die Warnung würde praktisch nicht viel nützen und auf einem System 
mit 64-bit int würde es garnicht auffallen. Aber hier müsste die Warnung 
doch zwangsläufig kommen und das irritiert mich.


Niklas G. schrieb:
> Code mit "g++" statt "gcc" kompilieren und "enum class" statt "enum"
> hinschreiben

Das war ja klar :)  make[1]: g++: No such file or directory;
Später gibt es tatsächlich nützliche neue Meldungen:

version.c:3: warning: "_GNU_SOURCE" redefined
    3 | #define _GNU_SOURCE
      | 
<command-line>: note: this is the location of the previous definition

info_up.c:73:7: error: initializer-string for 'const unsigned char [128]' is too long [-fpermissive]
   73 |       "________________________________"
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   74 |       "___#_%&_()_+,-._0123456789___=__"
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   75 |       "@ABCDEFGHIJKLMNOPQRSTUVWXYZ_____"
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   76 |       "_abcdefghijklmnopqrstuvwxyz_____";
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Au weia. Was macht der gcc daraus? Weiß der, dass das nie als String 
benutzt wird optimiert die '\0' am Ende weg?

Aber solche Sachen finde ich doch übertrieben, das macht doch nur 
Arbeit:

shm-view.c:200:15: error: invalid conversion from 'void*' to 'req_st*' [-fpermissive]
  200 |    req = mmap (0, sizeof (req_st), PROT_READ | PROT_WRITE, MAP_SHARED, fifo, 0);
      |          ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |               |
      |               void*

[Norbert U. (norbert_u)]

Versuche es mal mit der Option -Wenum-int-mismatch

[Bauform B. (bauformb)]

Norbert U. schrieb:
> -Wenum-int-mismatch

Das hört sich sehr gut an, danke! Leider ist mein gcc wohl doch zu alt, 
aber das ist vorgemerkt.

unrecognized command-line option '-Wenum-int-mismatch';
did you mean '-Wargument-mismatch'?

[Markus F. (mfro)]

in C sind enums typenlos (was leider dazu führt, daß sie auch ziemlich 
wertlos sind).

enum obst {APFEL, BIRNE, KIRSCHE, QUITTE};
enum tier {HUND, KATZE, MAUS};

...

enum obst o = KATZE;  /* führt weder zu einem Fehler noch zu einer Warnung */

also ziemlich witzlos, das ganze.

Schlimmer noch:

/* das führt zu Fehlermeldungen: */
enum haustier {HUND, KATZE};
enum wildtier {MAUS, ELEFANT};

führt (leider) zu Fehlern.

So daß der geneigte C-Enthusiast sich regelmäßig fragt, wozu enums gut 
sein sollen.

[Rolf M. (rmagnus)]

Bauform B. schrieb:
> Da steht 'long int' und mein enum sollte wirklich nicht long sein.

Warum gibst du die Größe hier nicht einfach mit aus?
> printf ("%ld %ld\n", sizeof i32, sizeof (time_t));
(übrigens: der korrekte Format-Specifier für size_t ist %zu)

aber ja, der enum sollte die gleiche Größe wie int haben.

Bauform B. schrieb:
> Au weia. Was macht der gcc daraus? Weiß der, dass das nie als String
> benutzt wird optimiert die '\0' am Ende weg?

Er "optimiert" nicht, sondern es ist in C so, dass in so einem Fall kein 
\0 angehängt wird, also:

char x[6] = "Hallo"; // hängt \0 an
char y[5] = "Hallo"; // erlaubt, hängt aber kein(!) \0 an
char z[4] = "Hallo"; // Fehler, zu wenig Platz

In C++ ist das anders geregelt. Da wird das \0 immer angehängt, d.h. der 
zweite Fall ist dort auch ein Fehler, weil zu wenig Platz.

Bauform B. schrieb:
> Aber solche Sachen finde ich doch übertrieben, das macht doch nur
> Arbeit:

Naja, C++ ist da strikter und lässt zwar Konvertierungen von Zeigern 
nach void* ohne Cast zu, aber von void* in was anderes muss man explizit 
casten. Allerdings braucht man void* in C++ auch nicht so oft, wenn man 
es richtig macht.

[Niklas G. (erlkoenig)]

Bauform B. schrieb:
> make[1]: g++: No such file or directory;

Kurioses Setup, lässt sich aber trivial beheben!

Bauform B. schrieb:
> Au weia. Was macht der gcc daraus?

Schalt mal -Wextra ein:

warning: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (129 chars into 128 available) [-Wunterminated-string-initialization]

0-Byte wird also weggelassen weil das Array zu klein ist.

Bauform B. schrieb:
> Aber solche Sachen finde ich doch übertrieben, das macht doch nur
> Arbeit:

Das ist Typsicherheit... void* sollte man halt so wenig wie möglich 
verwenden. In C ist es nicht vermeidbar, in C++ größtenteils schon. 
Einen Cast hinzuzufügen, auch als Warnung an den Leser, dass hier etwas 
potenziell gefährliches passiert, schadet nicht.

Markus F. schrieb:
> in C sind enums typenlos

Sie sind nicht typenlos, sie sind Integer.