Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
Дата
Msg-id 5f184fa6-f22c-1254-7b9c-7382683d3a27@dunslane.net
обсуждение исходный текст
Ответ на Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs

On 05/19/2018 12:45 PM, Tom Lane wrote:
>
> * frogmouth is failing the test too, due to printing values that look
> like the expected 64-bit result has been truncated to 32 bits.
> I suspect this explains it:
>
>    sqlda.pgc: In function 'dump_sqlda':
>    sqlda.pgc:44:4: warning: unknown conversion type character 'l' in format
>    sqlda.pgc:44:4: warning: too many arguments for format
>
> I'm guessing that the native printf() on that platform doesn't know
> "%lld" and is printing the value as 32 bits.  This seems a bit
> problematic to fix.  Using INT64_FORMAT isn't a solution: it's a cheat
> in that it's assuming that "long long" is 64 bits, and what's more,
> it definitely won't fix the problem on frogmouth because that build is
> using our own snprintf and so its value of INT64_FORMAT is calibrated
> to work with our code, ie, it's going to be "%lld" anyway.
>
> However ... we've got a ton of other places that use INT64_FORMAT with
> the native printf, eg in pgbench, and frogmouth is not producing
> warnings about those usages.  So I'm confused about exactly what is
> happening there.  Andrew, do you have any insight?
>
>             

Very occasionally ;-)


A little Googling suggested that __USE_MINGW_ANSI_STDIO might help. 
Here's what happened


    $ cat testme.c
    #include <stdio.h>

    int main(int argc, char **argv)
    {
         long long int val = 1111111111111111111LL;
         printf("sizeof long long = %d\n", sizeof(val));
         printf("val = %lld (%%lld) %I64d (%%I64d)\n",val,val);
         return 0;
    }

    $ gcc -Wall -o testme testme.c
    testme.c: In function 'main':
    testme.c:7:5: warning: unknown conversion type character 'l' in format
    testme.c:7:5: warning: too many arguments for format

    $ ./testme
    sizeof long long = 8
    val = 734294471 (%lld) 3153770738837321131 (%I64d)

    $ gcc -Wall -D__USE_MINGW_ANSI_STDIO -o testme testme.c

    $ ./testme
    sizeof long long = 8
    val = 1111111111111111111 (%lld) 1111111111111111111 (%I64d)



So maybe we just need to define this on XP/mingw (shouldn't be necessary 
on anything later). I don't know what other effects it might have, 
though. Perhaps there is some other flag or define that has the same 
effect that we use in compiling pgbench etc that isn't used by ecpg?

Now recall that this animal is on serious life support. It's on an 
unsupported OS, none of the animals are building the master branch 
because of the huge pages problem, and the compiler here is pretty much 
unsupported also. AFAIK the Msys people now use compilers from the 
mingw-w64 project exclusively, and they probably do the right thing.

Not sure how much more effort I should put in here.

cheers

andrew


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: BUG #15200: Support ANSI OFFSET .. FETCH syntax with bind variables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT