• # J'ai glissé

    Posté par  (site web personnel, Mastodon) . Évalué à 4 (+1/-0).

    Si quelqu'un peut remplacer le w par une apostrophe dans le titre, ça serait super. Mon clavier me joue des tours mais en général il ne se blo

  • # Oh

    Posté par  (site web personnel) . Évalué à 8 (+6/-0).

    Bon, moi j'aimerais déjà pouvoir faire du C23 et malheureusement beaucoup de mes environnements m'en empêche (surtout dans l'embarqué). Ce que j'aime le plus en C23 c'est

    • initialiser des objets 100% à 0 (y compris les bits de padding) avec struct foo f = {}
    • spécifier des enum pour avoir un meilleur support des IDEs et une lisibilité du code mais en restant utile pour des structure binaires (e.g. enum type : uint8_t)

    Pour la nouvelle norme

    1. Les cases range, bordel je veux ça depuis un bail
    2. le 3367, je comprends pas le nommage stdc_, ça va pas du tout avec l'existant

    AI is a mental disorder

    • [^] # Re: Oh

      Posté par  (site web personnel, Mastodon) . Évalué à 9 (+6/-0).

      Le nommage stdc_ est très brièvement justifié dans l'article. Historiquement, seules les quelques premières lettres (8, je crois) d'un nom de symbole étaient significatives. Ce n'était donc pas garanti de pouvoir avoir masuperfonction1 et masuperfonction2 (les deux pourraient voir leur symbole tronqué en "masuperf").

      Les versions précédentes du C utilisaient donc des abbréviations de plus en plus obscures (memcpy, strcmp, wmbstocstr, …) pour ne pas avoir de conflits dans ce cas.

      La limite ayant été augmentée à 31 caractères, en utiliser 5pour le préfixe stdc_ devient raisonable.

      Personellement je suis un peu embêté par le retrait des nombres octals. Je comprend la logique, mais ça ne va pas faciliter la migration de code existant qui en a besoin, ni de pouvoir écrire du code compatible avec plusieurs versions du standard.

      • [^] # Re: Oh

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+2/-1). Dernière modification le 14 juin 2025 à 21:54.

        seules les quelques premières lettres

        Seulement pour les fonction C standard. Et cela se justifie par le fait, qu'elle sont plus simple à mémoriser et plus rapide à écrire. Bon aujourd'hui avec les bons système d'auto-complétion, c'est moins utile. Et surtout avec les ajouts de fonctions, notamment de fonctions plus sécurisé (sans enlever les ancienne pour la rétro-compatibilité), ça devient un peu complexe.

        Mais sinon, je trouve très parlant les noms court:

        • strcpy : "string copy"

        • memcpy : "memory copy"

        Le problème c'est quand on en rajoute. strcpy devient ainsi "strncpy" "string copy n characters" (pour la sécu). Et après : https://learn.microsoft.com/fr-fr/cpp/c-runtime-library/reference/strncpy-strncpy-l-wcsncpy-wcsncpy-l-mbsncpy-mbsncpy-l?view=msvc-170 …
        On se retrouve avec des versions par type: l pour un long, i pour l'entier, s pour la string. Puis des versions par destination…

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

        • [^] # Re: Oh

          Posté par  (site web personnel) . Évalué à 6 (+3/-0).

          Seulement pour les fonction C standard. Et cela se justifie par le fait, qu'elle sont plus simple à mémoriser et plus rapide à écrire.

          C'était surtout une limitation des compilateurs de l'époque.

          • [^] # Re: Oh

            Posté par  (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 15 juin 2025 à 07:18.

            Plutôt des éditeurs de liens. Les compilateurs ne faisaient que répercuter cette limitation.

            « Smart IoT Crafting » : l'IoT pour tous

  • # Assignation dans les if

    Posté par  . Évalué à 4 (+2/-0).

    if (int num_fired = fire_off(argc)) {
    // checks for num_fired is non-zero
    }

    Vous pensez que vous allez utiliser ça ? C'est une fonctionnalité dont j'ai souvent eu envie, mais les risques de confusion entre comparaison et assignation me paraissent assez importants.

    J'ai souvenir d'une tentative d'introduction de backdoor dans le code de Linux, il y a bien longtemps :

    if ((options == (WCLONE|WALL)) && (current->uid = 0))
    retval = -EINVAL;

    Avec l'apparence d'une comparaison, l'user ID passait à 0, et l'utilisateur devenait root. C'est quand même difficile à détecter, sans doute suffisamment pour en décourager l'usage.

    • [^] # Re: Assignation dans les if

      Posté par  . Évalué à 4 (+3/-0).

      Ton exemple c'est quelqu'un qui essaye volontairement de tromper le relecteur. Les cas accidentels sont souvent détectés par le compilateur. Mais, oui, c'est un danger.

      La déclaration me semble moins dangereuse en fait. La déclaration se repère mieux que des parenthèses superflues et force l'affectation (if (int num_fired == fire_off(argv)) { n'a pas de sens). Donc l'affectation devrait être plus repérable par le relecteur.

      Je ne vois pas quels risques sont ajoutés, même si ça ne retire pas les risques déjà existants.

    • [^] # Re: Assignation dans les if

      Posté par  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

      Dans certains projets, pour éviter ce problème on utilise les "yoda conditions", ici on aurait écrit:

      0 == current_uid

      ce qui ne compile pas si on met un = à la place du ==

      Mais aujourd'hui les compilateurs savent détecter ce type d'erreur (avec des warnings à activer).

      Cette hossibilité de déclarer une variable dans un =f me semble surtout utile en c++ parce que la desruction de la variable sera faite dès la sortie du bloc if/else, cela peut parfois être important. En Ccela servira surtout à alléger l'écriture, ce qui n'est pas forcément une bonne idée (de la même façon que ne pas mettre d'accolades pour un if n'ets pas forcément une bonne idée).

      Le blog mentionne des cas d'usages pour des macros, et effectivement c'est dans ce cas que ça peut devenir très intéressant. Imaginons du code comme ceci:

      if (ISVALID(X)) { … }

      La macro ISVALID() peut avoir besoin de variables temporaires pour faire son travail.

    • [^] # Re: Assignation dans les if

      Posté par  (site web personnel) . Évalué à 8 (+6/-0).

      Vous pensez que vous allez utiliser ça ?

      Ça fait des années que j'essaye de l'utiliser en C++ et le résultat est toujours le même, une condition inutilement compliquée qui amène surtout beaucoup de questions. Juste pour réduire la portée d'une variable on se retrouve à se demander pourquoi tout le code est dans le if et quelle est la condition testée au final. Et puis je n'aime pas trop voir des affectations dans les conditions, on se demande toujours si c'est normal, du coup ça gêne le flot de lecture.

      S'il faut vraiment limiter la portée d'une variable, ce qui arrive quasiment jamais, je préfère ajouter des accolades :

      void foo()
{
  // …
  {
    int num_fired = fire_off(argc);

    if (num_fired != 0)
      // …
  }
}

      • [^] # Re: Assignation dans les if

        Posté par  (site web personnel, Mastodon) . Évalué à 3 (+0/-0).

        L'exemple que je donnais avec une macroest très improbable en C++ ouon fera ce genre de chose en enveloppant les choses dans une classe et on aurait dong un if (x.isvalid()) par exemple.

        mais en C, il y a un peu plus de cas où ça se justifie (bon, pas vraiment en fait. Faites du C++ au lieu d'insister avec le C)

    • [^] # Re: Assignation dans les if

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      Oui je le faisais en C++ parce que ça permet d'éviter d'encombrer un bloc plein de variables qui n'ont plus besoin d'être présente après le bloc if. De la même manière qu'on peut déclarer une variable dans une boucle for depuis 1999 :)

      if (int rc = gpio_pin_configure(&gpio, GPIO_OUTPUT); rc != 0) {
    LOG_ERR("error: %d", rc);
}

// rc n'existe plus ici

      AI is a mental disorder

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.