Re: [9.3 bug fix] ECPG does not escape backslashes

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(at)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(at)emma inst.92.5701]$ bin/ecpg x\\\"a/y.pgc
>> [andrew(at)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