[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