Stefan Kaltenbrunner just let me know via Jabber that there's a warning
in pg_regress.c:

pg_regress.c: In function `spawn_process':
pg_regress.c:914: warning: missing sentinel in function call

This small patch would seem to fix it, according to
http://www.linuxonly.nl/docs/sentinel/



--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"Los románticos son seres que mueren de deseos de vida"


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Alvaro Herrera wrote:
> Stefan Kaltenbrunner just let me know via Jabber that there's a warning
> in pg_regress.c:
>
> pg_regress.c: In function `spawn_process':
> pg_regress.c:914: warning: missing sentinel in function call
>
> This small patch would seem to fix it, according to
> http://www.linuxonly.nl/docs/sentinel/

You can apply this, but it sure seems like a compiler/include file bug
to me, even with the 64-bit explaination.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bruce Momjian <bruce@momjian.us> writes:
> Alvaro Herrera wrote:
>> pg_regress.c: In function `spawn_process':
>> pg_regress.c:914: warning: missing sentinel in function call

> You can apply this, but it sure seems like a compiler/include file bug
> to me, even with the 64-bit explaination.

There are lots of platforms where the include files and the compiler are
not all that compatible, gcc + vendor include files being the prototype
case. It's too bad that gcc doesn't have a
-Wno-snarkiness-about-system-headers-thank-you switch.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> It's too bad that gcc doesn't have a
> -Wno-snarkiness-about-system-headers-thank-you switch.

It does have a switch to *add* snarkiness about system headers, but does
not do it by default.

The problem in this case is that an uncast null pointer constant is not
always a sufficient sentinel for variadic functions, as explained here:
<http://c-faq.com/null/null2.html>.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> It's too bad that gcc doesn't have a
>> -Wno-snarkiness-about-system-headers-thank-you switch.

> It does have a switch to *add* snarkiness about system headers, but does
> not do it by default.

> The problem in this case is that an uncast null pointer constant is not
> always a sufficient sentinel for variadic functions, as explained here:
> <http://c-faq.com/null/null2.html>.

Sure, but on a machine where it actually matters (ie one where int and
pointer are of different sizes), I'd expect NULL to be #define'd as
"((void *) 0)" not just "0". You should *not* have to inform the
machine that NULL is a pointer.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Am Mittwoch, 18. Juli 2007 16:16 schrieb Tom Lane:
> You should *not* have to inform the machine that NULL is a pointer.

For variadic functions, that expectation is invalid, AFAIK.

It might be good to check the actual definition of NULL in this case, however,
before wondering further.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Peter Eisentraut wrote:
> Am Mittwoch, 18. Juli 2007 16:16 schrieb Tom Lane:
> > You should *not* have to inform the machine that NULL is a pointer.
>
> For variadic functions, that expectation is invalid, AFAIK.

No, what's invalid is that using an unadorned 0 is understood as a "null
pointer" by the compiler. That would happen in a lot of places except
on a variadic function.

However, the platform may define NULL as it wishes, and indeed in our
c.h it is defined (conditionally) as (void *)0. If the platform had
such a definition then it would work without issues.

I assume the platform in question does something like
#define NULL 0
which would be silly.

--
Alvaro Herrera http://www.advogato.org/person/alvherre
"El conflicto es el camino real hacia la unión"

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Am Mittwoch, 18. Juli 2007 17:16 schrieb Alvaro Herrera:
> Peter Eisentraut wrote:
> > Am Mittwoch, 18. Juli 2007 16:16 schrieb Tom Lane:
> > > You should *not* have to inform the machine that NULL is a pointer.
> >
> > For variadic functions, that expectation is invalid, AFAIK.
>
> No, what's invalid is that using an unadorned 0 is understood as a "null
> pointer" by the compiler. That would happen in a lot of places except
> on a variadic function.
>
> However, the platform may define NULL as it wishes, and indeed in our
> c.h it is defined (conditionally) as (void *)0. If the platform had
> such a definition then it would work without issues.
>
> I assume the platform in question does something like
> #define NULL 0
> which would be silly.

I suggest that you read through <http://c-faq.com/null/>, which is at odds
with your statements.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Wed, 2007-07-18 at 16:59 +0200, Peter Eisentraut wrote:
> It might be good to check the actual definition of NULL in this case, however,
> before wondering further.

Well, the existing coding is plainly wrong, regardless of the NULL
implementation used on any given machine (although it will usually
work). The simple rule is "you need to cast NULL to a pointer type when
passing arguments to a variadic function, or to a function whose
prototype is not in scope".

So +1 on this patch from me.

-Neil



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Neil Conway wrote:
> On Wed, 2007-07-18 at 16:59 +0200, Peter Eisentraut wrote:
> > It might be good to check the actual definition of NULL in this case, however,
> > before wondering further.
>
> Well, the existing coding is plainly wrong, regardless of the NULL
> implementation used on any given machine (although it will usually
> work). The simple rule is "you need to cast NULL to a pointer type when
> passing arguments to a variadic function, or to a function whose
> prototype is not in scope".
>
> So +1 on this patch from me.

Thanks, committed. I looked for other uses of execl(), execle() and
execlp() and found a single one of execl() which is already OK.

I wouldn't know how to look for other variadic functions using NULL
sentinels though.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster