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

[Bernd]

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:


{$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;
  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