Newsgroup: it.comp.lang.c
Titolo: stdout, stdin e stderr

Ho notato che queste due chiamate sono identiche
	fprintf(stdout, "Papero\n");
	printf("Papero\n");
Il descrittori stdout, stdin e stderr sono previsti/pretesi dallo
standard?
-- 
Tieni per te il Papero se vuoi la mia email
Non usi la Papero Template Library? Male.
Sito Papero -> 
http://utenti.tripod.it/papero

standard?
I descrittori in questione sono standard (e quindi previsti, se e'
questo che intendi).  Non capisco che cosa tu voglia dire con
"pretesi".  Lo standard output e lo standard error coincidono, in
mancanza di altre specificazioni, con il video, lo standard input con
il buffer di tastiera.  Usare printf("Papero\n"); con un programma che
ha rediretto lo standard output su un file, equivale a scrivere nel
file e non a video.

standard?
Si... occhio che pero' non si tratta di variabili che puoi
assegnare normalmente... es:
  FILE *f=fopen(....);
  FILE *old_stdin=stdin; /* Salva vecchio stdin */
  stdin=f;
  mia_funzione();
  stdin=old_stdin;
Questo codice *NON* e' tenuto a funzionare; in particolare
stdin e' una macro e non una variabile normale (per fare
queste cose puoi usare freopen).
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 standard?
Si.
EMG

 (per fare queste cose puoi usare freopen).
Infatti la mia curiosita' nasce dalla scoperta dell'uso di freopen in
una libreria. Andando a fondo ho trovato le chiamate al sistema
operativo su NT che sono "causate" da freopen. A me servono le
chiamate al S.O., perche' devo mantenere la mia libreria (mi occupo
personalmente della portabilita'). Non sono pero' riuscito a capire la
chiamata a basso livello su NT per avere stderr pero', ma questo e' un
problema a parte. 
(Su win32) Incredibilmente le chiamate "semplici" al S.O. per avere
gli handle standard sono bacate, mentre il run-time del C (con il VC)
funziona.
Tecnicamente ci sarebbe anche molto da dire sulle assunzioni molto
forti che il C fa sull'esistenza di stream predefiniti in un
eseguibile, ma se ne era gia' parlato in un lungo thread OT. 
Pero' io mi ricordo (magari ricordo male) che il C++ ne prevede
quattro di stream, cioe' anche quello di log. Credo che nessun S.O.
supporta quattro stream per il singolo eseguibile, e senza pero' il
supporto del S.O. queste sono solo lettere morte.
Oppure "semplicemente" il C o C++ (inteso come standard) non mette
becco sul concetto di reindirizzamento degli stream, e si limita a
parlare di cio' che deve fare il run-time?


 supporto del S.O. queste sono solo lettere morte.
in DOS ne hai addirittura 5, stdin, stdout, stderr, stdprn, stdaux
ed essendo definite in stdio.h credo siano standard C. (fonte BorlandC 5.0)
ciao
donCiccio

ed essendo definite in stdio.h credo siano standard C. (fonte BorlandC 5.0)
Hmmm... non e' detto che siano std perche' in stdio.h.............
--
Walkie...@Libero.It (ICQ# 8143647)

 Hmmm... non e' detto che siano std perche' in stdio.h.............
hai ragione, in effetti sguardando in stdio.h del VC++5 non c'e' traccia.
Resta vero il fatto che in DOS esistono gli stream per stampante e linea
seriale, cioe' i device PRN e AUX, peccato che solo il BC li usi.
ciao
donCiccio

in DOS ne hai addirittura 5, stdin, stdout, stderr, stdprn, stdaux
Niente ti impedisce di aprire come se fosse un file una seriale o una
stampante, e quindi di trattarlo come uno stream (almeno su win32)
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero
Link al Sito Papero 
http://www.mathtools.net/

 stampante, e quindi di trattarlo come uno stream (almeno su win32)
se, come dicevi tu nel tuo post precedente, il SO lo supporta, altrimenti
nisba, prova ad aprire come file lo scanner, se ti riesce dimmi come hai
fatto che mi serve :-)
Tu nel tuo post precedente affermavi di non conoscere SO che aprissero piu'
i 3 stream contemporanei per singolo eseguibile, io ti facevo solo notare
che il DOS ne apre 5.
ciao
donCiccio

che il DOS ne apre 5.
Cosa che io non sapero. Io ti facevo notare pero' se non ti serve
passare la pipe da un processo all'altro non hai necessita' di questo
tipo di supporto da parte del S.O. per gli stream aggiuntivi.
Se tu apri come una pipe una seriale o una parallela con una freopen()
puoi associare questo nuovo stream, e poi scriverci con il run-time.
Nel 99% dei casi non ti serve a niente, pero' puoi farlo.
Con le stampanti grafiche e/o poscript o gli scannner aprire lo stream
della parallela non serve a niente. Quello della seriale per me non e'
mai servito a niente.
In realta' un S.O. dovrebbe supportare una serie di pipe tra un
processo e l'altro, senza tanto stare a sindacare sul significato
dellle pipe stesse. Se guardi a fondo nel run-time del VC++ 6 vedrai
nascosti in alcuni angoli nascosti il supporto di un ipotetico S.O.
con 32 stream.


 con 32 stream.
non conosco il VC++, ma il BC 3.1 gestisce i FILE con un array di max 30
elementi, il che vuol dire max 30 file aperti contemporaneamenti per
eseguibile, e non 30 stream automaticamente aperti dal SO, non vorrei che
fosse la stessa cosa per il VC.
ciao
donCiccio