Je dois avouer que je ne me souviens pas pourquoi j'avais (je crois me souvenir quand même que c'est moi qui avait fait ça) séparé les cas unsigned/signed. Quand je vois le code... je me dit qu'il n'y a pas de raison de séparer les cases DADI_INT, DADI_UINT et DADI_COUNTER... au final, le code exécuté est le même. Le code faisait déjà la différence... je me suis probablement dit que c'était plus propre comme ça.
La justification de la différence entre intptr_t et uintptr_t m'échape. Peut-être qu'il existe qque part une architecture qui gère les deux cas différemment. Je suis pratiquement certain que dadi ne rencontrera jamais une telle arcitecture. A+ Jérôme Le 25 juillet 2013 18:50, David <cmoida...@gmail.com> a écrit : > Je comprends mieux cette histoire de uintptr_t. > > Par contre, du coup, on ne pourrait pas remplacer le intptr_t par un > uintptr_t? > On est d'accord qu'il n'y a pas de rapport entre le fait que le pointeur > pointe vers un int (ou un unsigned) et le choix de intptr_t (ou uintptr_t)? > > Merci pour le merge dans la branche master. > D'autres patchs, évolutions cette fois, sont en préparation. > > David > > Le 24 juillet 2013 14:25, Jerome Arbez-Gindre <jeromearbezgin...@gmail.com > > a écrit : > > A propos du patch intptr.patch, >> >> L'idée est de déclarer un type entier capable d'"acceuillir" un >> pointeur... suivant l'architecture sur laquelle on tourne. >> Ca ne dispense pas de faire les casts... >> >> C'est juste la façon standard de déclarer un type qui fera soit 16 bits >> (rare de nos jours), 32 bit ou 64 bits (moins rare de nos jours) suivant >> l'architecture du proc et de l'OS installé. >> >> Quand je travaillais encore sur dadi, je m'étais installé une debian 64 >> bits... la compilation ne passait pas sans ce patch ! >> >> En principe, c'est sans impacts négatifs ! >> >> Jérôme >> >> >> PS : le message "caché" est que la branche "multimib" de libdadi >> fonctionne très bien (avec ce patch) sur une debian 64 bits. >> >> >> Le 24 juillet 2013 09:55, MOREAU David < >> david.mor...@thalesaleniaspace.com> a écrit : >> >>> Bonjour,**** >>> >>> ** ** >>> >>> Nous avons effecué des tests avec la dernière version de dadi >>> (4.4.0-2-g8399075) sur CentOS6 et je me permets de vous proposer quelques >>> patchs que nous avons **** >>> >>> dû appliquer.**** >>> >>> ** ** >>> >>> *0001-Add-uint64_t-cast-before-bitwise-shift-avoid-gcc-war.patch* >>> >>> Pour éviter un warning de gcc (4.4.6).**** >>> >>> ** ** >>> >>> *0002-CMakeLists.txt-Add-gcc-flags-to-ignore-some-cast-war.patch* >>> >>> Idem, cette fois si pas de cast possible, donc nous avons ajouté les >>> flags gcc qui vont bien (-Wno-int-to-pointer-cast -Wno-pointer-to-int-cast) >>> **** >>> >>> ** ** >>> >>> *0003-Change-InetAddressType-from-uint-to-int.patch* >>> >>> Le type InetAddressType est déclaré en INTEGER dans INET-ADDRESS-MIB >>> (pas unsigned).**** >>> >>> ** ** >>> >>> *0004-Fix-Add-templates-for-uint64_t-values-in-table.patch* >>> >>> Pour faire fonctionner les COUNTER64 dans un tableau.**** >>> >>> ** ** >>> >>> *0005-Fix-add-null-character-after-strncpy.patch* >>> >>> Correction d'un regression sur les chaines de caractères.**** >>> >>> ** ** >>> >>> Le patch de Fred (83990756707fd9e5f35b551edc3a3135b6366e62) pour les >>> enums est OK.**** >>> >>> ** ** >>> >>> *intptr.patch* >>> >>> Ce n'est pas un patch que nous avons appliqué mais on nous n'avons pas >>> compris l'utilisation des intptr_t et uintptr_t.**** >>> >>> Nous aurions plutot "transtypé" avec des int et des unsigned. >>> Auriez-vous une explication?**** >>> >>> ** ** >>> >>> Voilà pour le moment.**** >>> >>> ** ** >>> >>> David**** >>> >>> ** ** >>> >>> -------------------------**** >>> >>> Moreau David**** >>> >>> Thales Alenia Space**** >>> >>> CCSL -- DVB**** >>> >>> 05.34.35.43.19**** >>> >>> [@@ THALES ALENIA SPACE INTERNAL @@]**** >>> >>> RESTRICTED@@]**** >>> >>> ** ** >>> >>> _______________________________________________ >>> Tsp-devel mailing list >>> Tsp-devel@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/tsp-devel >>> >>> >> >> _______________________________________________ >> Tsp-devel mailing list >> Tsp-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/tsp-devel >> >> > > _______________________________________________ > Tsp-devel mailing list > Tsp-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tsp-devel > >
_______________________________________________ Tsp-devel mailing list Tsp-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tsp-devel
