ecpg problem : pre-processor translated long constant to char

Started by Raymond Fungover 23 years ago2 messages
#1Raymond Fung
raymondf@acm.org

Dear all,

A simple testing program :

* * * * * * * * * * * * * * begin * * * * * * * * * * * * * * * *

#include <stdio.h>
#include <stdlib.h>

int main (void)
{
unsigned int v;

v = 0x87654321L;

return (0);
}

* * * * * * * * * * * * * * end * * * * * * * * * * * * * * * *

compile with ecpg using :

ecpg -o mytest.c -I/usr/include/pgsql mytest.pgc

produces the output C program file as follow :

* * * * * * * * * * * * * * begin * * * * * * * * * * * * * * * *

/* Processed by ecpg (2.8.0) */
/* These three include files are added by the preprocessor */
#include <ecpgtype.h>
#include <ecpglib.h>
#include <ecpgerrno.h>
#line 1 "test.pgc"
#include <stdio.h>
#include <stdlib.h>

int main (void)
{
unsigned int v;

v = '0x87654321'L;

return (0);
}

* * * * * * * * * * * * * * * end * * * * * * * * * * * * * * *

It has translated the 4 bytes constant (0x87654321) into a one byte
char constant (within the single quotes) during pre-processing. Seems
this happens only when the high bit of the constant is set (i.e. it
won't add the quotes if the constant is 0x12345678).

Also, I noticed that the line number reported during the preprocessing
error output is incorrect : it is '1' less than the actual line number
in the source file. As shown, I am using version 2.8.0 of ecpg. Is my
version being too old to be buggy ? Any suggestion to bypass the
translation problem ?

Thanks,
Raymond Fung.

#2Michael Meskes
meskes@postgresql.org
In reply to: Raymond Fung (#1)
Re: [HACKERS] ecpg problem : pre-processor translated long constant to char

On Thu, Jul 04, 2002 at 10:00:01AM +0800, Raymond Fung wrote:

Dear all,
...
It has translated the 4 bytes constant (0x87654321) into a one byte
char constant (within the single quotes) during pre-processing. Seems
this happens only when the high bit of the constant is set (i.e. it
won't add the quotes if the constant is 0x12345678).

Yes, this is a bug. But look here:

mm=# create table test (i int8);
CREATE
mm=# insert into test values (x'80000000');
ERROR: Bad hexadecimal integer input '80000000'
mm=# insert into test values (1234567890123);
INSERT 22762 1

The reason is that both the backend parser and the ecpg parser use
strtol to parse the hex constant. And strtol does not like anything >
0x80000000.

Also, I noticed that the line number reported during the preprocessing
error output is incorrect : it is '1' less than the actual line number
in the source file. As shown, I am using version 2.8.0 of ecpg. Is my
version being too old to be buggy ? Any suggestion to bypass the
translation problem ?

I heard about the off-by-one problem sometimes, but I've yet to find the
time to look for the reason. A collegue is bugging me all the time. :-)

Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!