Cast int pointeur - pourquoi fonte de première? (à p = (void*) 42; )

Dans le GLib de la documentation, il y a un chapitre sur la conversion de type macros.
Dans la discussion sur la conversion d'une int à un *void pointeur il dit (l'emphase est mienne):

Naïvement, que vous pourriez essayer, mais c'est incorrect:

gpointer p;
int i;
p = (void*) 42;
i = (int) p;

Encore une fois, cet exemple n'est pas correct, ne le copiez pas. Le problème est
que sur certains systèmes, vous devez faire ceci:

gpointer p;
int i;
p = (void*) (long) 42;
i = (int) (long) p;

(source: GLib Manuel de Référence pour GLib 2.39.92, chapitre Type De Macros De Conversion ).

Pourquoi est-ce que la fonte de long nécessaire?

Devrait nécessaires à l'élargissement de la int se produit pas automatiquement dans le cadre de la distribution d'un pointeur?

Je pense que parce que un int peut être 16bit tandis qu'une longue d'au moins 32 bits, vous pouvez obtenir 16 undefined bits si vous le lancez à partir de int directement. Mais alors sur une machine 64 bits, long peut-être encore 32 bits tandis que un pointeur peut avoir la taille 64 bits, d'obtenir le même problème (si elle existe).
Casting entier types de pointeurs mise en œuvre définies par l', ce qui signifie que conforme compilateur doit documenter exactement ce qui se passe ici. Ce serait bien si l'auteur de cette citation spécifié les systèmes nécessaires à la long cast (et encore mieux si ils évitaient cette technique entièrement, car il y a de plus fiable des solutions de rechange)
Oui, ce serait une (ou intptr_t)
Si vous allez à reconvertir le pointeur du même type, par opposition à un large type, vous ne se soucient pas comment il est “étendu” aussi longtemps que la conversion de pointeur à un rétrécissement de type entier, seuls les bits de poids faible (ce qui est le comportement habituel). Depuis il n'est même pas une allusion à une sorte de compilateur, qui permettrait de définir ces conversions de manière à causer des ennuis, je suppose superstitieux non-sens de la part de la glib auteurs.
developer.gnome.org/glib/stable/glib-Basic-Types.html je reste à mon cas. C'est le travail d'une personne ou des personnes qui ne comprennent pas ce qu'ils s'efforcent d'offrir une couche de compatibilité pour. #define G_MINFLOAT FLT_MIN pour “la valeur positive minimale qui peut être tenu dans une gfloat” est simplement faux. Plus important encore, pas une seule définition est utile si vous avez un compilateur C99, et seulement quelques-uns d'assurer la compatibilité avec C90.

OriginalL'auteur sleske | 2014-08-19

  1. 7

    Que, selon l' C99: 6.3.2.3 citation:

    5 Un entier peut être converti en un pointeur de type. Sauf que
    indiqué précédemment, le résultat de la mise en œuvre est définie, pourrait ne pas
    être correctement aligné, pourrait pas à une entité de référence
    type, et peut-être un piège de la représentation.56)

    6 Tout type pointeur peut être converti en un type entier. Sauf que
    indiqué précédemment, le résultat est la mise en œuvre définies. Si l'
    le résultat ne peut être représenté dans le type entier, le comportement est
    undefined. Le résultat n'a pas besoin d'être dans la plage de valeurs de toute
    type entier.

    Selon la documentation, à la lien vous avez mentionné:

    Les pointeurs sont toujours au moins 32 bits (sur toutes les plates-formes de GLib
    a l'intention de soutenir). Vous pouvez ainsi stocker au moins un entier 32 bits valeurs
    une valeur de pointeur.

    Et, de plus,long est assuré d'être au moins 32-bits.

    Donc,le code

    gpointer p;
int i;
p = (void*) (long) 42;
i = (int) (long) p;

    est plus sûr,plus portable, et bien définis pour jusqu'à 32 bits des nombres entiers, comme annoncé par la GLib.

    Désolé, mais je ne suis pas. Comment faire la liste des devis, vous expliquez que le casting de long est plus sûr et plus portable?
    Les pointeurs sont toujours au moins 32 bits(où GLib irait à l') et long est assuré d'être au moins 32-bits. Donc, il n'y a pas de différence de taille sur les systèmes où GLib seront en cours d'exécution. Alors que int n'est pas garanti d'être en 32 bits.
    et de plus, donc la portabilité de la garantie est uniquement pour les entiers jusqu'à 32 bits.
    Je reçois pourquoi vous lancez 42 de long et ensuite à vide*. Mais ce qui est le point de coulée d'abord et puis d'int? Si p est plus long à l'origine, vous devez d'abord tronquer à long, puis à l'int. Si p est un plus court que int-vous également de ne rien gagner.
    Je seconde @mcsim commentaire. Pourriez-vous clarifier ce point?

    OriginalL'auteur askmish

  2. 1

    Je pense que c'est parce que cette conversion est mise en œuvre dependendant. Il est préférable d'utiliser uintptr_t pour ce faire, parce que c'est exactement le type de pointeur en particulier la mise en œuvre.

    size_t est un type entier non signé destinées à contenir la taille maximale d'un objet, pas la taille d'un pointeur. uintptr_t est un type entier non signé a l'intention de tenir la représentation d'un pointeur, et son existence dans le standard de la montre en elle-même que size_t n'est pas cela.

    OriginalL'auteur DoctorMoisha