Le problème est pas avec l'écriture, il est à la lecture - la conversion scanf
saute %s
éventuels blancs, puis lit et convertit jusqu'à (mais sans inclure) l'espace blanc suivant.
Vous souhaitez probablement utiliser quelque chose comme fgets
ou la conversion %[^\n]
avec scanf
.
Editer: Je devrais probablement aussi mentionner que lorsque/si vous utilisez la conversion scanset (%[^\n]
), vous devez spécifier la longueur du tampon que vous lisez. En ce qui concerne le &buffer
en scanf("%s", &buffer);
étant une erreur, techniquement, il donne un comportement indéfini, mais en réalité, je ne connais aucune implémentation où cela fait une réelle différence.
Dans ce cas, buffer
a été défini comme un tableau, pas un pointeur. Le nom d'un tableau "se décompose" en un pointeur dans de nombreuses circonstances, mais pas lorsqu'il est utilisé comme l'opérande de l'opérateur adresse-de (unaire &
). En tant que tel, buffer
et &buffer
donnent exactement le même résultat, l'adresse du début du tableau.
Il y a quand même une différence. Lorsque vous utilisez juste buffer
, vous obtenez une valeur avec le type pointer to char
(étant donné que le tampon est un tableau de char). Lorsque vous utilisez &buffer
, vous obtenez un pointeur du type pointer to array of MAXLEN char
. Maintenant, lorsque vous passez une valeur à scanf (une fonction variadique), vous obtenez un comportement indéfini quand/si le type de la valeur que vous transmettez ne correspond pas au type attendu par la conversion que vous avez spécifiée. En réalité, avec tous les compilateurs C dont j'ai entendu parler, ça marchera bien, parce que la même adresse sera transmise de toute façon. En théorie (mais seulement en théorie, AFAIK) un compilateur pourrait pourrait utiliser une sorte de "gros pointeur" qui incluait des informations de type avec l'adresse, donc scanf
serait capable de détecter le désaccord de type. En réalité, je ne connais pas de compilateur qui fasse quelque chose de très similaire, donc vous ne verrez aucune différence entre l'utilisation de buffer
et l'utilisation de &buffer
dans ce cas.
Dans d'autres circonstances, cependant, la différence peut être détectable. Addition et la soustraction sur les pointeurs sont basées sur le type, donc (par exemple) array+1
et &array + 1
donneront des résultats différents:
#include <stdio.h>
int main() {
char array[10];
printf("%p %p %p\n", array, array+1, &array+1);
return 0;
}
Cela affichera trois numéros. Le premier nombre sera un nombre arbitraire, généralement en hexadécimal. Le second sera un plus grand que le premier, et le second sera 10 plus grand que le premier (parce que je l'ai défini comme un tableau de 10 caractères ...)
Indice: que se passe-t-il lorsque l'utilisateur tape plus de 100 caractères? –
Je pense, les caractères de plus de 100 ne sauveront pas. Ça ne va pas apparaître. Ai-je raison? Est-ce que cela a quelque chose à voir avec mon problème? – Devyn
Non - si l'utilisateur entre plus de 100 caractères, les caractères seront lus, écrasant tout ce qui se trouve en mémoire près du 'buffer' que vous avez attribué. C'est à dire. c'est le "buffer overrun" notoirement utilisé dans presque tous les vers, chevaux de Troie, virus, etc. –