• [^] # Re: Oui, mais.

    Posté par . En réponse au journal Self serving. Évalué à 3.

    Windows ne me semble pas en faute.

    Je ne sais pas qui exactement fournit msvcrt (Windows ou MSVC ?) mais, bon, on parle bien de l'écosystème Windows et de ses briques fondamentales fournies par Microsoft. Il y a beaucoup d'applications qui utilisent le CRT (notamment, bien sûr, la plupart des applications portables).

    Du coup, le problème me semble être un truc du genre on évite de passer des pointeurs de trucs internes à des compilos

    On évite si on peut. FILE a l'avantage de fournir une gestion bufferisée des fichiers, ce qu'un fd ou un handle ne font pas. Après on peut tout réécrire à la main, mais ce n'est pas une entreprise triviale…

    Au final, l'avantage du libre est qu'on peut tout recompiler et utiliser la même version de libc, mais ton Unix n’échapperai pas au problème (ça dépend du compilo).

    Si, si, il y échapperait, pour la raison que j'ai donnée plus haut : sur Unix, toutes les bibliothèques chargées dans un processus partagent la même libc (quelle que soit la version existante lors de la compilation). Donc il n'y a pas de problème de FILE * pointant vers des structures incompatibles, par exemple.

    Sous Windows, lorsque des bibliothèques ont été compilées avec des msvcrt différents, elles chargent également des copies de différents msvcrt au sein du même processus. D'où le clash quand ces bibliothèques s'échangent ensuite des pointeurs entre elles.

    tu es sûr que si je file un FILE* venant de libc.so.5, ça passera sans broncher vers libc.so.0?

    La question est sans objet, puisque cette situation ne se produira pas (tu auras une seule libc chargée dans le processus).