Re: compiler warnings on the buildfarm

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: compiler warnings on the buildfarm
Date: 2007-07-15 22:26:25
Message-ID: 14341.1184538385@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> Tom Lane wrote:
>> What I suspect is happening is that lionfish is running the buildfarm
>> script in a non-C locale, in which flex finds that some high-bit-set
>> characters are case-folded by tolower() and accordingly issues this
>> complaint. Now the statements that "it assumes you meant the literal
>> numeric range" and that the behavior is fully determined at compile time
>> (ie, no run-time invocations of tolower(), as indeed are not to be seen
>> in pl_scan.c) seem to mean that we'll get the behavior we want anyway.
>> But the warning is a bit nervous-making.

> hmmm - note that lionfish is not the only box reporting that kind of
> warning - also affected are:
> rosella (which is definitly running in a non-C locale as all the errors
> are in german there)
> wildebeest

I looked at the flex source code and it seems that indeed we *should*
expect to see that warning if we run flex in a locale in which any
characters in the range \200-\377 are letters that case-fold to plain
ASCII. Turkish ought to meet that criterion (the ol dotted vs dotless
i business) but I'm not sure about German. I could not get the warning
on plpgsql's scan.l with a local build of flex 2.5.33, though, no matter
what locale I ran it in. Odd.

Anyway, I tweaked plpgsql's Makefile to force LC_CTYPE=C, which
theoretically should silence this warning.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-07-15 22:44:23 Re: compiler warnings on the buildfarm
Previous Message Simon Riggs 2007-07-15 22:16:18 Re: plpgsql and qualified variable names