Incorrect handling of escaped hash character #215

New Issue

ariadne · 2021-03-14T10:38:06Z

avikivity commented

2021-03-14 10:38:06 +00:00

(Migrated from github.com)

If an escaped hash character appears in in a value, it is not treated as a comment introduction, but it is also removed from the output.

Example:

Name: x
Description: x
Version: 1.0

Cflags: kuku=\#ttt

$ pkg-config --cflags  ./x.pc
kuku=ttt

This breaks Clang's -Wno-error=#warnings flag (it was a bad idea to use a comment character in a command line argument, ut still).

Seen with 1.7.3.

If an escaped hash character appears in in a value, it is not treated as a comment introduction, but it is also removed from the output. Example: ``` Name: x Description: x Version: 1.0 Cflags: kuku=\#ttt ``` ```console $ pkg-config --cflags ./x.pc kuku=ttt ``` This breaks Clang's `-Wno-error=#warnings` flag (it was a bad idea to use a comment character in a command line argument, ut still). Seen with 1.7.3.

ariadne commented

2021-03-15 06:27:14 +00:00

If it is removed from the output, then the lexer is treating it as a comment introduction.

If it is removed from the output, then the lexer *is* treating it as a comment introduction.

ariadne commented

2021-03-15 06:29:43 +00:00

anyway, is there any other implementation where that testcase passes as expected? i am skeptical

avikivity commented

2021-03-15 09:25:07 +00:00

(Migrated from github.com)

If it is removed from the output, then the lexer is treating it as a comment introduction.

Well, the remainder of the line survives. If it was a comment introduction, it's expect it to be truncated after kuku=.

> If it is removed from the output, then the lexer _is_ treating it as a comment introduction. Well, the remainder of the line survives. If it was a comment introduction, it's expect it to be truncated after `kuku=`.

avikivity commented

2021-03-15 09:44:40 +00:00

(Migrated from github.com)

anyway, is there any other implementation where that testcase passes as expected? i am skeptical

I wasn't able to even build pkg-config, so I can't test it. But excising random # characters can't be right.

> anyway, is there any other implementation where that testcase passes as expected? i am skeptical I wasn't able to even build pkg-config, so I can't test it. But excising random `#` characters can't be right.

ariadne commented

2021-03-15 10:52:58 +00:00

what a weird bug. i'm honestly not sure what to do about this one.

avikivity commented

2021-03-17 18:44:34 +00:00

(Migrated from github.com)

I tested pkg-config 0.29.1 from Ubuntu 20.04. It emits the # and even quotes it:

# cat > x.pc
Name: x
Description: x
Version: 1.0

Cflags: kuku=\#ttt
# pkg-config --cflags  ./x.pc
kuku=\#ttt

I tested pkg-config 0.29.1 from Ubuntu 20.04. It emits the # and even quotes it: ```console # cat > x.pc Name: x Description: x Version: 1.0 Cflags: kuku=\#ttt # pkg-config --cflags ./x.pc kuku=\#ttt ```

avikivity commented

2021-03-18 11:58:11 +00:00

(Migrated from github.com)

Thanks! And I'd be grateful if a patch release can be issued, so I can try to lobby my distro to update.

Sign in to join this conversation.