Re: Access violation from palloc, Visual Studio 2005, C-language function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Flanagan" <kevin-f(at)linkprior(dot)com>
Cc: "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Access violation from palloc, Visual Studio 2005, C-language function
Date: 2010-03-10 22:42:51
Message-ID: 21691.1268260971@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Flanagan" <kevin-f(at)linkprior(dot)com> writes:
> Aha. I'd read that the build process for the contrib modules involved
> generating a .DEF file for the necessary exports. I had the impression that
> defining BUILDING_DLL was an alternative, addressing (part) of the issue
> (that is, PG_FUNCTION_INFO_V1 declares functions as 'extern PGDLLIMPORT',
> and if you define BUILDING_DLL, then PGDLLIMPORT is defined as ' __declspec
> (dllexport)'). But you're quite right, if I take out the BUILDING_DLL
> definition, and put the __declspec (dllexport) stuff in piecemeal, the
> access violation goes away. Thank goodness.

I remember having complained that that part of the PG_FUNCTION_INFO_V1
macro seemed backwards, and never really getting a satisfactory
explanation of why it isn't (ie, why it shouldn't be designed to expand
as __declspec (dllexport) instead). But anyway, I think the
conventional wisdom for exporting functions from a loadable module is
to use "dlltool --export-all" rather than bothering with being
selective.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-03-10 22:45:25 Re: PD_ALL_VISIBLE flag error on 9.0 alpha 4
Previous Message Heikki Linnakangas 2010-03-10 21:08:44 Re: PD_ALL_VISIBLE flag error on 9.0 alpha 4