Обсуждение: tiny fix needed

Heads up.

I have just discovered a tiny fix that is needed when compiling on Windows
with a very late model libintl.h. Essentially we need to add vfprintf to
the list of items we stop the libintl headers from hijacking. I am still
testing, but this change (3 extra lines in port.h) should be very low
risk.

(I am also on the track of some Cygwin oddness, but that could just be my
setup, and I don't think we should hold up anything for it.)

cheers

andrew

"Andrew Dunstan" <andrew@dunslane.net> writes:
> I have just discovered a tiny fix that is needed when compiling on Windows
> with a very late model libintl.h. Essentially we need to add vfprintf to
> the list of items we stop the libintl headers from hijacking. I am still
> testing, but this change (3 extra lines in port.h) should be very low
> risk.

Hm, you mean only

#ifdef vfprintf
#undef vfprintf
#endif

This seems a bit strange, because the other functions such as vsnprintf
have several other relevant bits in port.h, plus supporting code in
src/port/ ... why wouldn't we need all of that?
        regards, tom lane

Tom Lane wrote:
> "Andrew Dunstan" <andrew@dunslane.net> writes:
>> I have just discovered a tiny fix that is needed when compiling on
>> Windows
>> with a very late model libintl.h. Essentially we need to add vfprintf to
>> the list of items we stop the libintl headers from hijacking. I am still
>> testing, but this change (3 extra lines in port.h) should be very low
>> risk.
>
> Hm, you mean only
>
> #ifdef vfprintf
> #undef vfprintf
> #endif
>
> This seems a bit strange, because the other functions such as vsnprintf
> have several other relevant bits in port.h, plus supporting code in
> src/port/ ... why wouldn't we need all of that?
>


*sigh* you could well be right. I will dig some more. It only happens for
ECPG - everything else links just fine.

cheers

andrew

Andrew Dunstan wrote:
> Tom Lane wrote:
>   
>> "Andrew Dunstan" <andrew@dunslane.net> writes:
>>     
>>> I have just discovered a tiny fix that is needed when compiling on
>>> Windows
>>> with a very late model libintl.h. Essentially we need to add vfprintf to
>>> the list of items we stop the libintl headers from hijacking. I am still
>>> testing, but this change (3 extra lines in port.h) should be very low
>>> risk.
>>>       
>> Hm, you mean only
>>
>> #ifdef vfprintf
>> #undef vfprintf
>> #endif
>>
>> This seems a bit strange, because the other functions such as vsnprintf
>> have several other relevant bits in port.h, plus supporting code in
>> src/port/ ... why wouldn't we need all of that?
>>
>>     
>
>
> *sigh* you could well be right. I will dig some more. It only happens for
> ECPG - everything else links just fine.
>
>
>   

Hmm. Well, it turns out that pg_vfprintf is declared static in our 
snprintf.c. The only place vfprintf is used in the backend is in elog.c, 
although it is used in a variety of frontend programs, so it looks like 
this needs to be fixed properly.

Is there any reason we shouldn't treat vfprintf the same as other 
members of the printf family? It will certainly mean more that 3 lines, 
although I think the changes could possibly still be confined largely to 
port.h.

Of course, we could leave this for a dot release - I notice that the 
Windows buildfarm members are building happily, and I assume they have 
an earlier version of gettext/libiconv than I have just installed on my 
new laptop. But that would be a bit of a pity.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Hmm. Well, it turns out that pg_vfprintf is declared static in our 
> snprintf.c. The only place vfprintf is used in the backend is in elog.c, 
> although it is used in a variety of frontend programs, so it looks like 
> this needs to be fixed properly.

> Is there any reason we shouldn't treat vfprintf the same as other 
> members of the printf family?

It certainly seems odd that we don't.  I suppose that at some point
someone thought that vfprintf wasn't used anywhere --- but obviously
it is now, so I'd vote for changing it.  Given that we do have working
(because used by other entry points) pg_vfprintf, I'd argue that this
is a trivial fix and OK to do after RC1.
        regards, tom lane