Newsgroup: it.comp.lang.c
Titolo: File stream: FILE* o int?!

Mi spiego meglio:
ho notato che alcune funzioni di grande utilità per quello che sto facendo
io, come ad esempio la locking, richiedono un intero come descrittore del
file, mentre io ho fatto già un gran uso di fprintf ed fscanf, usando quindi
i classici puntatori a stream FILE*.
Ora, so che probabilmente la mia domanda sembrerà stupida ai più, ma esiste
un modo per avere un descrittore di file (intero) a partire dal puntatore
allo stream (di tipo FILE), oppure esistono funzioni simili alla fprintf ed
alla fscanf che prendano come argomento un descrittore intero invece di un
*FILE?
Grazie a tutti.
Ciao

 *FILE?
write() e read(), ma la stringa deve essere gia' completa, non puoi 
usare indicatori di conversione e non hai un numero variabile di parametri.
-- 
Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167
http://counter.li.org

 ha scritto nel messaggio 
news:dTr2f.5583$Pe2.1...@twister2.libero.it...

Ciao, prova con fileno(). 

 descriptor. Io proverei qualcosa tipo fd _fd o fd_
Nel mio ambiente (gcc v3.3.5 per linux i386) si chiama _fileno e la 
struttura _IO_FILE e' definita in libio.h e in stdio.h c'e'
#include <libio.h>
typedef struct _IO_FILE FILE;
Comunque non e' una buona idea usarlo..


Maxime ha scritto:

Interessante.. proprio non la conoscevo. Non fa parte del c standard, ma 
e' sicuramente piu' portabile della mia soluzione :-)



Ciao,
è veramente strano che non faccia parte dello standard perché se non erro, 
il prototipo, l'ho sempre trovato definito in "stdio.h". Premetto di non 
essere un conoscitore di standard C ma uso questo linguaggio da circa 20 
anni (forse di più) con i compilatori e le piattaforme più disparate e, 
spesso proprio a causa dei lock dei file e della comodità degli stream, ho 
dovuto approfittare di questa funzione (fileno). Mi verrebbe quasi da 
pensare che i definitori di standard se la siano dimenticata per il semplice 
fatto che non vedo quali dipendenze possa avere dalle piattaforme e quindi 
come poter creare problemi in un porting.
Un saluto. 

...dimenticavo...
Un'alternativa sarebbe aprire il file con la open(), la quale ritorna il 
descrittore, ed in seguito dedicargli uno stream usando la funzione fdopen() 
ma temo che anche quest'ultima non sia standard. Fammi sapere.
Un saluto. 

Maxime ha scritto:

Se non sbaglio e' definita in posix.1 quindi non c'e' niente di strano 
nel trovarla praticamente ovunque.
Non fa parte del c standard, come tutte le funzioni che trattano i file 
descriptor, perche' non e' detto che un sistema operativo li usi. Quindi 
non e' del tutto portabile nemmeno la tua altra soluzione (open+fdopen).
Comunque non sono un esperto di standard o di sistemi operativi e quindi 
non ti posso aiutare piu' di tanto.


 non e' del tutto portabile nemmeno la tua altra soluzione (open+fdopen).
Basta con la solita "Non fa parte del c standard" :-(
Il C non e` solo lo standard ISO/ANSI.  Vedi mio post precedente.



Ne fileno() ne fdopen() sono definite dallo standard ISO/ANSI ma tutti i 
compilatori (o quasi) includono entrambe le funzioni.


 
Non mi sono limitato a dire "sei ot", prima di arrivare a questo ho 
parlato dell'argomento. E come avevo gia' detto, se un argomento non 
riguarda il C ISO/ANSI si puo' tranquillamente continuare a parlarne in 
un altro ng. Prova a guardare comp.lang.c, e vedrai che anche se i post 
sono al 99% IT di traffico ne rimane molto e non ci sono solo principianti.


 
Vero quasi sempre, ma potrebbero usare altro. Se questo ng fosse 
it.comp.os.linux.development allora gli avrei risposto diversamente, ma 
essendo it.comp.lang.c gli dico che nello standard c (non posix) i file 
descriptor non sono nemmeno nominati.


.
it.comp.lang.c	Il linguaggio di programmazione C
Il newsgroup tratterà del linguaggio C, ideato da Brian W. Kernighan e 
Dennis M. Ritchie.
Il newsgroup tratterà di qualsiasi dialetto del linguaggio C, in modo
particolare del vecchio K&R e di quello specificato dall'istituto 
americano ANSI come standard "ANSI X3.159-1989" e ratificato 
dall'istituto internazionale ISO come standard "ISO/IEC 9899:1990". 
Argomenti compresi:
  - Il linguaggio in generale;
  - Gli algoritmi;
  - Le ottimizzazioni;
  - La portabilità;
  - I sistemi di sviluppo.
-----------------------------------------------------------------
La domanda dell'OP e` piu` che pertinete.  Sei tu che vai OT dando 
risposte senza aver letto il manifesto.


 sono al 99% IT di traffico ne rimane molto e non ci sono solo principianti.
Ma allora sei Laforgia :-(


 
Forse ti riferisci a "qualsiasi dialetto".. io ho interpretato quel 
pezzo come "stile di programmazione" o "modifiche minori agli standard 
nominati" e quindi non mi e' sembrato che POSIX fosse un "dialetto". 
Comunque se dici che mi sono sbagliato ti posso anche credere...
Quello che volevo dire e' che *qui* si parla di C standard e "astratto", 
ma solo perche' prima di scrivere programmi seri e utili, e' necessario 
conoscere il linguaggio. Poi non pensare che io sia una specie di 
filosofo del C, perche' non lo sono. Anzi, sono dell'idea che non serva 
a niente conoscere un linguaggio senza utiizzarlo per qualcosa di 
pratico. Rimango comunque dell'idea che gli argomenti vadano tenuti 
divisi. Prova a pensare se qui si parlasse di tutto quello che si puo' 
fare in C: le domande di chi vuole imparare si perderebbero nella marea 
di domande di chi si occupa di database, reti, sistemi operativi... 
Prova a guardare pl.comp.lang.c, non e' necessario conoscere il 
polacco.. Poi non capisco dove sta il problema: se i ng specifici ci 
sono, perche' non usarli?
Comunque se "qualsiasi dialetto" comprende anche POSIX, allora 
parliamone. E non e' una frase ironica, davvero ho interpretato il 
manifesto come ti ho detto.


 Ma allora sei Laforgia :-(
Si, perche' mi infastidiscono gli ot (anche se questa volta non era ot) 
e credo che serva uno spazio in cui parlare solo del linguaggio in se.
No, perche' io non mi credo un magnifico esperto di tutto. (ho detto 
piu' volte che sono solo agli inizi e quello che dico va considerato in 
questi termini, non come verita' assoluta)
No, perche' se sbaglio lo ammetto.
No, perche' non insulto nessuno.
No, perche' credo che il C non serva quasi a niente se non e' applicato 
praticamente (e se serve va esteso andando fuori dagli standard)


 *FILE?
tutte le funzioni presenti in <io.h> sotto win...
read, write, ecc....sono simulazioni delle funzioni
sotto linux (unistd.h)

:1,$d
Scusate se mi intrometto nuovamente ma mi sono sorte delle perplessità.
Spesso mi è capitato di leggere, su questo NG, domande relative all'utilizzo 
di funzioni interfaccianti i socket e risposte che consigliavano di 
rivolgersi ad altri NG più idonei, altrettanto spesso ho potuto notare che 
gli stessi corrispondenti, invece, rispondevano a domande sull'utilizzo 
delle printf, scanf e famiglia. Non sono, forse, anche queste delle funzioni 
che interfacciano l'I/O e quindi, secondo il manifesto, risultare OT?
E, ritornando alla domanda con cui è stato aperto questo thread, secondo il 
manifesto la risposta giusta da dare a chi si firma MonsterMash sarebbe 
dovuta essere: lo sappiamo ma qui non te lo possiamo dire quindi arrangiati 
oppure chiedicelo in privato?
In ogni caso, seguendo e accumunando le varie divergenze avutesi per lo 
standard in questo NG, il C che ne rimane a galla è appena sufficiente per 
qualche esercizio e qualche semplice programmino:( 

 praticamente (e se serve va esteso andando fuori dagli standard)
Giusto!  il C va applicato, ma per applicarlo lo standard ISO non basta. 
Devi applicarlo a degli algoritmi e in qualche caso anche per scrivere 
un S.O. (o le librerie di supporto al compilatore).  Non solo per gli 
esercizi del corso di laurea.
Ciao
Giovanni


 Giusto!  il C va applicato, ma per applicarlo lo standard ISO non basta. 
Beh, che dire.. questo thread mi ha fatto pensare che a volte mi sono 
lasciato prendere la mano e ho scritto troppo spesso le due lettere 
magiche. Mi cospargo il capo di cenere :-)



Grazie a tutti per le risposte. Ammetto di non aver più letto il NG nei 
giorni successivi al mio post, in quanto poche ore dopo avevo già trovato 
(scartabellando in msdn) la soluzione qui sopra proposta.
Alla fine ho usato questa, e pare funzionare bene.
La prossima volta provo con la fileno() :)
Grazie a tutti di nuovo
Ciao 

 e quindi, secondo il manifesto, risultare OT? 
Ma no. printf, scanf e "compagnia" sono funzioni della Libreria Standard del
C. Le funzioni dei socket no.
Max

 Non c'e` piu` Andrea LaForgia a scrivere queste cazzate, ti ci metti tu ora?
Taci, idiota, ignorante e incompetente.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 del manifesto.  
Lo si è capito benissimo invece.


 
Ciao, bentornato anche se non si sentiva proprio la tua mancanza
