Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Implementation de strlen()

4 réponses
Avatar
candide
Bonjour

Soit l'implémentation classique (Plauger, K&R) suivante de la fonction
standard strlen() :


size_t mystrlen(const char *s)
{
const char *p;
for (p = s; *p; ++p);
return p - s;
}



Ce qui m'ennuie c'est que p-s est de type ptrdiff_t, d'où ma question :


Le code ci-dessus est-il portable ? N'y a-t-il pas risque d'overflow ?

4 réponses

Avatar
Jean-Marc Bourguet
candide writes:

Bonjour

Soit l'implémentation classique (Plauger, K&R) suivante de la fonction
standard strlen() :


size_t mystrlen(const char *s)
{
const char *p;
for (p = s; *p; ++p);
return p - s;
}



Ce qui m'ennuie c'est que p-s est de type ptrdiff_t, d'où ma question :


Le code ci-dessus est-il portable ? N'y a-t-il pas risque d'overflow ?



* La conversion d'un signe comme ptrdiff_t en un non signe comme size_t est
toujours bien definie.

* Pour p-s, il y a bien un risque de comportement indefini (6.5.6/9): The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is undefined.

* Ne pas oublier que l'implementation de la bibliotheque standard peut
dependre du fait que le reste de la chaine a le comportement desire, meme
c'est indefini par la norme.

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Samuel DEVULDER
candide a écrit :

Ce qui m'ennuie c'est que p-s est de type ptrdiff_t, d'où ma question :


Le code ci-dessus est-il portable ? N'y a-t-il pas risque d'overflow ?



Apparemment ptrdiff_t soulève en lui même d'autres risques:

http://blogs.msdn.com/david_leblanc/archive/2008/09/02/ptrdiff-t-is-evil.aspx

sam.
Avatar
Jean-Marc Bourguet
Samuel DEVULDER writes:

candide a écrit :

> Ce qui m'ennuie c'est que p-s est de type ptrdiff_t, d'où ma question :
> Le code ci-dessus est-il portable ? N'y a-t-il pas risque d'overflow ?

Apparemment ptrdiff_t soulève en lui même d'autres risques:

http://blogs.msdn.com/david_leblanc/archive/2008/09/02/ptrdiff-t-is-evil.aspx



Le probleme, ce n'est pas ptrdiff_t, c'est l'utilisation abusive de non
signes. (Et oui, je pense que le fait que size_t est non signe est une
utilisation abusive, meme si j'en comprends suffisemment bien les raisons
pour penser que c'etait le bon choix a l'epoque; il y a un cout a
travailler avec un langage ayant plus de 30 ans d'histoire).

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
espie
In article ,
Jean-Marc Bourguet wrote:
Samuel DEVULDER writes:

candide a écrit :

> Ce qui m'ennuie c'est que p-s est de type ptrdiff_t, d'où ma question :
> Le code ci-dessus est-il portable ? N'y a-t-il pas risque d'overflow ?

Apparemment ptrdiff_t soulève en lui même d'autres risques:

http://blogs.msdn.com/david_leblanc/archive/2008/09/02/ptrdiff-t-is-evil.aspx



Le probleme, ce n'est pas ptrdiff_t, c'est l'utilisation abusive de non
signes. (Et oui, je pense que le fait que size_t est non signe est une
utilisation abusive, meme si j'en comprends suffisemment bien les raisons
pour penser que c'etait le bon choix a l'epoque; il y a un cout a
travailler avec un langage ayant plus de 30 ans d'histoire).



C'est helas extremement repandu, et criminel, d'expliquer les non-signes
sans donner les schemas d'utilisation qui vont avec. Mais, sauf si tu as
des mathematiciens, auxquels tu peux dire que "c'est de l'arithmetique
modulaire toute simple", il faut passer du temps sur le classique
if (abs(b-a) < 5)

qui foire d'office en non-signe, et reclame a haut cri une fonction/macro
absdiff(a, b) qui fera ce qu'il faut meme en non signe.

La solution, bien sur, c'est le principe de precaution: si je ne suis pas sur
du fonctionnement des choses, je passe par des types intermediaires qui
auront des comportements garantis.