Skip site navigation (1) Skip section navigation (2)

Re: ECPG failure on BF member Vaquita (Windows Vista)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Mark Wong <markwkm(at)gmail(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ECPG failure on BF member Vaquita (Windows Vista)
Date: 2007-04-25 20:38:30
Message-ID: 5575.1177533510@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> But I also see that my amd64/FC6 machine does pass these tests with gcc.

Yeah, but the typedef represented by va_list can and probably does vary
between amd64 and ppc64.  I haven't an easy way to check, but I wonder
whether it's not an array type on ppc.

I'm of the opinion that ecpg is trying to do something here that's not
portable.  The C99 draft I have says

       [#3] The type declared is

               va_list

       which is an object type  suitable  for  holding  information
       needed  by the macros va_start, va_arg, va_end, and va_copy.
       If access to the varying arguments is  desired,  the  called
       function  shall declare an object (referred to as ap in this
       subclause) having type va_list.  The object ap may be passed
       as an argument to another function; if that function invokes
       the va_arg macro with parameter ap, the value of ap  in  the
       calling function is indeterminate and shall be passed to the
       va_end macro prior to any further reference to ap. (198)

       ____________________

      198 It is permitted to create a pointer to a va_list and pass
          that  pointer  to  another  function,  in  which case the
          original function may make further use  of  the  original
          list after the other function returns.

The footnote seems to say that what the code is doing is OK ... but
there isn't any such footnote in the Single Unix Spec:
http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
which makes me wonder just how portable it really is.

My recommendation is to get rid of the APREF hack, deal only in
va_list not &va_list, and inline ECPGget_variable into the two
places it's used to avoid the question of passing va_lists around
after they've been modified.  The routine's not that big (especially
seeing that only half of it is actually shared by the two callers)
and it's just not worth the notational effort, let alone any portability
risks, to factor it out.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Gustavo ToniniDate: 2007-04-25 20:46:04
Subject: Re: Fragmentation project
Previous:From: Bruce MomjianDate: 2007-04-25 20:28:25
Subject: My upcoming travel

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group