[gull] Y a t-il un portable =?utf-8?q?recomand=E9=5Fpour=5FLa?= Debian?

Daniel Cordey dc at mjt.ch
Tue Aug 17 08:48:01 CEST 2004


On Monday 16 August 2004 18:41, Jean-Bruno Luginbuhl wrote:

> Oui mais ils ont su garder la compatibilité
> ASCENDANTE, il est notoire que RIEN ne fonctionne sur
> les UNIX d'aujourd'hui des logiciels d'hier

Ca semble dependre des UNIX... ce que tu mentionnes etait exeptionnel sous 
HP-UX. J'ai encore une version de ivo (emacs multi-window datant de 1987), 
compile sur HP-UX 4.0 et tournant toujours sous 10.20. La version 64 bits de 
HP-UX 11.0 a sonne le glas de cette epoppee, pour un simple probleme d'API 
avec le kernel (proc_stat different de 64 bits et 32 bits).. Sniff...

Donc, sous UNIX, Linux, si tu te contentes d'utiliser les libraries standards 
(libx, X11, etc.) tu ne devrais pas avoir de probleme a assurer la perenite 
de ton application tout au long des versions futures. Ce n'est qu'a partir du 
momenet ou tu utilises un API qui n'est pas encore fige, ou qui a evolue, que 
tu auras des problemes. 

Un exemple tres simple est donne par la fonction lseek(2). Cette fonction, 
compilee il y a quelques annees en mode 32 bits utilisait une signature dont 
le deuxieme parametre etait un entier non-signe de 32 bits... Depuis quelques 
annees, on permet la manipulation de fichiers de plus de 4GB (32 bits !), ce 
qui fait que le deuxieme argument n'est plus 32 bits mais 64 bits ! Ceci a 
pour effet de "casser" la compatibilite d'applications, meme ecrites 
proprements :-( Remarque qu'en lisant la doc, on trouve des trucs tres 
insidieux mais qui peuvent engendrer des comportements differents suivant les 
plate-formes (exemple pris dans le manuel de lseek(2) sous Linux)

	SVR1-3 returns long instead of off_t, BSD returns int

Daniel




More information about the gull mailing list