Обсуждение: ecpg problem : pre-processor translated long constant to char

Поиск
Список
Период
Сортировка

ecpg problem : pre-processor translated long constant to char

От
Raymond Fung
Дата:
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.



Re: ecpg problem : pre-processor translated long constant to char

От
Michael Meskes
Дата:
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!