On 07/04/2013 08:58 AM, Andres Freund wrote:
On 2013-07-04 08:50:34 -0400, Andrew Dunstan wrote:
On 07/04/2013 08:31 AM, Michael Meskes wrote:
On Thu, Jul 04, 2013 at 07:58:39AM -0400, Andrew Dunstan wrote:
michael@feivel:~$ grep line test\\\\a/init.c |head -1
#line 1 "test\\a/init.pgc"
...
Really? I'd expect to see 4 backslashes in the #line directive, I think.
Eh, why? The four backslashes come are two that are escaped for shell usage.
The directory name is in my example was "test\\a". What did I miss?
Isn't the argument to #line a C string literal in which one would expect
backslashes to be escaped? If not, how would it show a filename containing a
'"' character?
[andrew@emma inst.92.5701]$ bin/ecpg x\\\"a/y.pgc
[andrew@emma inst.92.5701]$ grep line x\\\"a/y.c
#line 1 "x\"a/y.pgc"
This must surely be wrong.
I think it's correct. Quoting the gcc manual
(http://gcc.gnu.org/onlinedocs/gcc-4.8.1/cpp/Include-Syntax.html#Include-Syntax)
"However, if backslashes occur within file, they are considered ordinary
text characters, not escape characters. None of the character escape
sequences appropriate to string constants in C are processed. Thus,
#include "x\n\\y" specifies a filename containing three
backslashes. (Some systems interpret ‘\’ as a pathname separator. All of
these also interpret ‘/’ the same way. It is most portable to use only
‘/’.)"
Well, that refers to #include, but for the sake of argument I'll assume
the same rule applies to #line. So this just gets processed by stripping
the surrounding quotes? Well I guess I learn something every day.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
