Cette histoire de prépocesseur qui remplace les 0 par des pointeurs invalides si le 0 n'est pas suffisament invalide m'a l'air complétement tordue!!!
Tu as de la chance. C'est juste que tu n'as jamais bossé sur des archis ou dans des contextes ou l'adresse 0 est interressante. Pour le coté exotique je citerais entre autres:
- Dos et variantes
- Windows avant 1995
- OS2 et variantes
-Mac OS jusqu'à 8 (et un peu 9 aussi mais moins)
- Processeurs zilog (Z80 et consors)
etc.
Cette histoire de prépocesseur qui remplace les 0 par des pointeurs invalides si le 0 n'est pas suffisament invalide m'a l'air complétement tordue!!!
Ben pourtant. Si l'adresse 0 existe et est utile, il faut bien pouvoir y acceder non ? De fait il faut bien que le compilo puisse faire la différence entre un pointeur vers l'adresse 0 valide et un autre qui est invalide. Au final c'est la front-end (on va faire plaisir aux codeurs C) qui s'en occupe.
C'est peut être le cas sur certaines architectures où on veut à tout pris pouvoir exploiter l'adresse 0 au mépris de la portabilité
Au moment ou la base de ces architectures a été créé on vérifiait la comptabilité fortran, éventuellement CP/M. On a gardé ce genre d'architecture après pour la compatibilité avec leurs ancètres.
Il faut cependant remarquer qu'il s'agit alors d'une constante... et c'est effectivement pour ça que le compilateur te laisse accéder à 0 comme tu le veux et que cette convention du « 0 <=> adresse invalide » n'est pas connu du compilateur.
C'est bienle prob, quelqu'un doit la traiter en amont sur les architectures ou 1) l'adresse 0 est valide et 2) on veut la compatibilité avec le C dans le reste du monde. Donc c'est toute l'étape de preprocessing qui s'en occupe.
Rien ne t'empêche cependant de réécrire un malloc() qui renvoie 0xFFFFFFFF si l'allocation ne peut pas se faire pour pouvoir exploiter normalement ton système
Alors là tu vas reveillr un troll qui n'a pas revu le jour depuis des années. Avant le C, les fonction qui retournait des valeurs (Bonc OK les jump sub routine qui remplissait des registres) se comportait comme suit :
regsitre a 0 : tout s'est bien passé
registre a N (N>0) : erreur n°N
registre a -1 : instruction illégale
Quand le C est parti pour l'inverse il y a eu des grincement de dents.
Perso j'utilise toujours la vieille notation pour mes progs a moi, avec un gros entete dans mes fichiers. Bon ca c'est pour les fonctions en général.
Pour malloc en particulier il renvoit un pointeur vers la zone mémoire libérée, lequel est éventuellement NULL.
Et citer malloc ici ne fait pas vraiment avancer le débat : Si mon preprocessing corrige les sorties à 0 des fonctions dont la signature indique qu'ils renvoient un pointeur, il corrigera celle de malloc avant la compil. Donc je ne casserai aucune compatibilité source vu que la correction sera faite par le prepro/front end en aval du source...
mais je t'avouerais que je préfèrerais perdre 1 octet de RAM plutôt que tenter de réinventer un ersatz de langage C avec des conventions différentes.
Aujourd'hui tout le monde fait ca. Mais a l'epoque ou on achetait les 2Mo de ram pour plusieurs milliers de francs et ou on ne pouvait accéder a la mémoire que par pages de 4ko la simple pensée de fiche en l'air 512 octets par barrette ne faisait rire personne.
Pour l'atari ST, il s'agit ici d'émulation donc de compatibilité au niveau binaire. Il est clair que l'on ne peut pas surveiller toutes les allocations et tous les jumps pour vérifier que l'adresse ne vaut pas 0. D'ou le hack.
[^] # Re: Petites precisions
Posté par Jerome Herman . En réponse au journal J'adore Linus. Évalué à 2.
Tu as de la chance. C'est juste que tu n'as jamais bossé sur des archis ou dans des contextes ou l'adresse 0 est interressante. Pour le coté exotique je citerais entre autres:
- Dos et variantes
- Windows avant 1995
- OS2 et variantes
-Mac OS jusqu'à 8 (et un peu 9 aussi mais moins)
- Processeurs zilog (Z80 et consors)
etc.
Cette histoire de prépocesseur qui remplace les 0 par des pointeurs invalides si le 0 n'est pas suffisament invalide m'a l'air complétement tordue!!!
Ben pourtant. Si l'adresse 0 existe et est utile, il faut bien pouvoir y acceder non ? De fait il faut bien que le compilo puisse faire la différence entre un pointeur vers l'adresse 0 valide et un autre qui est invalide. Au final c'est la front-end (on va faire plaisir aux codeurs C) qui s'en occupe.
C'est peut être le cas sur certaines architectures où on veut à tout pris pouvoir exploiter l'adresse 0 au mépris de la portabilité
Au moment ou la base de ces architectures a été créé on vérifiait la comptabilité fortran, éventuellement CP/M. On a gardé ce genre d'architecture après pour la compatibilité avec leurs ancètres.
Il faut cependant remarquer qu'il s'agit alors d'une constante... et c'est effectivement pour ça que le compilateur te laisse accéder à 0 comme tu le veux et que cette convention du « 0 <=> adresse invalide » n'est pas connu du compilateur.
C'est bienle prob, quelqu'un doit la traiter en amont sur les architectures ou 1) l'adresse 0 est valide et 2) on veut la compatibilité avec le C dans le reste du monde. Donc c'est toute l'étape de preprocessing qui s'en occupe.
Rien ne t'empêche cependant de réécrire un malloc() qui renvoie 0xFFFFFFFF si l'allocation ne peut pas se faire pour pouvoir exploiter normalement ton système
Alors là tu vas reveillr un troll qui n'a pas revu le jour depuis des années. Avant le C, les fonction qui retournait des valeurs (Bonc OK les jump sub routine qui remplissait des registres) se comportait comme suit :
regsitre a 0 : tout s'est bien passé
registre a N (N>0) : erreur n°N
registre a -1 : instruction illégale
Quand le C est parti pour l'inverse il y a eu des grincement de dents.
Perso j'utilise toujours la vieille notation pour mes progs a moi, avec un gros entete dans mes fichiers. Bon ca c'est pour les fonctions en général.
Pour malloc en particulier il renvoit un pointeur vers la zone mémoire libérée, lequel est éventuellement NULL.
Et citer malloc ici ne fait pas vraiment avancer le débat : Si mon preprocessing corrige les sorties à 0 des fonctions dont la signature indique qu'ils renvoient un pointeur, il corrigera celle de malloc avant la compil. Donc je ne casserai aucune compatibilité source vu que la correction sera faite par le prepro/front end en aval du source...
mais je t'avouerais que je préfèrerais perdre 1 octet de RAM plutôt que tenter de réinventer un ersatz de langage C avec des conventions différentes.
Aujourd'hui tout le monde fait ca. Mais a l'epoque ou on achetait les 2Mo de ram pour plusieurs milliers de francs et ou on ne pouvait accéder a la mémoire que par pages de 4ko la simple pensée de fiche en l'air 512 octets par barrette ne faisait rire personne.
Pour l'atari ST, il s'agit ici d'émulation donc de compatibilité au niveau binaire. Il est clair que l'on ne peut pas surveiller toutes les allocations et tous les jumps pour vérifier que l'adresse ne vaut pas 0. D'ou le hack.
Kha
Qui se sent vieux, mais vieux...