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

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)

10 réponses

5 6 7 8 9
Avatar
Jean-Marc Bourguet
"Charlie Gordon" writes:

Hier, au détour d'une conversation de geek au resto, j'ai découvert un cas
ou (*p) n'est pas équivalent à (p[0]).


Hors macro? Ca m'interesse.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Charlie Gordon
"Jean-Marc Bourguet" a écrit dans le message de news:

"Charlie Gordon" writes:

Hier, au détour d'une conversation de geek au resto, j'ai découvert un
cas
ou (*p) n'est pas équivalent à (p[0]).


Hors macro? Ca m'interesse.


Je confirme : hors macros, et même de deux façons apparentées mais
différentes.
la question est donc : quelle est la définition de p ?

Chqrlie.


Avatar
Stéphane Goujet
Le Thu, 28 Jun 2007 09:27:52 +0200
"Charlie Gordon" a écrit:

Hier, au détour d'une conversation de geek au resto, j'ai découvert
un cas ou (*p) n'est pas équivalent à (p[0]).


Si p pointe sur un NaN ?
Non, vous parlez d'équivalence, pas d'égalité, ça ne doit pas ê tre ça.

--
Stéphane Goujet.

Avatar
Jean-Marc Bourguet
"Charlie Gordon" writes:

"Jean-Marc Bourguet" a écrit dans le message de news:

"Charlie Gordon" writes:

Hier, au détour d'une conversation de geek au resto, j'ai découvert un
cas
ou (*p) n'est pas équivalent à (p[0]).


Hors macro? Ca m'interesse.


Je confirme : hors macros, et même de deux façons apparentées mais
différentes. la question est donc : quelle est la définition de p ?


int p();
int (*p)();

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org



Avatar
Charlie Gordon
"Jean-Marc Bourguet" a écrit dans le message de news:

"Charlie Gordon" writes:

"Jean-Marc Bourguet" a écrit dans le message de news:

"Charlie Gordon" writes:

Hier, au détour d'une conversation de geek au resto, j'ai découvert un
cas
ou (*p) n'est pas équivalent à (p[0]).


Hors macro? Ca m'interesse.


Je confirme : hors macros, et même de deux façons apparentées mais
différentes. la question est donc : quelle est la définition de p ?


int p();
int (*p)();


Tout à fait.
Ce qui a comme conséquence qu'on ne peut pas écrite des horreurs gratuites
comme :

void *p = 0[malloc](n); /* does not compile */

Chqrlie.




Avatar
Jean-Marc Bourguet
"Charlie Gordon" writes:

Ce qui a comme conséquence qu'on ne peut pas écrite des horreurs gratuites
comme :

void *p = 0[malloc](n); /* does not compile */


Je dois dire que ca me desole un peu... je commence a me sentir bride dans
ma creativite.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Thierry B.
--{ Charlie Gordon a plopé ceci: }--


Je pense la même chose.
Hier, au détour d'une conversation de geek au resto, j'ai découvert un cas
ou (*p) n'est pas équivalent à (p[0]).

Hélas, la marge de la nappe était trop étroite...



--
- Le monde appartient à ceux dont les ouvriers se lèvent tôt. (Coluche)

Avatar
Charlie Gordon
"Thierry B." a écrit dans le message de news:

--{ Charlie Gordon a plopé ceci: }--


Je pense la même chose.
Hier, au détour d'une conversation de geek au resto, j'ai découvert un
cas
ou (*p) n'est pas équivalent à (p[0]).

Hélas, la marge de la nappe était trop étroite...



Pourtant la démonstration en était merveilleuse ;-)

Chqrlie.


Avatar
Ael Rowan Terence
"Charlie Gordon" a écrit dans le message de
news:46826773$0$10944$
"Ael Rowan Terence" a écrit dans le message de news:
f5tmrv$mnm$

Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que
le


compilateur ne detecte pas :
if ( n=0 )

A la place de
if ( n==0)

Avec l'erreur de frappe le programme va compilé, et va même donner
l'illusion de fonctionner sauf que le résultat est faux.


Si ton compilateur ne proteste pas sur cette ligne, c'est qu'il est mal
configuré. Il faut impérativement passer les bonnes options au
compilateur


C'est justement l'avantage de écriture if (0=n).

Car, même, dans le cas d'un compilateur desuet, ou mal configuré, l'erreur
sera mentionnée.
Alors que l'ecriture que tu préferres risque de passer inaperçu dans
certains cas.


Nonobstant, je suis d'accord avec toi, il vaut mieux disposer des meilleurs
outils correctement parametrés. Mais est-ce, partout et tout le temps,
possible ?


Avatar
Charlie Gordon
"Ael Rowan Terence" a écrit dans le message de news:
f7l37m$v07$

"Charlie Gordon" a écrit dans le message de
news:46826773$0$10944$
"Ael Rowan Terence" a écrit dans le message de news:
f5tmrv$mnm$

Pardon , je n'ai pas été clair, je parle de cette erreur de frappe, que
le


compilateur ne detecte pas :
if ( n=0 )

A la place de
if ( n==0)

Avec l'erreur de frappe le programme va compilé, et va même donner
l'illusion de fonctionner sauf que le résultat est faux.


Si ton compilateur ne proteste pas sur cette ligne, c'est qu'il est mal
configuré. Il faut impérativement passer les bonnes options au
compilateur


C'est justement l'avantage de écriture if (0=n).


C'est le seul avantage de cette écriture, mais cet avantage est illusoire
puisqu'il suffit de configurer correctement son environnement de compilation
pour obtenir le warning utile et bien d'autres encore. De plus, je trouve
que les inconvénents en termes de lisibilité sont significatifs, mais cette
opinion est personnelle.

Car, même, dans le cas d'un compilateur desuet, ou mal configuré, l'erreur
sera mentionnée.


Pourquoi tolérer que le compilateur soit mal configuré ? Bien d'autres
erreurs passeront inaperçues avec de telles méthodes.
Quel environnement désuet ne supporte pas un tel niveau d'avertissements ?
Je pratique le C depuis plus de 25 ans, cela fait au moins 15 ans que je
n'ai plus vu d'environnement dans lequel je ne puisse pas configurer ou
installer les outils minimaux pour programmer avec des méthodes saines.

Alors que l'ecriture que tu préferres risque de passer inaperçu dans
certains cas.


Je ne vois pas dans quels cas ?

Nonobstant, je suis d'accord avec toi, il vaut mieux disposer des
meilleurs
outils correctement parametrés. Mais est-ce, partout et tout le temps,
possible ?


Je prétends que oui.

Chqrlie.



5 6 7 8 9