Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C Futures page man str[n]cat

Futures page man str[n]cat

89 réponses
Avatar
Marc Boyer
Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.




STRCAT(3) Linux Programmer's Manual STRCAT(3)

NAME
strcat, strncat - concatenate two strings

SYNOPSIS
#include <string.h>

char *strcat(char *dest, const char *src);

char *strncat(char *dest, const char *src, size_t n);

DESCRIPTION
The strcat() function appends the src string to the dest
string, overwriting the null character (`\0') at the end of
dest, and then adds a terminating null character. The
strings may not overlap, and the dest string must have
enough space for the result.

The strncat() function is similar, except that

* it will use at most n characters from src; and

* src does not need to be null terminated if it contains n
or more characters.

As with strcat(), the resulting string in dest is always
null terminated.

If src contains n or more characters, strcat() writes n+1
characters to dest (n from src plus the terminating null
character). Therefore, the size of dest must be at least
strlen(dest)+n+1.

A simple implementation of strncat() might be:

char*
strncat(char *dest, const char *src, size_t n)
{
size_t dest_len = strlen(dest);
int i;

for(i = 0 ; i < n && src[i] != '\0' ; i++)
dest[dest_len + i] = src[i];
dest[dest_len + i] = '\0';
return dest;
}

RETURN VALUE
The strcat() and strncat() functions return a pointer to the
resulting string dest.

CONFORMING TO
SVr4, 4.3BSD, C89, C99.

SEE ALSO
bcopy(3), memccpy(3), memcpy(3), strcpy(3), strncpy(3),
wcscat(3), wcsncat(3)




--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Marc Boyer
Le 20-06-2007, Gabriel Dos Reis a écrit :
Marc Boyer writes:
| > -Wno-unused-parameter
|
| Tient, pourquoi donc ?
| Moi, je suis plutôt pour la démarche.
| void foo(int x, int y){
| (void) y; // unused parameter, parce que blabla...

Mon dieu !


Pourquoi ? Tu fais comment quand tu as un paramètre qui sert
plus à rien ?

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Avatar
espie
In article ,
Marc Boyer wrote:
Pourquoi ? Tu fais comment quand tu as un paramètre qui sert
plus à rien ?


C'est un des trucs ou j'ai toujours pas compris que le comite de
normalisation n'ait pas adopte la convention C++... ils sont
rapides pour prendre les mot-cles C++ et les re-adapter a la
sauce un peu plus cradingue (voir les incoherences de const et void *
en C), par contre, une construction aussi bete que

void
f(int x, int)
{
}


pas un pour la reprendre...

Avatar
espie
In article ,
Marc Boyer wrote:
Le 19-06-2007, Charlie Gordon a écrit :
"Marc Boyer" a écrit dans le message
de news:
Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.


Autant dire que la proposition a été vidée de sa substance.
Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes,
surtout strncpy !


C'est une page de man, pas un cours de C.


Ridicule, il y a une section USAGE, une section BUGS dans les pages de man.
Tu veux des exemples ?

Extrait de gets(3) sous OpenBSD:
BUGS
Since it is usually impossible to ensure that the next input line is less
than some arbitrary length, and because overflowing the input buffer is
almost invariably a security violation, programs should NEVER use gets().
The gets() function exists purely to conform to ANSI X3.159-1989 (``ANSI
C'').

Extrait de strncpy(3) sous OpenBSD:
The following sets chararray to ``abcdef'' and does not NUL terminate
chararray because the length of the source string is greater than or
equal to the length parameter. strncpy() only NUL terminates the desti-
nation string when the length of the source string is less than the
length parameter.

(void)strncpy(chararray, "abcdefgh", 6);

The following copies as many characters from input to buf as will fit and
NUL terminates the result. Because strncpy() does not guarantee to NUL
terminate the string itself, it must be done by hand.

char buf[BUFSIZ];

(void)strncpy(buf, input, sizeof(buf) - 1);
buf[sizeof(buf) - 1] = '';

Note that strlcpy(3) is a better choice for this kind of operation. The
equivalent using strlcpy(3) is simply:

(void)strlcpy(buf, input, sizeof(buf));

Extrait de malloc(3):
When using malloc() be careful to avoid the following idiom:

if ((p = malloc(num * size)) == NULL)
err(1, "malloc");

The multiplication may lead to an integer overflow. To avoid this,
calloc() is recommended.

et de realloc(3):
When using realloc() be careful to avoid the following idiom:

size += 50;
if ((p = realloc(p, size)) == NULL)
return (NULL);

Do not adjust the variable describing how much memory has been allocated
until the allocation has been successful. This can cause aberrant pro-
gram behavior if the incorrect size value is used. In most cases, the
above sample will also result in a leak of memory. As stated earlier, a
return value of NULL indicates that the old object still remains allocat-
ed. Better code looks like this:

newsize = size + 50;
if ((newp = realloc(p, newsize)) == NULL) {
free(p);
p = NULL;
size = 0;
return (NULL);
}
p = newp;
size = newsize;

Bon, apres, ca depend si tu veux laisser les gens libre de se pendre tout
seul. Le probleme, si tu ne mets pas ce genre de chose dans ta doc, c'est
que les *mauvais* exemples foisonnent...



Avatar
Marc Boyer
Le 20-06-2007, Gabriel Dos Reis a écrit :
Marc Boyer writes:

| Le 20-06-2007, Gabriel Dos Reis a écrit :
| > Marc Boyer writes:
| >| > -Wno-unused-parameter
| >|
| >| Tient, pourquoi donc ?
| >| Moi, je suis plutôt pour la démarche.
| >| void foo(int x, int y){
| >| (void) y; // unused parameter, parce que blabla...
| >
| > Mon dieu !
|
| Pourquoi ? Tu fais comment quand tu as un paramètre qui sert
| plus à rien ?

Je n'ecris pas ce que je considere une abomination, e.g. le cast
ci-dessus avec ou sans commentaire.


En quoi est-ce une abomination ? C'est une sorte de #pragma
popularisé par l'usage.

Je laisse le compilateur raler -- c'est une limitation stupide du langage.

Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais
je ne l'ecris pas dans mes propres codes.


Sauf que cet __attributte__ est spécifique à GCC non ?
Alors que le (void) est plus populaire, pour un résultat
semblable, non ?

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Avatar
Marc Boyer
Le 20-06-2007, Marc Espie a écrit :
In article ,
Marc Boyer wrote:
Le 19-06-2007, Charlie Gordon a écrit :
"Marc Boyer" a écrit dans le message
de news:
Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.


Autant dire que la proposition a été vidée de sa substance.
Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes,
surtout strncpy !


C'est une page de man, pas un cours de C.


Ridicule, il y a une section USAGE, une section BUGS dans les pages de man.
Tu veux des exemples ?


Non, non, je te crois.

Bon, apres, ca depend si tu veux laisser les gens libre de se pendre tout
seul. Le probleme, si tu ne mets pas ce genre de chose dans ta doc, c'est
que les *mauvais* exemples foisonnent...


Disons que ce n'est pas vraiment 'ma' doc.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)




Avatar
espie
In article ,
Gabriel Dos Reis wrote:
Marc Boyer writes:

| Disons que ce n'est pas vraiment 'ma' doc.

Mais tu es en train de la changer, de l'ameliorer.


Non, non, c'est l'esprit linux. On ne veut surtout pas froisser
les gens et on reste dans le consensuel. Tu sais, c'est ce cher modele
de developpement dit `foutoir', euh, `bazar'...

Avatar
Gabriel Dos Reis
Marc Boyer writes:


[...]

| >| > Je laisse le compilateur raler -- c'est une limitation stupide du langage.
| >| >
| >| > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais
| >| > je ne l'ecris pas dans mes propres codes.
| >|
| >| Sauf que cet __attributte__ est spécifique à GCC non ?
| >| Alors que le (void) est plus populaire, pour un résultat
| >| semblable, non ?
| >
| > Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code
| > populaire. J'essaie d'ecrire du code simple, correcte, lisible et
| > maintenable. (Je n'y arrive pas toujours, mais j'essaie).
|
| Pour ma part, beaucoup plus simplement, quand il y a un paramètre
| inutile dans une signature, je change la signature.

Cela n'est pas toujours possible -- ou alors, possible mais avec
encore plus de monstruosites. Par exemple, considere le cas des
frameworks ou des callbacks. Le type des functions est fige par
le concepteur du framework, et les arguments passes aux callbacks ne
sont pas forcement utilises.

| Mais il semble que dans l'industrie, une fois qu'on a fixé une
| interface, on répugne à la faire bouger.

Cela n'est pas seulement de la repugnance -- et on n'a pas forcement
besoin d'aller dans l'industrie pour trouver cela, bien que
l'industrie est plus grande productrice et consomatrice de frameworks.

| Donc, on a ces 'unused parameters'. Qu'en fait-on ?

Comme je l'ai observe plus tot, soit on change de langage, soit on
laisse le warning car c'est un cas legitime ou le warning n'est le que
le reflet d'une limitation stupide du langage. Mutiler le code (avec
ou sans commentaire) ne fait qu'empirer une situation deja pas rose,
si tu veux mon avis.

| Si on demande au compilo de ne rien
| dire, on peut passer à côté de vrais problème. Si on demande
| au compilo de détecter, à chaque passe, il va râler à chaque
| compilation.

Si le nombre de fois ou le compilateur rale est superieur au nombres
de problemes detectes, il y a un probleme avec le framework qu'on
utilise et il est temps de repenser.

| Le coup du (void) me semblait neutre: ajouté au coup
| par coup par le programmeur, et sans impact sur le code
| généré.
| Quel désavantage ? Il surprend le débutant.

Comme je l'ai dit plus tot, je voudrais du code simple, correcte,
maintenable ou j'exprime directement les idees.
Si le code est simple, correcte et maintenable sans la mutilation,
alors je considere que la mutilation n'est pas seulement un bruit de
fond mais une entrave.

-- Gaby
Avatar
Marc Boyer
Le 20-06-2007, Gabriel Dos Reis a écrit :
Marc Boyer writes:

| Disons que ce n'est pas vraiment 'ma' doc.

Mais tu es en train de la changer, de l'ameliorer.


Oui, mais le type qui décide de ce qui y sera et n'y sera
pas, c'est pas moi. J'ai fait une proposition, elle est en partie
passée.
Après, si quelqu'un pense pouvoir être plus convainquant
que moi pour faire passer la partie 'BUG', je peux lui
dire qui contacter.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Mais si cela génère une dizaine de warning à chaque compilation,

Comment cels se fait-il que tu les as a chaque compilation ? Mauvais
decoupage de ton projet ?

| > Mutiler le code (avec
| > ou sans commentaire) ne fait qu'empirer une situation deja pas rose,
| > si tu veux mon avis.
|
| Ben, je ne vois pas en quoi c'est une mutilation.

Ce n'est pas grave : tu m'as demande pourquoi c'est une abomination ;
je t'ai donne mes raisons. Nous n'avions pas l'hypothese que nous
avions les mes yeux -- autrement nous ne serions pas la a en parler.

-- Gaby
Avatar
Marc Boyer
Le 20-06-2007, Gabriel Dos Reis a écrit :
Marc Boyer writes:
| Le 20-06-2007, Gabriel Dos Reis a écrit :
| > Marc Boyer writes:
| >
| >| Le 20-06-2007, Gabriel Dos Reis a écrit :
| >| > Marc Boyer writes:
| >| >| > -Wno-unused-parameter
| >| >|
| >| >| Tient, pourquoi donc ?
| >| >| Moi, je suis plutôt pour la démarche.
| >| >| void foo(int x, int y){
| >| >| (void) y; // unused parameter, parce que blabla...
| >| >
| >| > Mon dieu !
| >|
| >| Pourquoi ? Tu fais comment quand tu as un paramètre qui sert
| >| plus à rien ?
| >
| > Je n'ecris pas ce que je considere une abomination, e.g. le cast
| > ci-dessus avec ou sans commentaire.
|
| En quoi est-ce une abomination ? C'est une sorte de #pragma
| popularisé par l'usage.

C'est probablement parce que je n'ai pas l'imagination assez debordante
pour voir cela comme une "sorte de pragma popularise par l'usage" que
je trouve que c'est une abomination. Et je trouve aussi que les
pragmas sont des abominations, alors je ne suis pas sure que ce soit
une analogie qui m'aidera beaucoup.


ok

| > Je laisse le compilateur raler -- c'est une limitation stupide du langage.
| >
| > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais
| > je ne l'ecris pas dans mes propres codes.
|
| Sauf que cet __attributte__ est spécifique à GCC non ?
| Alors que le (void) est plus populaire, pour un résultat
| semblable, non ?

Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code
populaire. J'essaie d'ecrire du code simple, correcte, lisible et
maintenable. (Je n'y arrive pas toujours, mais j'essaie).


Pour ma part, beaucoup plus simplement, quand il y a un paramètre
inutile dans une signature, je change la signature.

Mais il semble que dans l'industrie, une fois qu'on a fixé une
interface, on répugne à la faire bouger. Donc, on a ces 'unused
parameters'. Qu'en fait-on ? Si on demande au compilo de ne rien
dire, on peut passer à côté de vrais problème. Si on demande
au compilo de détecter, à chaque passe, il va râler à chaque
compilation.

Le coup du (void) me semblait neutre: ajouté au coup
par coup par le programmeur, et sans impact sur le code
généré.
Quel désavantage ? Il surprend le débutant.
Tu en vois d'autre ?

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

1 2 3 4 5