read() est-il standard ?

RTFM ( Read The Fucking Manual )
Comme la radio RFM on rajoute un T et ça donne:
READ THE FUCKING MANUAL si vous me croyez pas allez sur wikipedia.
maintenant ceux qui connaissent pas ( je cite les modérateurs surement pour les conneries qu'ils disent du genre la fonction read pas dispo dans la lib C ... )
Qui est quand même une des bases du langage c.

Alors pour ceux qui veulent apprendre le C je dis pas que ce site est nul au contraire il est très bien mais pour les modérateurs qui disent que certaines fonctions ce trouvant dans la libc de base... Enfin voila revoyez vos bases cela vous fera pas de mal et pour les nouveaux continuez comme ça vous verrez c'est cool le C moi perso c'est ma drogue la programmation ( après les femmes faut pas oublier car quand on est sur son pc mais on a une vie a coté ^^ :oops: )

Enfin voila tout ça pour dire au modo de réapprendre le C!!! :D

Andouille, read() ne fait pas partie du C standard, c'est une fonction POSIX.
C'est toi qui devrait lire le manuel, au paragraphe Conformité
http://man.developpez.com/man2/read.2.php

Eh bien GFY (Go F--- Yourself) car la fonction read() ne fait effectivement pas partie de la norme C.
Donc, il existe des lib C qui tout en respectant le standard, n'ont pas cette fonction.

La seule fonction standard C pour la lecture par bloc, c'est fread().

Donc, va réapprendre les normes et ne dis pas aux modos ce qu'ils ont à faire.

Edit: http://www.medinoc.fr/web/ImagesDive...ForumNinja.gif par Gruik, qui contrairement à moi n'a pas perdu de temps à être agressif.

http://fr.wikipedia.org/wiki/POSIX
merci de ton information maintenant va lire ce message fonction systeme depuis 1988 donc si t'as tout de plus vieux je comprend sinon revois tout :)

Tu l'as dit toi-même: POSIX
P-O-S-I-X.
Pas Standard C.

Windows par exemple, n'est pas POSIX.

Il me semble que Wiki n'est pas une source fiable.

je suis d'accord avec d'ou mon ancien sujet qui a été modifié RTFM on te dis read tu vois ça marche pas la personne précise pas son os il regarde le man sinon il précise son os et la c'est clair personnelement j'ai xp cigwin etc... read fonctionne très bien il suffit juste de commencer à prog avec ce qu'il faut. :) Sinon faut installer unix pour bien programmer mais ça pour ceux qui débute c'est toujours pas top.

Pour ce qui est de wikipédia c'est peu être pas une source sur mais en général ce qui est dedans est vérifié avant d'y être mi.

Ici, on est plutôt à cheval sur le standard C, et on évite d'utiliser POSIX si on a une alternative standard JUSTE LÀ SOUS NOTRE NEZ.

Pour information au sujet de Windows, les derniers SDK de Microsoft respectent toujours le standard C90 (bien qu'ils incitent à ne pas le suivre et qu'ils défèquent sur C99) mais s'éloignent de POSIX: Notamment, utiliser read() te donnera un warning.
Sans compter que la fonction open() de DOS ou Windows, bien qu'elle possède le même nom que la fonction open() POSIX, ne s'y conforme pas.

Donc, Windows n'est pas POSIX, et c'est une des raisons dominantes pour lesquelles on colle au standard autant que faire se peut. La fonction non-standard read() ne sert à rien tant qu'on a fread() sous la main.

Je tiens dans mes mains le k&r2.
Au chapitre 8.2 il semblerai que la fonction read soit dans le fichier "appelsys.h" c'est un prototype et non un standard

emprex tu connais rtfm google man et c'est réglé c'est plus complet qu'un bouquin 8O
moi je te dis juste si tu prog sous windows télécharger des programmes comme cygwin et tu programme sous windows comme si c'était POSIX enfin bon windows c'est sympa mais c'est pourri pour programmer ça a rien et médinoc si tu relis ce que j'avais écris au dessus j'ai précisé que si on te dis read et que tu vois que ça marche pas rtfm la tu vois fread et c'est réglé c'est pour ça ( rtfm ou man read mais bon tu dois connaitre :P )

Citation:

---

Envoyé par paillepailles

emprex tu connais rtfm google man et c'est réglé c'est plus complet qu'un bouquin 8O

---

Mais le bouquin est plus accessible, et le K&R 2 est la norme. D'ailleurs, je doute que le K&R2 soit disponible gratos sur le Web... (son errata l'est, par contre).

Citation:

---

moi je te dis juste si tu prog sous windows télécharger des programmes comme cygwin et tu programme sous windows comme si c'était POSIX

---

Donc, tu télécharges un truc supplémentaire qui ne fait pas partie du SDK de Windows. CQFD.

Citation:

---

enfin bon windows c'est sympa mais c'est pourri pour programmer ça a rien

---

Perdu. Ça a pas mal de choses que POSIX n'a pas, notamment une API de fenêtrage qui est garantie être présente sur tous les Windows dans rien à installer, une API de cryptographie, une API réseau avec des extensions sympa, une API de multithreading native...

Citation:

---

et médinoc si tu relis ce que j'avais écris au dessus j'ai précisé que si on te dis read et que tu vois que ça marche pas rtfm la tu vois fread et c'est réglé c'est pour ça ( rtfm ou man read mais bon tu dois connaitre :P )

---

Donc, tu essaies de me dire qu'il faut utiliser read(), parce que si ça ne marche pas, l'aide te dira la bonne fonction... Un peu :aie: non ?

Citation:

---

Envoyé par emprex

Je tiens dans mes mains le k&r2.
Au chapitre 8.2 il semblerai que la fonction read soit dans le fichier "appelsys.h" c'est un prototype et non un standard

---

Relis le tire du chapitre : extension Unix. Ce n'est pas le standard C.

@paillepailles

N'insiste pas, tu te ridiculises en public. Mais si ça peut te faire plaisir, chacun ses petites manies.

Voila la norme :

http://www.open-std.org/jtc1/sc22/wg...docs/n1124.pdf

si tu trouves read(), fait moi signe.

The nice thing about standards is that there are so many to choose from.

Il faut donc savoir de quelle norme on parle. Quand il s'agit du C, c'est ISO-9099. Et la il n'y a pas de fonction read.

read() est une fonction Unix. Et la norme de Unix, c'est IEEE-1003, alias POSIX. On y trouve pas mal de choses qui n'ont pas de rapport avec le C (par exemple une description du shell).

Citation:

---

Envoyé par Jean-Marc.Bourguet

read() est une fonction Unix.

---

Oui mais bon tu peux l'utiliser sous windows quand même. Tu veux dire qu'elle est d'origine Unix ?

Citation:

---

Envoyé par hegros

Oui mais bon tu peux l'utiliser sous windows quand même. Tu veux dire qu'elle est d'origine Unix ?

---

Vraisemblablement mais il n'est pas tout a fait impossible qu'il s'agit d'une evolution independante. Je connais assez mal windows, mais je vois au moins 3 raisons differentes pour lesquelles ce serait disponible:
- par chance: le nom est assez commun pour arriver a utiliser le meme nom pour la meme chose et les arguments necessaires sont relativement naturel aussi (je viens de verifier l'interruption 21, fonction 3Fh du DOS a la meme interface si on exclu le probleme de l'ordre des arguments).
- par compatibilite. Il y a des programmes C qui utilise cette fonction, on fournit un systeme pour faire du C, fournissons la aussi (la norme date de 1989 et les premiers compilateurs C hors Unix d'avant et de plus personne ne se limite a la norme quand faire un peu plus permet de satisfaire les clients a peu de frais sans inconvénients majeurs )
- par compatibilite: on utilise une couche posix (cygwin, uwin, interix pour citer celles que je connais) et donc on a naturellement ce qui est unix.

Citation:

---

Envoyé par Jean-Marc.Bourguet

- par compatibilite: on utilise une couche posix (cygwin, uwin, interix pour citer celles que je connais) et donc on a naturellement ce qui est unix.

---

MinGW supporte aussi une partie de POSIX.1 dont read() / write(). Mais sous Windows, la fonction de l'API officielle est ReadFile() / WriteFile() ... Medinoc saura mien en parler, parce que moi aussi, Windows, c'est ... de loin...

read est une fonction (un appel système) UNIX. Dans le livre de K&R, cette fonction apparaît dans la partie "interface avec le système UNIX". Dans les cours de C actuels elle apparaît (si elle apparaît) dans un chapitre du genre "les E/S de bas niveau sous UNIX", et bien sûr dans le texte de la norme : elle n'apparaît pas!

Le langage C est en quelque sorte un "assembleur indépendant de la machine". Le langage est concis, il n'y a pas de fonctions intégrées (c'est-à-dire prédéfinies), chacun doit donc à priori développer ses propres fonctions ou utiliser des fonctions déjà existantes (les APIs de son système par exemple).

Afin de faciliter la tâche aux programmeurs (en particulier pour l'écriture de programmes portables), on a composé un bouquet de fonctions qui doit être livré avec tout compilateur C digne de ce nom. read n'en fait pas partie (mais rien n'empêche un implémenteur particulier de l'inclure dans son bouquet ...). D'ailleurs comme nous le savons le C doit ses origines au système UNIX, c'est pourquoi de nombreuses fonctions de la bibliothèque standard sont en fait des fonctions originaires d'UNIX.