scanf et fgets

Le
Julien
bonjour

Je fais actuellement les exercices de http://www.france-ioi.org/
d'ailleurs si vous avez d'autres sites avec des exercices, je suis
intéressé.

Je me posais la question, un scanf est-il dangereux pour récupérer un
entier saisi par l'utilisateur.

est ce que :

char chaine[1000];
signed int valeur;

(void) fgets(chaine, (int) sizeof(chaine), stdin);
valeur = atoi(chaine);

est plus sûr que

signed int valeur;
scanf("%i",&valeur);

d'autant que là je ne peux pas mettre connaître la taille maximale de
l'entier.

J'ai essayé un char chaine[INT_MAX] mais ça n'a pas compilé.

Merci de vos avis.

--
Julien <Juke@free.fr>
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Stephane Legras-Decussy
Le #997536
"Julien"
Je me posais la question, un scanf est-il dangereux pour récupérer un
entier saisi par l'utilisateur.


http://mapage.noos.fr/emdel/inputs.htm

le reste du site est de la même qualité...
à lire et relire... :-)

Thierry PINELLI
Le #997535
Julien wrote:

bonjour


bonjour

signed int valeur;
signed int valeur;


que dit la norme au sujet de ce type ?

Julien
Le #997534

signed int valeur;
signed int valeur;


que dit la norme au sujet de ce type ?


j'ai cherché un petit peu, je n'ai pas trouvé. y'a une contre
indication ?

J'ai regardé dans la faq et fait un coup de "signed int" + C99 sur
google.

--
Julien

Thierry PINELLI
Le #997533
Julien wrote:

signed int valeur;
signed int valeur;
que dit la norme au sujet de ce type ?



j'ai cherché un petit peu, je n'ai pas trouvé. y'a une contre
indication ?


je pense que le type 'int' est, sauf indication contraire, "signed"

qui a déja vu : signed int main() ???



Mickaël Wolff
Le #997532
je pense que le type 'int' est, sauf indication contraire, "signed"


Ça dépend de la machine, et du choix d'implémentation du compilateur.

FAQ très intéressante :

qui a déja vu : signed int main() ???


Pourquoi pas ? Mais dans ce cas, je mettrais signed main () pour
porter à confusion :p

Bref, comme toujours, tu as fait le choix de l'a priori, comme nous le
faisons tous ;) Les programmeurs sont incorrigibles.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

gl
Le #997531
je pense que le type 'int' est, sauf indication contraire, "signed"


Ça dépend de la machine, et du choix d'implémentation du compilateur.



Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.


Mickaël Wolff
Le #997378
Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.


C'est la même chose, ce sont des entiers tout les deux. Il y a un qui
est juste de taille déterminée. Mais en lisant bien une seconde fois, tu
verras que le char n'est traité qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

espie
Le #997377
In article Mickaël Wolff
Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.


C'est la même chose, ce sont des entiers tout les deux. Il y a un qui
est juste de taille déterminée. Mais en lisant bien une seconde fois, tu
verras que le char n'est traité qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.


Comme ce que tu racontes n'est pas clair du tout, un petit resume
rapide des regles de base de portabilite des types entiers:

- les types standards int, short, long sont toujours signes, quel que soit
le compilateur, quelle que soit la machine.
- donc int == signed int, short == signed short, long == signed long.
- char est un cas particulier. Selon les implementations, char peut etre
signe, ou non signe. Il faut preciser si on veut explicitement des
signed char, ou des unsigned char.
- je ne detaillerai pas les wchar_t (qui sont un typedef en C et un type
natif en C++. Il suffit ici de savoir qu'ils existent.

- L'implementation des types signes en C laisse enormement de latitude a
l'implementeur. Il est juste dit que les short doivent pouvoir representer
l'intervalle -32767,+32767, les int pareils, et les longs montent jusqu'a
2^31. Il n'y a guere de contrainte de representation (meme si on s'oriente
vers de la representation en complement a 2, ou complement a 1 de
facon explicite). La norme ne dit rien sur ce qui se passe en cas de
debordement de capacite.
- le type char fait au moins 8 bits. Il peut faire plus, la constante
CHAR_BIT permet de savoir ou on en est.
- par definition, sizeof(char) == 1.
- les types unsigned sont plus precis. Ils se comportent precisement comme
doit se comporter de l'arithmetique modulaire dans Z/2^n Z, pour une valeur
adequate de n.

- une implementation peut contenir des types entiers supplementaires,
eventuellement plus grands.
- C99 standardise long long, ainsi que tous les intN_t et int_leastN_t et
consorts.
- Si l'implementation dispose de types entiers pour une taille donnee,
elle DOIT definir intN_t.
- Une implementation DOIT definir une serie de intleastN_t raisonnable
pour pretendre etre completement standard (de memoire, 16, 32, 64... a
verifier dans la norme).


gl
Le #997376
C'est la même chose, ce sont des entiers tout les deux.


Ce sont des types entiers, mais ca s'arrete la, ce n'est pas la meme chose

Il y a un qui est juste de taille déterminée.


Ah bon ? Par convention sizeof(char) vaut 1, le char etant la reference
des tailles memoires.
Mais il n'y a pas de taille imposee pour char ni pour int (seulement des
plages minimales de valeur).


Mais en lisant bien une seconde fois, tu verras que le char n'est traité
qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.



Ben justement non, je ne vois rien dans l'article qui generalise ce fait
a tous les types entiers.

Jean-Marc Bourguet
Le #997375
(Marc Espie) writes:

In article Mickaël Wolff
Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.


C'est la même chose, ce sont des entiers tout les deux. Il y a un qui
est juste de taille déterminée. Mais en lisant bien une seconde fois, tu
verras que le char n'est traité qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.


Comme ce que tu racontes n'est pas clair du tout, un petit resume
rapide des regles de base de portabilite des types entiers:


Tu oublies que les bitfields (pour Mickael, i dans struct s { int i:5; };
et *pas* tous les objets entiers) sont aussi un cas particulier où il faut
préciser le signe si ça a de l'importance.

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



Publicité
Poster une réponse
Anonyme