va_end et longjmp

Le
rixed
Bonjour !

La norme à l'air d'expliquer que va_end est nécessaire après chaque
va_start pour s'assurer du bon fonctionnement du return.

Mon problème est le suivant : j'ai un longjmp qui "traverse" une
stack-frame qui a "ouvert" une va_list mais ne pourra donc pas
la fermer.

Dans la pratique, ça marche bien sur sans problème.

Est-ce grave selon vous ?
Pensez vous à des architectures qui pourrait poser problème ?
Par exemple une fuite mémoire si des données sont recopiées par le
va_start et libérée par le va_end ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain SF
Le #7040021
wrote on 18/06/2008 21:30:
Bonjour !

La norme à l'air d'expliquer que va_end est nécessaire après chaque
va_start pour s'assurer du bon fonctionnement du return.

Mon problème est le suivant : j'ai un longjmp qui "traverse" une
stack-frame qui a "ouvert" une va_list mais ne pourra donc pas
la fermer.



les handler d'exceptions (longjmp) en cascade sont censés être
fait pour éviter cel: on fait le ménage local, puis on jump.

Dans la pratique, ça marche bien sur sans problème.



dans 'une' pratique, non ? celle de votre comilo actuel.

sous wintel avec studio, cela fonctionnera aussi sûrement
car le define va_end ne fait rien ... jusqu'au jour où ...

Est-ce grave selon vous ?



c'est surtout guérisable.

Sylvain.
rixed
Le #7040811
>> Mon problème est le suivant : j'ai un longjmp qui "traverse" une
stack-frame qui a "ouvert" une va_list mais ne pourra donc pas
la fermer.



les handler d'exceptions (longjmp) en cascade sont censés être
fait pour éviter cel: on fait le ménage local, puis on jump.



Oui, mais vu toute la machinerie que gcc place derrière les anodins
setjmp/longjmp je préfère en intercaller le moins possible.

Lorsqu'une étape est nécessaire pour "faire le ménage" dans une fonction
j'ai recours à une astuce plus rapide : une pile de fonctions à appeler
avant un éventuel longjmp. Mais avec va_end ça ne fonctionne pas puisque
c'est une macro.

D'où la tentation d'oublier le va_end...
espie
Le #7042381
In article
Bonjour !

La norme à l'air d'expliquer que va_end est nécessaire après chaque
va_start pour s'assurer du bon fonctionnement du return.

Mon problème est le suivant : j'ai un longjmp qui "traverse" une
stack-frame qui a "ouvert" une va_list mais ne pourra donc pas
la fermer.

Dans la pratique, ça marche bien sur sans problème.

Est-ce grave selon vous ?



C'est moche, non portable, et ca va casser sur certaines archis.

Contrairement a ce que tu peux penser, les preconisations de la norme
ne sont pas la juste pour faire chier, il y a certaines archis avec des
ABI particulierement funky ou les va_list ont besoin de structures
annexes pour faire leur boulot (de memoire, je dirais bien ppc, hppa, et
m88k).

Tu as le droit de reparer ca.

Dans mon boulot dans OpenBSD, je passe suffisamment de temps a reparer
des cochonneries pour porter des logiciels pour que ce genre de trucs
me gonfle particulierement. C'est toujours un petit truc qui marche presque
partout, apres lequel on se retrouve a courir dans des mega et des mega de
code source parce qu'un zozo a vu que ca marchait sur son compilo, son
archi, et s'est permis de generaliser a tout le reste...

Entre les melanges entre pointeurs et entiers (sparc64), les alignements non
respectes (sparc64 et alpha), ou la pile qui croit toujours dans le meme sens
(hppa), j'ai plus un catalogue de trucs-qui-devraient-marcher-mais-ne-marchent
-pas. Et c'est pratiquement toujours pour des broutilles.

setjump/longjump est en bonne place dans la liste des horreurs qui ne
fonctionnent presque jamais...
Gabriel Linder
Le #7043421
On Thu, 19 Jun 2008 08:39:43 +0000, Marc Espie wrote:

Dans mon boulot dans OpenBSD, je passe suffisamment de temps a reparer
des cochonneries pour porter des logiciels pour que ce genre de trucs me
gonfle particulierement. C'est toujours un petit truc qui marche presque
partout, apres lequel on se retrouve a courir dans des mega et des mega
de code source parce qu'un zozo a vu que ca marchait sur son compilo,
son archi, et s'est permis de generaliser a tout le reste...

Entre les melanges entre pointeurs et entiers (sparc64), les alignements
non respectes (sparc64 et alpha), ou la pile qui croit toujours dans le
meme sens (hppa), j'ai plus un catalogue de
trucs-qui-devraient-marcher-mais-ne-marchent -pas. Et c'est pratiquement
toujours pour des broutilles.




Est-ce qu'un tel recueil de choses-à-ne-pas-faire est accessible quelque
part ? Ce genre de détails m'intéresse (et je ne dois probablement pas
être le seul), vu que je n'ai jamais travaillé que sur des i386/x86_64 :(
espie
Le #7044861
In article Gabriel Linder
On Thu, 19 Jun 2008 08:39:43 +0000, Marc Espie wrote:

Dans mon boulot dans OpenBSD, je passe suffisamment de temps a reparer
des cochonneries pour porter des logiciels pour que ce genre de trucs me
gonfle particulierement. C'est toujours un petit truc qui marche presque
partout, apres lequel on se retrouve a courir dans des mega et des mega
de code source parce qu'un zozo a vu que ca marchait sur son compilo,
son archi, et s'est permis de generaliser a tout le reste...

Entre les melanges entre pointeurs et entiers (sparc64), les alignements
non respectes (sparc64 et alpha), ou la pile qui croit toujours dans le
meme sens (hppa), j'ai plus un catalogue de
trucs-qui-devraient-marcher-mais-ne-marchent -pas. Et c'est pratiquement
toujours pour des broutilles.




Est-ce qu'un tel recueil de choses-à-ne-pas-faire est accessible quelque
part ? Ce genre de détails m'intéresse (et je ne dois probablement pas
être le seul), vu que je n'ai jamais travaillé que sur des i386/x86_64 :(



Trouve-toi un alpha pas rapide et pas chere, ou une vieille sparc.
Ca doit pouvoir se trouver pour <50EUR en fouillant les poubelles,
c'est franchement le plus simple.

Le vrai bon recueil, c'est celui des choses a faire, a savoir se
procurer la norme du C, la lire, et la respecter.
rixed
Le #7051991
On 2008-06-19, Marc Espie
Dans mon boulot dans OpenBSD, je passe suffisamment de temps a reparer
des cochonneries pour porter des logiciels pour que ce genre de trucs
me gonfle particulierement.



Ce qui ne dispense pas de rester courtois.

Merci quand même pour les infos.
espie
Le #7053741
In article
On 2008-06-19, Marc Espie
Dans mon boulot dans OpenBSD, je passe suffisamment de temps a reparer
des cochonneries pour porter des logiciels pour que ce genre de trucs
me gonfle particulierement.



Ce qui ne dispense pas de rester courtois.



Ca, c'est la version edulcoree. Tu peux remplacer `cochonneries' par
`BIP de logiciel de BIP'... ;-)


Generalement, je suis plus poli, mais quand tu passes des HEURES sur
des conneries et que tu as l'impression que le logiciel que tu essaies
de porter a ete programme par des debiles profonds qui font tout ce
qu'il ne faut pas, parfois, ca enerve un peu...
Publicité
Poster une réponse
Anonyme