lib_pad of struct Library
-
Ce ne serait pas pour indiquer qu’une library possède une interface PPC avec les versions 50 et plus ?
Et si je mets 0x80 dedans ça fait quoi ?
(en fait j’ai besoin d’un flag pour différencier des drivers internes/chargés du disque, et je ne trouve pas d’astuce)
Les ploucs hyperos l’utilisent. Et donc tout programme ayant oublié de le mettre à 0 ne fonctionne plus.
Si ils ont été capables de l’utiliser c’est qu’ils sont pas aussi ploucs que ça …
C’est plutôt ceux qui ne l’utilisent pas qui sont des ploucs …
Vu que ça existe, faut l’utiliser
Tu l’utilises Hénès ? Bah non tu l’utilises pas vu que tu codes pas sur AOS4 :p Donc … T’es un plouc !!!
MDR
Et si je mets 0x80 dedans ça fait quoi ?
(en fait j’ai besoin d’un flag pour différencier des drivers internes/chargés du disque, et je ne trouve pas d’astuce)
Si tu veux être compatible avec OS4, ça m’étonnerait que ce soit une bonne idée, vu qu’on sait pas trop l’effet que pourrait avoir les autres valeurs différentes de 0. Tu cherches à faire quoi exactement ?
Oh mon dieu ! Mais c’est encore pire que de ne pas respecter l’ABI System XII version 26 révision 2 d’octobre 1978…
Ce ne serait pas pour indiquer qu’une library possède une interface PPC avec les versions 50 et plus ?
Possible. J’avais vu cela il y a des années et, vu l’intérêt relatif que je porte au tout, je ne me souviens vraiment pas
Et si je mets 0x80 dedans ça fait quoi ?
Puisqu’ils ont décidé de considérer comme réservé ce champ qui ne l’était pas jusqu’ici (à méditer pour ceux qui ont posté n’importe quoi dans ce thread sans réfléchir), je suivrais le conseil de centaurz et je ne me poserais même pas la question si j’étais toi…
(en fait j’ai besoin d’un flag pour différencier des drivers internes/chargés du disque, et je ne trouve pas d’astuce)
Je crois que je ne vais pas trop pouvoir t’aider mais il doit y avoir un moyen. Peut-être essayer de chercher du côté des seglists (dos/FindSegment() ?).
Mod(en fait j’ai besoin d’un flag pour différencier des drivers internes/chargés du disque, et je ne trouve pas d’astuce)
Pour chaque device parcouru dans la liste, tu peux essayer de le retrouver dans DEVS: directement sur le disque.
Et concernant l’usage de lib_pad, cette variable porte bien son nom : elle sert à aligner sur 16bits… et n’a pas d’autre usage. Les RKM disent surement mettre à zéro et de ne pas l’utiliser… Quiconque enfreint la loi périra dans d’immenses douleurs rectales pour la nuit des temps.
Si il avait fallu ajouter un quelque chose à tout cela, un nouveau lib_Flags aurait généralement suffit à résoudre le problème tout en gardant une compatibilité exemplaire.
Je ne sais pas ce qu’il a été fait du lib_pad côté OS4, mais quelque soit son usage, j’abonde l’avis de Henes.
Tchecko:
Et concernant l’usage de lib_pad, cette variable porte bien son nom : elle sert à aligner sur 16bits… et n’a pas d’autre usage. Les RKM disent surement mettre à zéro et de ne pas l’utiliser… Quiconque enfreint la loi périra dans d’immenses douleurs rectales pour la nuit des temps.
Si il avait fallu ajouter un quelque chose à tout cela, un nouveau lib_Flags aurait généralement suffit à résoudre le problème tout en gardant une compatibilité exemplaire. Je ne sais pas ce qu’il a été fait du lib_pad côté OS4, mais quelque soit son usage, j’abonde l’avis de Henes.
Je suis en partie d’accord avec toi : comme son nom l’indique lib_pad sert à aligner aucun programmeur ne devrait l’utiliser pour y caser quoi que ce soit.
Mais je suis aussi pas d’accord : en tant que concepteur du système un programmeur peut tout à fait décider qu’un champ de bourrage auparavant privé (je ne sais pas moi mais tout champ d’une structure système non documenté comme modifiable est privé) va servir à autre chose. Après je ne ferais que te citer :
Quiconque enfreint la loi périra dans d’immenses douleurs rectales pour la nuit des temps.
Gilloo:
Et ajouter une API dans ton driver pour indiquer s’il est interne ou non ?
Sinon qui déclenche le chargement de tes drivers ? Si c’est ta pile USB ne peut-elle maintenir la liste des drivers disques ?
en tant que concepteur du système un programmeur peut tout à fait décider qu’un champ de bourrage auparavant privé (je ne sais pas moi mais tout champ d’une structure système non documenté comme modifiable est privé) va servir à autre chose.
Certes mais tu me sembles plutot parler d’un champ réservé Le concepteur du système va alors te spécifier à quelle valeur tu dois initialiser ce champ (s’il s’agit d’une entrée fournie à l’API) pour être compatible avec toute évolution future.
A moins que je sois aveugle, rien de tout cela ici.
PS: j’espère au moins que quelqu’un a vérifié l’axiome de mon troll initial avant d’essayer de défendre ce choix complètement stupide
Certes mais tu me sembles plutot parler d’un champ réservé Le concepteur du système va alors te spécifier à quelle valeur tu dois initialiser ce champ (s’il s’agit d’une entrée fournie à l’API) pour être compatible avec toute évolution future.
A moins que je sois aveugle, rien de tout cela ici.
C’est marrant mais j’ai plutôt la démarche inverse : dans une structure système tout champ qui ne m’est pas indiqué expressément comme modifiable est considéré comme privé ou au moins en lecture seule. Après venir taper dans ce champ pour le positionner à d’autres valeurs ça reste aléatoire…
Pour moi un champ de bourrage == un champ privé (ou réservé si tu préfères), et ne veut certainement pas dire « allez-y mettez ce que vous voulez à cet emplacement », ça chez moi c’est un champ qui s’appelle « UserData »
PS: j’espère au moins que quelqu’un a vérifié l’axiome de mon troll initial avant d’essayer de défendre ce choix complètement stupide
Tu as raison il serait bon de vérifier cela pour répondre à la question initiale de Gilloo, malheureusement mon A1 est actuellement en panne je ne pourrais pas le faire moi-même. Toutefois je parlais de manière générale sur le fait d’utiliser un champ de bourrage.
C’est marrant mais j’ai plutôt la démarche inverse : dans une structure système tout champ qui ne m’est pas indiqué expressément comme modifiable est considéré comme privé ou au moins en lecture seule.
On doit avoir un problème de communication car je ne dit pas le contraire
Après venir taper dans ce champ pour le positionner à d’autres valeurs ça reste aléatoire…
Dans le cas d’une structure qui est retournée par le système je suis d’accord. Mais ce n’est pas le cas ici et il faut donc initialiser tous les champs avant de passer ce genre de structure aux API système. Dans le cas contraire, le comportement est complètement bugué de manière aléatoire et dépend du contenu de la mémoire à ce moment là…
Le problème est que les octets de padding sont en dehors de tout cela et rien ne précise la valeur à laquelle il faut les initialiser. Contrairement aux champs réservés pour usage futur (Si je me trompe, merci de m’indiquer où cela est précisé. J’aime apprendre:-).
Décider 20 ans après que finalement il fallait les mettre à 0 (et réécrire les docs en ce sens ? ce serait bien dans l’esprit et a déjà été fait pour les functions controlant les caches)… serait stupide
On doit avoir un problème de communication car je ne dit pas le contraire
Peut-être pourtant j’avais l’impression que tu disais qu’il était excusable de venir écrire des données dans un champ de bourrage d’une structure système. Si ce n’est pas le cas, j’en suis désolé et je te présente mes plus sincères excuses. Sauf si… ah non y a pas de « sauf »
Dans le cas d’une structure qui est retournée par le système je suis d’accord. Mais ce n’est pas le cas ici
exec.library/OpenLibrary
Certes mais il me semble que le code de bonne pratique veut que le développeur d’une bibliothèque tierce (s’il a besoin de champs supplémentaires) étende la structure Library plutôt que d’utiliser des champs (supposés inutilisés) de la structure retournée (initialisée) par le système.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › lib_pad of struct Library