Est-il possible de renvoyer différents "faux" en C?

Cela se fait généralement dans le bon sens inverse.

typedef enum {
  USBD_OK   = 0,
  USBD_BUSY,
  USBD_FAIL,
}USBD_StatusTypeDef;

#define NRF_SUCCESS                           (NRF_ERROR_BASE_NUM + 0)  ///< Successful command
#define NRF_ERROR_SVC_HANDLER_MISSING         (NRF_ERROR_BASE_NUM + 1)  ///< SVC handler is missing
#define NRF_ERROR_SOFTDEVICE_NOT_ENABLED      (NRF_ERROR_BASE_NUM + 2)  ///< SoftDevice has not been enabled
#define NRF_ERROR_INTERNAL                    (NRF_ERROR_BASE_NUM + 3)  ///< Internal Error
#define NRF_ERROR_NO_MEM                      (NRF_ERROR_BASE_NUM + 4)  ///< No Memory for operation
#define NRF_ERROR_NOT_FOUND                   (NRF_ERROR_BASE_NUM + 5)  ///< Not found
#define NRF_ERROR_NOT_SUPPORTED               (NRF_ERROR_BASE_NUM + 6)  ///< Not supported
#define NRF_ERROR_INVALID_PARAM               (NRF_ERROR_BASE_NUM + 7)  ///< Invalid Parameter
#define NRF_ERROR_INVALID_STATE               (NRF_ERROR_BASE_NUM + 8)  ///< Invalid state, operation disallowed in this state
#define NRF_ERROR_INVALID_LENGTH              (NRF_ERROR_BASE_NUM + 9)  ///< Invalid Length
#define NRF_ERROR_INVALID_FLAGS               (NRF_ERROR_BASE_NUM + 10) ///< Invalid Flags
#define NRF_ERROR_INVALID_DATA                (NRF_ERROR_BASE_NUM + 11) ///< Invalid Data
#define NRF_ERROR_DATA_SIZE                   (NRF_ERROR_BASE_NUM + 12) ///< Invalid Data size
#define NRF_ERROR_TIMEOUT                     (NRF_ERROR_BASE_NUM + 13) ///< Operation timed out
#define NRF_ERROR_NULL                        (NRF_ERROR_BASE_NUM + 14) ///< Null Pointer
#define NRF_ERROR_FORBIDDEN                   (NRF_ERROR_BASE_NUM + 15) ///< Forbidden Operation
#define NRF_ERROR_INVALID_ADDR                (NRF_ERROR_BASE_NUM + 16) ///< Bad Memory Address
#define NRF_ERROR_BUSY                        (NRF_ERROR_BASE_NUM + 17) ///< Busy
#define NRF_ERROR_CONN_COUNT                  (NRF_ERROR_BASE_NUM + 18) ///< Maximum connection count exceeded.
#define NRF_ERROR_RESOURCES                   (NRF_ERROR_BASE_NUM + 19) ///< Not enough resources for operation

C'est une logique très simple - si la fonction renvoie une valeur non nulle - cela signifie que quelque chose ne va pas.

Exemples de la vie réelle: Bibliothèques STM: / * Suivant l'état du périphérique USB * /

 if(salloc(a,b)) // Handle error

 if(USB_Transmit(a,b)) // Handle error

Où NRF_ERROR_BASE_NUM est généralement 0

Si vous écrivez

salloc_rc returnCode = salloc(a, b);
if (returnCode != SALLOC_OK) handleError();

c'est tout simplement faux. Bogue grave. Mais si vous écrivez

if (salloc(a, b)) handleError();

alors, en tant que lecteur de votre code, je n'ai aucune idée si cette déclaration est correcte ou non, ce qui m'oblige à lire la documentation. Donc, la manière correcte de faire ceci est:

if (! salloc(a,b)) handleError();

C'est propre, ça dit exactement au lecteur ce qui se passe, ça donne une chance de définir un point d'arrêt où vous examinez le code de retour. Gagnez partout. N'ayez pas peur de quelques frappes supplémentaires. Rendez votre code lisible. Et si on vous parle d'une "manière habituelle de vérifier les erreurs" qui rend votre code difficile à lire, alors n'utilisez pas la "manière habituelle de vérifier les erreurs".

Notez que dans de nombreux autres langages modernes (Java, Swift), vous ne pouvez pas utiliser une énumération comme condition dans une instruction if, ou comme argument pour! (ne pas). Merde, je viens d'appeler Java un "langage plus moderne" :-(

Vous avez plusieurs options, si vous n'avez besoin que d'un code de réussite et de plusieurs codes d'erreur.
Aucun n'est aussi naturel / idiomatique et donc agréable que si les choses étaient l'inverse:

1. Utilisez un espace auxiliaire pour des informations supplémentaires:

   1. Utilisez errno pour Informations supplémentaires sur le transport pour les personnes intéressées.
      La bibliothèque standard fait cela de manière extensive.

   2. Stockez l'erreur spécifique dans l'objet utilisé. fgetc () le fait avec feof () et ferror().

   3. Définissez votre propre réserve (locale du thread) pour des informations supplémentaires sur les erreurs.

   4. Utilisez un rappel ou un pointeur de sortie supplémentaire.

   5. Renvoyez une struct avec tous les membres dont vous avez besoin.

2. Utilisez une logique inversée, ce qui signifie que seul faux est le succès.
   Cela rappelle l'utilisation d'une fonction de comparaison générale comme strcmp () pour vérifier l'égalité.

3. Dédiez une partie de la plage de valeurs de retour aux erreurs:

   1. Utilisez une erreur négative. La bonne chose est que vous avez tous les non-négatifs pour réussir.
      COM le fait largement avec leur HRESULT . Comme beaucoup d'appels système Linux.

   2. Les nombres à virgule flottante ont généralement de nombreuses valeurs NaN. On pourrait y mettre des détails, et certaines architectures garantissaient même de propager celle avec le plus petit code. Malheureusement, cela a été rarement utilisé, a un léger coût et n'a donc pas été suivi pour les nouvelles instructions.

   Il existe d'autres exemples moins pratiques.

Mon conseil est de le stocker dans l'objet manipulé si vous le pouvez, suivi de errno , puis de la logique inversée et enfin des conventions COM.