Bon, le problème est tout con, ça m'étonne qu'il n'ait pas encore été traité ici, mais je me casse les dents là dessus depuis quelques heures. J'ai beau chercher, je ne trouve rien.
 
Donc : comment faire pour éviter que cette p...n de libc sous Windows ne transforme les "\n" en "\n\r", sans refermer le descripteur (ça serait trop simple sinon). J'utilise gcc 3.4.2 sous Dev-Cpp 4.9.9.2
 
Le problème, c'est que je dois envoyer les données sur le descripteur stdout (qui est une socket ouverte par Apache dans un CGI). J'aurais bien utilisé perl, mais le programme en question fait des traitements beaucoup trop couteux pour perl.
 
Arf, et virer Windows n'est pas non plus une option, même si ce n'est pas l'envie qui me manque.

Ouvrir (ou reouvrir : freopen()) le flux en mode binaire ("wb" ou "rb" ).

Arf, exactement la réponse que je ne voulais pas:
1. reopen utilise un argument sur le nom de fichier, que je n'ai pas.
2. Si je l'avais, il ferait un fclose() sur le troisième argument, et je ne pourrai plus retourner au client les données.
 
Sinon, j'ai aussi essayé :
* fdopen(fileno(stdout), "wb" ); : même symptôme.
* fcntl : F_GETFL undeclared blablabla ...

P...n, j'ai trouvé. 5 heures de bidouillage. Histoire de se coucher moins idiot ce soir, la petite incantation magique pour contourner les bugs^Wfeatures de Windows:
 
setmode(fileno(stdout), O_BINARY); // première instruction de main()
 
Je ne sais pas si c'est portable, mais ça marche dans mon cas.
 
(edit: le plus drôle, c'est que j'ai trouvé ça dams les sources de perl 5.8.7. OpenSource rulez !!)

 
Je suis plus très sûr, mais je crois que ça vient du source de php.
 
edit: après vérif, c'est bien ça