Les chaines de caractères en C

http://nicolasj.developpez.com/articles/libc/string/

Citation:

---

Après un rappel sur la structure des chaines de caractères en C et un aperçu des fonctions de la bibliothèque standard servant à manipuler ces chaines, je vous propose de créer notre propre bibliothèque de manipulation des chaines de caractères.

---

Vous pouvez laisser un commentaire sur cet article à la suite.

Citation:

---

Envoyé par gege2061

Les chaînes de caractères sont en fait stockées dans un tableau de caractères

---

Il n'y a pas de 'caractères'. C'est un tableau d'entiers de type char.

"Les chaînes de caractères sont en fait stockées dans un tableau de char"

Citation:

---

de code ASCII

---

Il n'y a pas de 'code ASCII ' en C. une chaine est terminée par un caractère valant 0 (ou '\0' en octal ou '\x0' en hexadécimal, si on aime la complication).

Le fait qu'il ait la même valeur que le NUL du charset ASCII est un détail d'implémentation qui ne nous intéresse pas dans une théorie générale sur le langage C.

\0 n'existe pas en C. C'est '\0'.

Citation:

---

toute modification de la chaîne s3 se conclura par une erreur de segmentation

---

Non. Ça se traduira par un comportement indéterminé.

Ca fait déjà beaucoup d'imprécisions... J'ai pas trop envie de continuer...

Je propose :

"<...> dont la fin est marquée par un caractère nul, de valeur 0 et représenté par le caractère '\0' ou '\x0' ou la valeur 0 directement.

Nota : le chiffre 0 (zéro) est le caractère '0'. Sa valeur dépend du charset utilisé (en ASCII, 48 décimal)"

Corrigé selon tes conseils.

:merci:

Citation:

---

Envoyé par gege2061

Corrigé selon tes conseils.

:merci:

---

OK.

Citation:

---

II-N. strtok

---

Tu parles de 'ct', mais le paramètre est 't'...

Citation:

---

III-A. Modifier la case d'une chaîne de caractère

---

ces fonctions retournant un espace alloué, j'aurais mis un suffixe _dyn ...

Code:

---

1 2	char *str_tolower_dyn (char const *s); char *str_toupper_dyn (char const *s)

---

;

ou un rappel à strdup() ...

Code:

---

1 2	char *str_dup_tolower (char const *s); char *str_dup_toupper (char const *s);

---

avec un rappel à 'free()'...

j'aurais aussi prévu le cas plus simple de la chaine modifiable :

Code:

---

1 2	char *str_tolower (char *s); char *str_toupper (char *s);

---

Bonjour,

Je passais par ici par hasard. Je vois bien que l'exemple date un peu...
Une remarque sur les exemples de code donnés, comme par exemple celui-ci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

char *str_tolower (const char *ct) { char *s = NULL; if (ct != NULL) { int i; s = malloc (sizeof (*s) * (strlen (ct) + 1)); if (s != NULL) { for (i = 0; ct[i]; i++) { s[i] = tolower (ct[i]); } s[i] = '\0'; } } return s; }

---

Je crois que c'est une mauvaise idée de montrer à des débutants des exemples de fonctions structurées comme celle-ci. Une fonction est responsable de l'utilisation qu'elle fait de la mémoire. Donc si une fonction alloue de la mémooire avec un malloc, elle doit la libérer avec un free abant de sortir.

En conséquence, une fonction comme celle-ci ne peut pas renvoyer son résultat sous forme d'une chaine de caractère qu'elle a allouée sur le tas. C'est une mauvaise pratique. La responsabilité d'allouer de la mémoire revient à l'appellant de la fonction, pas à la fonction elle-même.

La solution la plus simple est de faire la modification sur la chaine en place. Sil l'appelant veut garder l'original, libre à lui de faire une copie avant :

Code:

---

1 2 3 4 5 6

void to_upper(char *c) { for (; *c; ++c) if (*c >= 'a' && *c <= 'z') *c += 'A' - 'a'; }

---

Une autre solution, pas très satisfaisante, est de prendre deux arguments, l'un en entrée, l'autre en sortie. Un peu moche.

Code:

---

1 2 3 4 5

void to_upper(const char *in, char *out) { for (; *in; ++in, ++out) *out = *in + (*in >= 'a' && *in <= 'z' ? 'A' - 'a' : 0); }

---

Voilà. C'est juste mon grain de sel...

Citation:

---

Envoyé par ol9245

Bonjour,

Je passais par ici par hasard. Je vois bien que l'exemple date un peu...
Une remarque sur les exemples de code donnés, comme par exemple celui-ci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

char *str_tolower (const char *ct) { char *s = NULL; if (ct != NULL) { int i; s = malloc (sizeof (*s) * (strlen (ct) + 1)); if (s != NULL) { for (i = 0; ct[i]; i++) { s[i] = tolower (ct[i]); } s[i] = '\0'; } } return s; }

---

Je crois que c'est une mauvaise idée de montrer à des débutants des exemples de fonctions structurées comme celle-ci. Une fonction est responsable de l'utilisation qu'elle fait de la mémoire.

---

Comme malloc() ? Ou fopen () ?

J'ai bien insisté que le fait que la fonction allouait un bloc et qu'il fallait le libérer après usage. C'est la seule façon de faire des copies de chaines réentrantes, ce qui permet le multi-tâche ...

Citation:

---

Donc si une fonction alloue de la mémoire avec un malloc, elle doit la libérer avec un free avant de sortir.

---

Dans ce cas, une variable locale devrait suffire ...

Citation:

---

En conséquence, une fonction comme celle-ci ne peut pas renvoyer son résultat sous forme d'une chaine de caractère qu'elle a allouée sur le tas. C'est une mauvaise pratique. La responsabilité d'allouer de la mémoire revient à l’appelant de la fonction, pas à la fonction elle-même.

---

Voilà une position bien dogmatique. Il faudra en parler à celui qui a écrit fopen() ...

Dans la pratique évidemment qu'on passe son temps à allouer ici et à libérer là. Certes ça demande quelques efforts de programmation et des outils de vérification (j'ai même fini par en écrire un, voir ma bibliothèque CLIB), mais c'est le seul moyen d'être efficace et de ne pas passer son temps à recopier des données qui peuvent parfois être longues ...

Même si tu utilises un système plus symétrique qui ressemble à de la programmation objet (ADT), il y a quand même un fonction de création de l'objet et une fonction de destruction de celui-ci. Le fait que l'on contrôle manuellement la destruction permet de créer des objet dynamiques persistants (le temps de leur utilisation et dans n'importe quel tâche).

Sur ce, moi je suis musicien, maintenant, alors ces problèmes là, je m'en tape un peu, là ...

Citation:

---

Dans ce cas, une variable locale devrait suffire ...

---

Bonjour, à ma connaissance, contrairement aux langages disposant d'un système de "garbage collector", la mémoire allouée par malloc a besoin d'être libérée avant la perte de sa référence, en l'occurrence, la variable locale contenant l'adresse de cette mémoire... sinon c'est la fuite (en avant) de mémoire assurée.
En C: 1 malloc => 1 free

den75,
Quand ol9245 a énoncé la règle générale :

Citation:

---

si une fonction alloue de la mémooire avec un malloc, elle doit la libérer avec un free abant de sortir

---

et que Emmanuel Delahaye avait répondu :

Citation:

---

Dans ce cas, une variable locale devrait suffire

---

il ne proposait pas d'appeler malloc sans appeler free, mais d'allouer une variable automatique, qui sera donc automatiquement désallouée quand on sortira de la portée de cette variable.

Cependant, quand la taille à allouer est inconnue à la compilation, il vaut souvent mieux allouer avec malloc que d'allouer un VLA (Variable Length Array) ou d'appeler une fonction non standard comme alloca.

A part ça, de mon côté, je ne suis pas toujours contre les fonctions qui appellent malloc et demandent à l'utilisateur de la fonction d'appeler eux-même free. Mais, pour éviter les fuites mémoires, il faut utiliser une convention. Par exemple, j'aime bien le suffixe "_dyn" proposé par Emmanuel Delahaye.

Par contre, pour une fonction qui convertit une chaîne en minuscules, je n'aurais pas fait d'allocation dans le tas. J'aurais fait comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <ctype.h> #include <stdio.h>   void MyProject_str_to_tolower(char* restrict dest, const char* restrict src) { for(; *src != '\0'; ++src, ++dest) *dest = tolower(*src); *dest = '\0'; }   int main() { const char src[] = "Hello world!"; char dest[sizeof(src)]; // L'utilisateur est libre d'allouer la chaîne résultante dans la pile. MyProject_str_to_tolower(dest, src); printf("%s", dest); return 0; }

---

C'est proche de ce la solution que ol9245 avait qualifiée de moche, mais je ne trouve pas ça moche.

Edit 2017-01-25-17h27 : Conversion en majuscules remplacée par une conversion en minuscules pour mieux coller aux précédents messages du fil.

Bonsoir, La discussion date cependant je peut-être apporté quelque précision sans trop lancé de débats.

Citation:

---

Envoyé par Emmanuel Delahaye

Non. Ça se traduira par un comportement indéterminé.

---

Je pense qu'il n'y a pas de comportement indéterminé en soi, mais il y a bien un segment défaut justifier .
Je m’explique. Ici s3 const char *s3 = "Développez"; est un pointeur constant sur une chaîne constante. Lors de la phase de compilation toute modification sur s3 sera interdite et la compilation échouera, car l’erreur a été décelé, mais dans le cas contraire "char *s3 = "Développez" le compilateur placera la chaîne constante dans un segment de données en lecture seule et toute tentative de modification à travers ce pointeur aboutira systématiquement à une erreur de segmentation donc pour une variable pointeur sur une chaîne constante on aura systématiquement une erreur de segmentation et non un comportement indéterminé.

Cas compilation avec const

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <stdio.h> #include <stdlib.h>   int main( void ){   const char *ptr = "Bonjour"; ptr[2] = 'Z'; return EXIT_SUCCESS; }

---

Code:

---

1 2 3 4 5

root@mv:~# gcc *.c -Wall -Werror -g -o Deb source.c: In function 'main': source.c:7:9: error: assignment of read-only location '*(ptr + 2u)' ptr[2] = 'Z';

---

Cas compilation sans const

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <stdio.h> #include <stdlib.h> int main( void ){ char *ptr = "Bonjour"; ptr[2] = 'Z'; <<< Thread 1: address access protected (fault address: 0x400566) return EXIT_SUCCESS; }

---

Code:

---

1 2 3 4

root@mv:~# gcc *.c -Wall -Werror -g -o Deb root@mv:~# ./Deb Segmentation fault

---

à bientôt.

Citation:

---

il ne proposait pas d'appeler malloc sans appeler free, mais d'allouer une variable automatique, qui sera donc automatiquement désallouée quand on sortira de la portée de cette variable.

---

Oui, bien sûr. J'avais mal lu et le code de départ et les commentaires.
Maintenant concernant le choix entre:

Méthode 1:

Code:

---

1 2 3 4 5 6 7 8

void Appelant() { char src[]="Hello"; char dst[LENGTH];   StrManip(src,dst); ... }

---

ou

Méthode 2:
void Appelant()

Code:

---

1 2 3 4 5 6 7

{ char src[]="Hello"; char *dst=StrManip(src); ... free(dst); ... }

---

Je pense que si LENGTH est prédictible voire simplement bornée alors il faut choisir la Méthode 1
Mais dans le cas où la taille mémoire demandée pour le résultat est "trop variable" alors la Méthode 2 peut faire sens.

Citation:

---

Envoyé par sambia39

Je pense qu'il n'y a pas de comportement indéterminé en soi, mais il y a bien un segment défaut justifier .
[...]
mais dans le cas contraire "char *s3 = "Développez" le compilateur placera la chaîne constante dans un segment de données en lecture seule et toute tentative de modification à travers ce pointeur aboutira systématiquement à une erreur de segmentation donc pour une variable pointeur sur une chaîne constante on aura systématiquement une erreur de segmentation et non un comportement indéterminé.

---

C'est bien un comportement indéterminé https://www.securecoding.cert.org/co...+qualification

Il n'y a pas obligatoirement d'erreur de segmentation. Par exemple, j'ai constaté que sur certains MCU, si tu essayes d'écrire à une adresse qui pointe vers de la mémoire flash, ça n'a juste pas d'effet.

Citation:

---

Envoyé par sambia39

mais dans le cas contraire "char *s3 = "Développez" le compilateur placera la chaîne constante dans un segment de données en lecture seule

---

Je pense que ceci n'est pas vrai. Je ne vois nul part dans la norme du langage qu'une chaîne définie par char* doit se trouver en mémoire en lecture seule. Je sais que c'est souvent ce qui se passe et pour résoudre le souci, on fait souvent char s3[] = "Développez" si on veut modifier la chaîne mais je ne suis pas sûr que la norme le force vu que le C est utilisé sur des architectures qui n'ont pas de section lecture seule.

Mais j'ai un doute donc je pose la question :) Si j'ai raison, alors il vaut mieux dire "souvent" que toujours.

Concrêtement, ce n'est pas char* qui peut y être placée, ca c'est une variable sans importance pour la question.
C'est la chaine litérale. Et encore, la norme ne l'impose pas. Je crois qu'elle n'impose même pas l'existence d'une mémoire dédiée à ce type d'objet.
Elle pourrait tout aussi bien être dans le tas, ou en bas de la pile.

La norme précise qu'il s'agit d'un UB si on tente de modifier les chaînes littérales. Ce qui est requis est qu'une telle chaîne soit stockée dans un tableau statique de la bonne longueur (pas plus, pas moins) → norme C11 6.4.5 String literals.

Code:

---

1 2 3 4 5

char *ptr="hello world"; // ptr pointe sur le premier caractère du littéral *ptr='H'; // UB !   char arr[]="hello world"; // on copie le littéral dans le tableau arr[0]='H'; // OK

---

Dans le code précédent, la norme n'oblige en rien à avoir le littéral "hello world" en read only, ni même à n'avoir qu'une version de ce littéral ni même plusieurs.
Le fait est qu'une optimisation courante est d'avoir des chaînes littérales en read only (plus contraignant qu'un const) simplement pour pouvoir gagner de la place et fusionner plusieurs chaînes dans un même tableau. gcc proposait un option il y a quelques années pour «rendre» ces chaînes écrivables (?) mais cette option a été enlevée. La tendance est de forcer une plus grande const correctness→-Wwrite-strings (pour autant que ce soit utile et cohérent en C). Du coup on voit souvent :

Code:

---

1 2 3

const char *ptr="hello world"; // à la place de char *ptr="hello world";

---

:merci: picodev :)

Bonsoir,

Citation:

---

Envoyé par Bktero

C'est bien un comportement indéterminé https://www.securecoding.cert.org/co...+qualification.....

---

Citation:

---

Envoyé par fearyourself

Je pense que ceci n'est pas vrai. Je ne vois nul part dans la norme du langage qu'une chaîne définie par char* doit se trouver en mémoire en lecture seule. Je sais que c'est souvent ce qui se passe et pour résoudre le souci, on fait souvent char s3[] = "Développez" si on veut modifier la chaîne mais je ne suis pas sûr que la norme le force vu que le C est utilisé sur des architectures qui n'ont pas de section lecture seule.

Mais j'ai un doute donc je pose la question :) Si j'ai raison, alors il vaut mieux dire "souvent" que toujours.

---

J’ai écrit que cela n’est pas un comportement indéterminé à cause de ce qui se trouve sous le capot.
Alors comment se présentent les choses : dans un premier temps on va décompiler l’exécutable afin de déterminer où est-ce que notre variable pointeur sur chaîne constante se trouve-t-il, mais également savoir si le segment mémoire ou se trouve cette variable peut-être lue et modifiée

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

root@mv:~# objdump -Sr source.o && readelf -l Deb source.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <main>: #include <stdio.h> #include <stdlib.h> int main( void ){ 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp char *ptr = "DEBUG_TEST"; 4: 48 c7 45 f8 00 00 00 movq $0x0,-0x8(%rbp) b: 00 8: R_X86_64_32S .rodata *(ptr) = 'A'; c: 48 8b 45 f8 mov -0x8(%rbp),%rax 10: c6 00 41 movb $0x41,(%rax) return EXIT_SUCCESS; 13: b8 00 00 00 00 mov $0x0,%eax } 18: 5d pop %rbp 19: c3 retq Elf file type is EXEC (Executable file) Entry point 0x4003c0 There are 8 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 0x00000000000001c0 0x00000000000001c0 R E 8 INTERP 0x0000000000000200 0x0000000000400200 0x0000000000400200 0x000000000000001c 0x000000000000001c R 1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x000000000000068c 0x000000000000068c R E 200000 LOAD 0x0000000000000690 0x0000000000600690 0x0000000000600690 0x0000000000000228 0x0000000000000230 RW 200000 DYNAMIC 0x00000000000006a8 0x00000000006006a8 0x00000000006006a8 0x00000000000001d0 0x00000000000001d0 RW 8 NOTE 0x000000000000021c 0x000000000040021c 0x000000000040021c 0x0000000000000044 0x0000000000000044 R 4 GNU_EH_FRAME 0x0000000000000560 0x0000000000400560 0x0000000000400560 0x0000000000000034 0x0000000000000034 R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 03 .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 04 .dynamic 05 .note.ABI-tag .note.gnu.build-id 06 .eh_frame_hdr 07 root@mv:~#

---

Observerez ci-dessus que la chaîne constante a été placer dans (mon cas) dans .RODATA. ( Read-Only Data) en clair donné constant en lecture seule. Qui est une zone distinguée du segment de données "si je peux dire ainsi" On distingue également que cette zone permet la lecture et l’exécution, mais pas l’écriture donc essayer de modifier l’élément qui se trouve dans cette zone débouche systématiquement sur une erreur de segmentation (sous UNIX tout comme GNU/LINUX et Mac Os); ce qui justifie le segment défaut et que nous n’avons pas affaire à un comportement indéterminé, mais bien une erreur de segmentation par ce que l’on a voulu écrire dans une zone qui ne nous est pas autorisée.

Pour ce qui est de UB @picodev a bien expliquer là choses
à bientôt@

Histoire qu'on soit clair: je discutais juste du fait que la phrase disait : le compilateur place les char *s = "blah" dans une zone lecture seule. Et je voulais juste faire noter que cela n'est pas toujours le cas.

Dans 99% des systèmes, ce que tu as dit est vrai :)