Embedded weblog - Tag - bsd - Commentaires

decreasing the size of the distribution [OpenBSD] - Gilles Blanc

2009-10-27T10:16:58+01:00

PF/OSPF/CARP

Et vraiment, que ça. N'empêche, parfois, il n'y a pas le choix.

Et puis, c'est sous licence permissive BSD, aussi... (mais à ce niveau, si c'est juste pour cette raison, aller voir du côté de Net ou Free est meilleur, à mon sens -- l'histoire de la sécurité et du strlcat et compagnie, ça reste tout de même de la blague)

decreasing the size of the distribution [OpenBSD] - Xuelynom

2009-10-26T21:05:50+01:00

Haha excellent :D

A se demander pourquoi des gens restent encore sur ce système.... (à part les barbus en charge)

au détour d'une macro crasseuse - Gilles Blanc

2009-08-28T18:59:46+02:00

Eh bien, tu t'es lâché dis-moi ! ^^ Tiens, v'la le code, la fonction setthetime qui utilise cette horreur vaut aussi le coup d'oeil...

au détour d'une macro crasseuse - Patrick Foubet

2009-08-28T17:25:01+02:00

En fait, comme toujours sur un blog, on va à l'essentiel et on néglige les détails, c'est pourquoi souvent les commentaires qu'on y trouve sont mals perçus.
Donc là, comme c'est le tien (de blog), j'ai un remords et je vais essayer de réparer mon manque d'explication (si j'y arrive) ;-)

Voici un petit programme, que j'appelle e.c, dans lequel j'ai défini :
- la macro ATOI2 vue ci-dessus
- la macro ATOI2a que j'ai proposée en échange
- la macro ATOI2b qui est encore une autre version
Dans un premier temps je n'utilise pas ces macros mais "atoi" de la librairie standard.

#define ATOI2(ar) ((ar) += 2, ((ar)[-2] - '0') * 10 + ((ar)[-1] - '0'))
#define ATOI2a(ar) ((ar)[0] - '0') * 10 + ((ar)[1] - '0')
#define ATOI2b(ar) (((ar++)[0] - '0') * 10 + ((ar++)[0] - '0') )

#include <stdio.h>

int main(int N, char*P[])
{
char t[10], *b;
int i,j,k;
strcpy(t,"256789");
b=t;
i = atoi(t); /* ligne 13 */
j = atoi(b);
k = atoi("791234"); /* ligne 15 */
printf(" i=%d j=%d k=%d t=<%s> b=<%s> ",i, j, k, t, b);
}

Je compile :
$ cc -o e e.c
Pas de problème particulier.
J'exécute :
$ ./e
i=256789 j=256789 k=791234 t=<256789> b=<256789>
Rien que du classique.

Maintenant je remplace dans les lignes 13 à 15, atoi par ATOI2, macro qui ne travaille que sur les deux premiers caractères et qui en plus fait progresser le pointeur de 2 crans.

Je compile :
$ cc -o e e.c
e.c: Dans la fonction « main »:
e.c:13: error: incompatible types in affectation
e.c:15: error: affectation of read-only location
e.c:15: error: incompatible types in affectation

Hé oui ! car une des raisons est que l'on essaie d'accéder aux éléments d'une chaîne de caractère définie comme une constante (ligne 15).
Ceci avec gcc peut se résoudre (bien que ce soit fortement déconseillé) par :
$ cc -o e -fwritable-strings e.c
e.c: Dans la fonction « main »:
e.c:13: error: incompatible types in affectation
e.c:15: error: incompatible types in affectation

Il reste quand même que, selon l'implémentation faite par le compilateur, un tableau de caractères et une chaîne constante ne sont pas toujours assimilables à un pointeur !! (cf K&R pour les détails). On peut les utiliser pour initialiser un pointeur mais pas pour faire des opérations dessus.
Certains compilateurs le permettent (comme par exemple le cc d'un Aix que j'ai utilisé dans les années 90) mais il ne faut pas compter dessus !!

Par contre, si on remplace, entre les lignes 13 et 15, atoi par ATOI2a on a bien le résultat sur les 2 premiers caractères mais le pointeur n'est pas décallé de 2 !! Il faut le faire à la main.

Pour bien enfoncer le clou, je propose une seconde alternance, qui fait la même chose que ATOI2 mais sans l'instruction ','. Si on remplace atoi par ATOI2b, on a, à la compilation :
$ cc -o e e.c
e.c: Dans la fonction « main »:
e.c:13: error: wrong type argument to increment
e.c:13: error: wrong type argument to increment
e.c:15: error: wrong type argument to increment
e.c:15: error: wrong type argument to increment

Ce qui confirme bien la raison décrite ci-dessus.
On remarque au passage que l'utilisation des index négatifs ne perturbe pas le compilateur, et c'est normal.

Et voilà tout ce qui se cachait derrière mon laconique "avec un gcc 3.3.5 le code que tu signales ne passe pas" !

Comme quoi, on veut dire deux mots en passant et on y passe la soirée ...

Bien à toi

au détour d'une macro crasseuse - Gilles Blanc

2009-08-27T11:40:28+02:00

Pourtant, c'est un gcc3.3.5 qu'il y a sur BSD 4.2 ; mais il faut dire qu'ils l'ont tellement bidouillé, aussi...

au détour d'une macro crasseuse - Patrick Foubet

2009-08-27T11:15:26+02:00

Autant pour moi !! Je voulais écrire :
#define ATOI2(ar) ((ar)[0] - '0') * 10 + ((ar)[1] - '0')
Comme quoi la critique est une arme à double tranchant ;-)

En tous cas, avec un gcc 3.3.5 le code que tu signales ne passe pas !!

au détour d'une macro crasseuse - Patrick Foubet

2009-08-26T17:43:00+02:00

Je ne sais pas ce que le programmeur d'OpenBSD a fumé avant d'écrire cela mais :
#define ATOI2(ar) ((ar)[-2] - '0') * 10 + ((ar)[-1] - '0')
est quand même plus simple, plus rapide et fonctionne avec tous les compilateurs ;-)

au détour d'une macro crasseuse - Gilles Blanc

2009-05-28T16:38:24+02:00

Aaaahhh, bien vu l'expert ! :)

au détour d'une macro crasseuse - Sam

2009-05-27T18:45:08+02:00

Cela dit, aujourd'hui, il n'y aurait aucune raison de ne pas le coder comme une fonction :

static inline unsigned char atoi2(const char **ar);

Mais nous sommes en 2009, les compilateurs n'étaient probablement pas aussi efficace à l'époque où cette macro a été codée.

au détour d'une macro crasseuse - Sam

2009-05-27T18:31:41+02:00

Pourtant, tu as probablement déjà utilisé la virgule comme opérateur, par exemple dans "i++, j++" comme troisième argument d'un "for".

Ce genre d'utilisations est assez fréquente si on ne veut pas utiliser les extensions de GCC qui permettent d'avoir des blocs "{}" renvoyant un résultat, similaires à une lambda expression et permettant même d'y mettre des boucles du coup.