Documentation PostgreSQL 14.22 » Internes » Conventions de codage pour PostgreSQL » Conventions diverses de codage

Précédent | Niveau supérieur | Suivant
54.3. Guide de style des messages d'erreur | Sommaire | Chapitre 55. Support natif des langues

## 54.4. Conventions diverses de codage

### Standard C

Le code dans PostgreSQL devrait seulement se baser sur les fonctionnalités disponibles dans le standard C99. Ceci signifie qu'un compilateur se conformant au standard C99 doit être capable de compiler PostgreSQL, à l'exception possible de quelques parties dépendantes de la plateforme.

Certaines fonctionnalités incluses dans le standard C99 ne sont actuellement pas autorisées dans le code principal de PostgreSQL. Ceci inclut actuellement les tableaux de longueur variable, les déclarations mêlées dans le code, les commentaires `//`, les noms de caractères universels. Les raisons incluent entre autre la portabilité et les pratiques historiques.

Les fonctionnalités des révisions ultérieures du standard C ou du compilateur peuvent être utilisées si un contournement est fourni.

Par exemple `_Static_assert()` et `__builtin_constant_p` sont actuellement utilisés, même s'ils font partie, respectivement, d'une révision plus récente du standard C et d'une extension GCC. S'ils ne sont pas disponibles, nous retournons respectivement vers l'utilisation d'un remplacement C99 compatible réalisant les mêmes vérifications, mais émet des messages plutôt incompréhensibles et nous n'utilisons pas `__builtin_constant_p`.

### Macros du style fonctions et fonctions inline

Les macros avec arguments et les fonctions `static inline` peuvent être utilisés. Ces dernières sont préférables s'il y a un risque de multiples évaluations si elles sont écrites en tant que macro, comme le cas avec

    #define Max(x, y)       ((x) > (y) ? (x) : (y))

ou quand la macro deviendrait très longue. Dans d'autres cas, il est possible d'utiliser des macros ou au moins plus facilement. Par exemple parce que des expressions de types divers ont besoin d'être passées à la macro.

Quand la définition d'une fonction inline référence des symboles (autrement dit des variables, des fonctions) uniquement disponibles dans le moteur, la fonction pourrait ne pas être visible lorsqu'elle est incluse dans le code frontend.

    #ifndef FRONTEND
    static inline MemoryContext
    MemoryContextSwitchTo(MemoryContext context)
    {
        MemoryContext old = CurrentMemoryContext;

        CurrentMemoryContext = context;
        return old;
    }
    #endif   /* FRONTEND */

Dans cet exemple, `CurrentMemoryContext`, qui est seulement disponible dans le moteur, est référencé et la fonction est donc cachée avec un `#ifndef FRONTEND`. Cette règle existe parce que certains compilateurs émettent des références aux symboles contenus dans les fonctions inline même si la fonction n'est pas utilisée.

### Écrire des gestionnaires de signaux

Pour pouvoir être exécuté à l'intérieur d'un gestionnaire de signal, le code doit être écrit avec beaucoup d'attention. Le problème fondamental est qu'une gestion de signal peut interrompre le code à tout moment, sauf s'il est bloqué. Si le code à l'intérieur d'un gestionnaire de signal utilise le même état que le code en dehors, un grand chaos peut survenir. Comme exemple, pensez à ce qui arriverait si un gestionnaire de signal essaie d'obtenir un verrou qui est déjà détenu par le code interrompu.

En dehors d'arrangements spéciaux, le code dans les gestionnaires de signaux doit seulement appeler des fonctions saines de signal asynchrone (d'après la définition de POSIX) et accèder à des variables de type `volatile sig_atomic_t`. Quelques fonctions dans `postgres` sont aussi déclarées comme saines pour les signaux, notamment `SetLatch()`.

Dans la plupart des cas, les gestionnaires de signaux ne devraient rien faire de plus que de noter qu'un signal est arrivé, et réveiller du code à l'extérieur du gestionnaire en utilisant un latch. Voici un exemple d'un tel gestionnaire :

    static void
    handle_sighup(SIGNAL_ARGS)
    {
        int         save_errno = errno;

        got_SIGHUP = true;
        SetLatch(MyLatch);

        errno = save_errno;
    }

`errno` est sauvegardé puis restauré parce que `SetLatch()` pourrait le modifier. Si cela n'était pas fait, le code interrompi qui était en train d'inspecter `errno` pourrait voir la mauvaise valeur.

### Appeler des pointeurs de fonction

Pour plus de clarté, il est préféré de déréférencer explicitement un pointeur de fonction lors de l'appel de cette fonction si le pointeur est une simple variable, par exemple :

    (*emit_log_hook) (edata);

(même si `emit_log_hook(edata)` fonctionnerait aussi). Quand le pointeur de fonction fait partie d'une structure, la ponctuation supplémentaire peut et devrait habituellement être omise. Par exemple :

    paramInfo->paramFetch(paramInfo, paramId);