Unescaped new lines in postgres
From the gcc 3.0.2 release ntoes:
"The poorly documented extension that allowed string constants in C, C++ and
Objective C to contain unescaped newlines has been deprecated and may be
removed in a future version. Programs using this extension may be fixed in
several ways: the bare newline may be replaced by \n, or preceded by \n\, or
string concatenation may be used with the bare newline preceded by \n" and "
placed at the start of the next line. "
I seem to recall that I came across a fair bit of this kind of thing in the
psql source code at least. I wonder if it should be fixed to be
compliant...
Chris
Can you show an example?
---------------------------------------------------------------------------
From the gcc 3.0.2 release ntoes:
"The poorly documented extension that allowed string constants in C, C++ and
Objective C to contain unescaped newlines has been deprecated and may be
removed in a future version. Programs using this extension may be fixed in
several ways: the bare newline may be replaced by \n, or preceded by \n\, or
string concatenation may be used with the bare newline preceded by \n" and "
placed at the start of the next line. "I seem to recall that I came across a fair bit of this kind of thing in the
psql source code at least. I wonder if it should be fixed to be
compliant...Chris
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
From the gcc 3.0.2 release ntoes:
"The poorly documented extension that allowed string constants in C, C++ and
Objective C to contain unescaped newlines has been deprecated and may be
removed in a future version.
Not everyone uses gcc. One would think that this sort of thing would be
sufficiently unportable to have been weeded out of PG long ago, irrespective
of what gcc does or doesn't do.
While I didn't try searching through the whole source tree, a quick grep
through psql didn't find any instances of such coding...
regards, tom lane
From heap.c:
/*
* sanity checks
*/
if (relname && !allow_system_table_mods &&
IsSystemRelationName(relname) && IsNormalProcessingMode())
elog(ERROR, "invalid relation name \"%s\"; "
"the 'pg_' name prefix is reserved for system
catalogs",
relname);
I guess this is a slightly different example than what the issue is below.
Maybe I'm wrong and the above code is still legal. Even so, seems a bit
dodgy to me...
Chris
Show quoted text
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Friday, 23 November 2001 12:26 PM
To: Christopher Kings-Lynne
Cc: Hackers
Subject: Re: [HACKERS] Unescaped new lines in postgresCan you show an example?
------------------------------------------------------------------
---------From the gcc 3.0.2 release ntoes:
"The poorly documented extension that allowed string constants
in C, C++ and
Objective C to contain unescaped newlines has been deprecated and may be
removed in a future version. Programs using this extension maybe fixed in
several ways: the bare newline may be replaced by \n, or
preceded by \n\, or
string concatenation may be used with the bare newline preceded
by \n" and "
placed at the start of the next line. "
I seem to recall that I came across a fair bit of this kind of
thing in the
psql source code at least. I wonder if it should be fixed to be
compliant...Chris
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From heap.c:
/*
* sanity checks
*/
if (relname && !allow_system_table_mods &&
IsSystemRelationName(relname) && IsNormalProcessingMode())
elog(ERROR, "invalid relation name \"%s\"; "
"the 'pg_' name prefix is reserved for system
catalogs",
relname);I guess this is a slightly different example than what the issue is below.
Maybe I'm wrong and the above code is still legal. Even so, seems a bit
dodgy to me...
Yes, I have seen this before. It looked pretty nifty when I saw it, and
I have not seen it used in any other code.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
From heap.c:
/*
* sanity checks
*/
if (relname && !allow_system_table_mods &&
IsSystemRelationName(relname) && IsNormalProcessingMode())
elog(ERROR, "invalid relation name \"%s\"; "
"the 'pg_' name prefix is reserved for system
catalogs",
relname);
I guess this is a slightly different example than what the issue is below.
Maybe I'm wrong and the above code is still legal.
This is legal ANSI C. The spec says that one of the later phases of the
preprocessor is
6. Adjacent string literal tokens are concatenated.
I have an old book on C portability that says that this behavior
actually predates the ANSI spec, but wasn't universal in pre-ANSI
compilers.
It's also legal per spec to write
"invalid relation name \"%s\"; \
the 'pg_' name prefix is reserved for system catalogs",
(note the backslash before the newline) but this strikes me as worse
style since you now have a critical dependency on (a) lack of trailing
whitespace on the first line and (b) lack of leading whitespace on the
second.
What the gcc release note is about is
"invalid relation name \"%s\";
the 'pg_' name prefix is reserved for system catalogs",
Unescaped newlines in string literals are specifically forbidden by
the spec, but apparently gcc takes them anyway.
regards, tom lane