Martijn van Oosterhout wrote:
> On Fri, May 04, 2007 at 02:18:31PM +0200, Zdenek Kotala wrote:
> > Is the reason for keeping this in a code? Another kind of construct is:
> >
> > #define PG_RETURN_NULL() \
> > do { fcinfo->isnull = true; return (Datum) 0; } while (0)
>
> This is a standard w
On Fri, May 04, 2007 at 02:18:31PM +0200, Zdenek Kotala wrote:
> Is the reason for keeping this in a code? Another kind of construct is:
>
> #define PG_RETURN_NULL() \
> do { fcinfo->isnull = true; return (Datum) 0; } while (0)
This is a standard way of getting multiple statements into a mac
Zdenek Kotala wrote:
Tom Lane wrote:
We can fix this for gcc by putting __attribute__((noreturn)) on the
declaration of pg_re_throw(), but what about other compilers?
Sun studio also complains about it :(.
I'm sorry it was to late for me, I recheck it again and Sun studio is
happy :-) and
Tome Lane wrote:
> We can fix this for gcc by putting __attribute__((noreturn)) on the
> declaration of pg_re_throw(), but what about other compilers?
For MSVC 2005 use __declspec(noreturn) (see [1]). I think this also work for
some older versions of MSVC.
Regards,
Hannes Eder
References:
[1] h
"Hannes Eder" <[EMAIL PROTECTED]> writes:
> Tome Lane wrote:
>> We can fix this for gcc by putting __attribute__((noreturn)) on the
>> declaration of pg_re_throw(), but what about other compilers?
> For MSVC 2005 use __declspec(noreturn) (see [1]). I think this also work for
> some older versions
Tom Lane wrote:
We can fix this for gcc by putting __attribute__((noreturn)) on the
declaration of pg_re_throw(), but what about other compilers?
Sun studio also complains about it :(.
Zdenek
---(end of broadcast)---
TIP 5: don
I just noticed that my recent change to prevent PG_RE_THROW from dying
if there's noplace to longjmp to has provoked a whole lot of warnings
that were not there before. Apparently this is because gcc understands
that siglongjmp() never returns, but is not equally clueful about
pg_re_throw().
We c
