[fpc-pascal] header translation question, 64 bit problem

[ik]

On Sun, Jun 17, 2012 at 2:02 AM, Bernd <prof7bit at googlemail.com> wrote:

> Hi,
>
> I am translating parts of the libpurple headers. Now I seem to have a
> problem with this:
>
>
> typedef enum
> {
>        PURPLE_PLUGIN_UNKNOWN  = -1,  /**< Unknown type.    */
>        PURPLE_PLUGIN_STANDARD = 0,   /**< Standard plugin. */
>        PURPLE_PLUGIN_LOADER,         /**< Loader plugin.   */
>        PURPLE_PLUGIN_PROTOCOL        /**< Protocol plugin. */
>
> } PurplePluginType;
>
>
> typedef int PurplePluginPriority;
>
>
> struct _PurplePluginInfo
> {
>        unsigned int magic;
>        unsigned int major_version;
>        unsigned int minor_version;
>        PurplePluginType type;               // <-- maybe this is the
> problem?
>        char *ui_requirement;
>        unsigned long flags;
>        GList *dependencies;
>        PurplePluginPriority priority;
>
>        char *id;
>        char *name;
>        char *version;
>        char *summary;
>        char *description;
>        char *author;
>        char *homepage;
>
>        /**
>         * If a plugin defines a 'load' function, and it returns FALSE,
>         * then the plugin will not be loaded.
>         */
>        gboolean (*load)(PurplePlugin *plugin);
>        gboolean (*unload)(PurplePlugin *plugin);
>        void (*destroy)(PurplePlugin *plugin);
>
>        void *ui_info; /**< Used only by UI-specific plugins to build a
> preference screen with a custom UI */
>        void *extra_info;
>        PurplePluginUiInfo *prefs_info; /**< Used by any plugin to display
> preferences.  If #ui_info has been specified, this will be ignored. */
>
>        /**
>         * This callback has a different use depending on whether this
>         * plugin type is PURPLE_PLUGIN_STANDARD or PURPLE_PLUGIN_PROTOCOL.
>         *
>         * If PURPLE_PLUGIN_STANDARD then the list of actions will show up
>         * in the Tools menu, under a submenu with the name of the plugin.
>         * context will be NULL.
>         *
>         * If PURPLE_PLUGIN_PROTOCOL then the list of actions will show up
>         * in the Accounts menu, under a submenu with the name of the
>         * account.  context will be set to the PurpleConnection for that
>         * account.  This callback will only be called for online accounts.
>         */
>        GList *(*actions)(PurplePlugin *plugin, gpointer context);
>
>        void (*_purple_reserved1)(void);
>        void (*_purple_reserved2)(void);
>        void (*_purple_reserved3)(void);
>        void (*_purple_reserved4)(void);
> };
>
>
>
> I have translated it as follows:
>

you have few problems here.
1. Please use ctypes instead, they are set to work properly with 64 bit
etc.. and are properly sized to fit C's type sizes.
For example C's int, is not equal to Pascal's Integer, but to longint of
Pascal


>
>
> {$calling cdecl}
>
> type
>  TPurplePluginType = (
>    PURPLE_PLUGIN_UNKNOWN  := -1,  // Unknown type.
>    PURPLE_PLUGIN_STANDARD := 0,   // Standard plugin.
>    PURPLE_PLUGIN_LOADER,          // Loader plugin.
>    PURPLE_PLUGIN_PROTOCOL         // Protocol plugin.
>  );
>
>  TPurplePluginPriority = Integer;
>
>  TPurplePluginInfo = packed record
>    magic: Integer;
>    major_version: Integer;
>    minor_version: Integer;
>    plugintype: TPurplePluginType;
>    ui_requirement: PChar;
>    flags: LongInt;
>    dependencies: PGList;
>    priority: TPurplePluginPriority;
>    id: PChar;
>    name: PChar;
>    version: PChar;
>    summary: PChar;
>    description: PChar;
>    author: PChar;
>    homepage: PChar;
>    load: function(plugin: PPurplePlugin): GBoolean;
>    unload: function(plugin: PPurplePlugin): GBoolean;
>    destroy: procedure(plugin: PPurplePlugin);
>    ui_info: Pointer;
>    extra_info: Pointer;
>    prefs_info: PPurplePluginUiInfo;
>    actions: function(plugin: PPurplePlugin; context: Pointer): PGList;
>
>    _purple_reserved1: Pointer;
>    _purple_reserved2: Pointer;
>    _purple_reserved3: Pointer;
>    _purple_reserved4: Pointer;
>

This 4 types are actually callback rather then "simple" pointers. It will
work, but personally I prefer it as a callback when I can avoid general
"Pointer".


>  end;
>
> This works perfectly well on windows 32 bit and Linux 32 bit but today
> someone helped me compile it on linux x86_64 and from the debug output
> of libpurple it seems that when I pass it this record initialized with
> my values it *can* detect that plugintype is set to
> PURPLE_PLUGIN_PROTOCOL because then it will try to read extra_info and
> it thinks it is null, probably it is off a few bytes.
>
> I cannot test this myself because I don't have a 64 bit Linux. When an
> experienced programmer (should be most on this list) looks at this
> header what is the obvious thing that might break it on 64 bit?
> Pointers should be ok, but what is with int and Integer and what is
> with enums? And are there maybe also certain compiler switches that
> influence it?  What might be wrong?
>
> Bernd
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20120617/f776465b/attachment.html>