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 ?
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
>> 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...
>> 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.
>> 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
In article , wrote:
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...
In article <slrng5im5c.cbs.rixed@apc.happyleptic.org>,
<rixed@happyleptic.org> wrote:
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...
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
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 :(
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 :(
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
In article <485a3280$0$21142$, Gabriel Linder wrote:
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.
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.
In article <485a3280$0$21142$7a628cd7@news.club-internet.fr>,
Gabriel Linder <linder@jeuxvideo.com> wrote:
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.
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.
In article <485a3280$0$21142$, Gabriel Linder wrote:
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.
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
On 2008-06-19, 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.
Ce qui ne dispense pas de rester courtois.
Merci quand même pour les infos.
On 2008-06-19, Marc Espie <espie@lain.home> 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.
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
In article , wrote:
On 2008-06-19, 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.
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...
In article <slrng5mp2t.2mm.rixed@apc.happyleptic.org>,
<rixed@apc.happyleptic.org> wrote:
On 2008-06-19, Marc Espie <espie@lain.home> 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.
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...
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...
