Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ViSolve Open Source Team writes:
>> 2. genbki.sh: a one-line change that fixes a string concatenation problem with the
>> HP-C compiler (specific to included .c files).
> You're doing this:
> -TMPFILE="$TMPDIR/genbkitmp$$.c"
> +TMPFILE="$TMPDIR/genbkitmp$$.h"
> I'm afraid this will not fly, because calling the preprocessor is only
> portable on .c files. Generally, it's also unwise to rely in this kind of
> subtle side effect. We need a general solution.
I've been looking at this problem, and I think that in fact the HP
compilers are exposing a bogus assumption in our code. The reason that
genbki.sh fails on these compilers is that it effectively assumes that
adjacent string literals, such as
"foo" "bar"
will not be concatenated into a single string literal by 'cpp'.
Otherwise, some entries in pg_proc.h get messed up, such as this one:
DATA(insert OID = 1176 ( timestamptz PGNSP PGUID 14 f f t f s 2 1184 "1082 1083"
"select cast(($1 + $2) as timestamp with time zone)" - _null_ ));
In future other catalogs might have similar issues.
But since the ANSI C spec requires adjacent string literals to be
concatenated, that step has to happen *someplace* in the compiler.
I cannot fault HP for choosing to implement it in cpp rather than
some later step of compilation. Therefore this is really our fault
not theirs; we are making an unwarranted assumption about the
behavior of cpp.
It strikes me however that there is a really simple solution, which
is to stop invoking cpp at all during genbki.sh. It is not doing
*anything* of value for us ... merely introducing portability hazards.
The generated temp file that is fed to cpp does not contain any
#-sign preprocessor commands, nor any macros to be expanded. When
using gcc, the only difference between cpp's input and output is
the addition of a comment line like this:
# 1 "genbkitmp12116.c"
It appears that there was once provision to do more interesting things
via cpp: the Makefile and genbki shell script contain provisions to
pass additional switches to cpp, which presumably might be used to
insert "-D" switches so that identifiers could be expanded to something
else in the BKI data. But we aren't using that, and have not done so
for a very long time. Instead we expect genbki.sh itself to replace
everything that needs replacing (NAMEDATALEN etc). I see no reason
why we'd abandon that technique in favor of using cpp again.
So I propose that we remove the cpp invocation and associated
infrastructure from genbki.sh. Any objections?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
