On Mon, Jul 20, 2009 at 3:14 AM, Jeremy Kerrj...@ozlabs.org wrote:
That code is not broken as it stands, and doesn't appear to really
gain anything from the proposed change. Why should we risk any
portability questions when the code isn't going to get either simpler
or shorter?
OK, after
Hi Tom,
That code is not broken as it stands, and doesn't appear to really
gain anything from the proposed change. Why should we risk any
portability questions when the code isn't going to get either simpler
or shorter?
OK, after attempting a macro version of this, we end up with:
#define
Hi Robert,
Perhaps we should use macros.
I was trying to avoid macros, as this means we lose type- and syntax-
checking at the call-site, and end up with slightly messier code.
However, I understand that this is probably personal preference for me
:)
How about just 'static' functions? (ie,
Jeremy Kerr j...@ozlabs.org writes:
However, I'd rather make decisions on data, rather than guessing. Is the
actual problem here that some compilers just don't support the 'inline'
keyword?
I think Alvaro's complaint is unfounded --- we already have logic
to #define inline as empty if the
Tom,
However, I think the whole patch is pretty useless. That code is not
broken as it stands, and doesn't appear to really gain anything from
the proposed change. Why should we risk any portability questions
when the code isn't going to get either simpler or shorter?
This patch clears the
Jeremy Kerr j...@ozlabs.org writes:
We also need disable_sigpipe to be called when it's not the start of a
block, hence the separate type definition.
So break that macro into two (variable definition and code).
regards, tom lane
--
Sent via pgsql-hackers mailing list
Jeremy Kerr wrote:
Also, since we don't need to declare variables in the macros, we
can change the code to be implemented as static inlines.
Does this work in compilers other than GCC? I think we use some kludges
to protect against them ... see pg_list.h for the canonical example.
--
Alvaro
Hi, Alvaro,
Does this work in compilers other than GCC? I think we use some
kludges to protect against them ... see pg_list.h for the canonical
example.
As I understand it, we're not using static inlines in pg_list.h to
prevent multiple objects from exporting the same symbols if the
On Tue, Jul 14, 2009 at 8:42 PM, Jeremy Kerrj...@ozlabs.org wrote:
Hi, Alvaro,
Does this work in compilers other than GCC? I think we use some
kludges to protect against them ... see pg_list.h for the canonical
example.
As I understand it, we're not using static inlines in pg_list.h to
Currently, the sigpipe-masking code in libpq is implemented as
a set of macros, which depend on declaring local variables.
This change adds a (private) struct sigpipe_info to contain the
compile-dependent data required for sigpipe masking and restoring.
The caller can then declare a struct
10 matches
Mail list logo
