the C preprocessor is being invoked in such a way that ASCII spaces in pathnames of P4 files are unacceptable

[Abe149]

As of this writing, even with my recent driver improvements (mostly/entirely about providing good error feedback when the compiler｀s user makes a mistake), the C preprocessor is being invoked in such a way that ASCII spaces in the input pathnames of P4 files are unacceptable. This only affects top-level P4 files, i.e. it does not affect P4 files that are only accessed via #include, so I conclude that this is a driver bug.

$ ./p4c 'test file with ASCII spaces in its name.p4'
cc: error: file: No such file or directory
cc: error: with: No such file or directory
cc: error: ASCII: No such file or directory
cc: error: spaces: No such file or directory
cc: error: in: No such file or directory
cc: error: its: No such file or directory
cc: error: name.p4i: No such file or directory
cc: error: file: No such file or directory
cc: error: with: No such file or directory
cc: error: ASCII: No such file or directory
cc: error: spaces: No such file or directory
cc: error: in: No such file or directory
cc: error: its: No such file or directory
cc: error: name.p4: No such file or directory
cc: fatal error: input file ‘./test’ is the same as output file
compilation terminated.

$# ./p4c 'test dir. with ASCII spaces in its name'/normal_pathname.p4
cc: error: dir.: No such file or directory
cc: error: with: No such file or directory
cc: error: ASCII: No such file or directory
cc: error: spaces: No such file or directory
cc: error: in: No such file or directory
cc: error: its: No such file or directory
cc: error: name/normal_pathname.p4: No such file or directory

 ./p4c 'test dir. with ASCII spaces in its name/test file with ASCII spaces in its name.p4'
cc: error: file: No such file or directory
cc: error: with: No such file or directory
cc: error: ASCII: No such file or directory
cc: error: spaces: No such file or directory
cc: error: in: No such file or directory
cc: error: its: No such file or directory
cc: error: name.p4i: No such file or directory
cc: error: dir.: No such file or directory
cc: error: with: No such file or directory
cc: error: ASCII: No such file or directory
cc: error: spaces: No such file or directory
cc: error: in: No such file or directory
cc: error: its: No such file or directory
cc: error: name/test: No such file or directory
cc: error: file: No such file or directory
cc: error: with: No such file or directory
cc: error: ASCII: No such file or directory
cc: error: spaces: No such file or directory
cc: error: in: No such file or directory
cc: error: its: No such file or directory
cc: error: name.p4: No such file or directory
cc: fatal error: input file ‘./test’ is the same as output file
compilation terminated.

$ cat normal_basename.p4
#include "test file with ASCII spaces in its name.p4"```

ls -l 'test file with ASCII spaces in its name.p4'
-rw-r--r-- 1 Abe users 0 Apr 21 23:45 test file with ASCII spaces in its name.p4

[i.e. it is an empty file]

./p4c normal_basename.p4
[--Wwarn=missing] warning: Program does not contain a `main' module

[i.e. no avalanche of nonsensical error messages]

[mihaibudiu]

We just use popen.

[rst0git]

$ ./p4c 'test file with ASCII spaces in its name.p4'

p4c is a Python wrapper that provides a user interface across different P4 backends (e.g., p4c-bm2-ss, p4c-dpdk, p4c-ebpf, etc). The command-line interface is based on the argparse Python module and unfortunately this modules doesn't support spaces in the input.

However, with Mihai's fix now merged, it should be possible to work-around this problem by directly running the appropriate compiler driver. For example, the following command should work as expected:

p4c-bm2-ss 'test file with ASCII spaces in its name.p4'

[Abe149]

@rst0git, @mbudiu-vmw …

@rst0git wrote:

The command-line interface is based on the argparse Python module and unfortunately this modules doesn't support spaces in the input.

   

Actually, a quick experiment in Python3 shows that this is not an inherent {limitation of / flaw in} the standard “argparse” library… at least not with mainline/standard Python3 with this version signature:

Python 3.6.2 (v3.6.2:5fd33b5926, Jul 16 2017, 20:11:06)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

… running on Mac OS X 10.11.6 with this result from “uname -a” [hostname elided]:

Darwin 𝑒𝑙𝑖𝑑𝑒𝑑 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64

“tar.gz” attachment with both code and test data: argparse＿vs.＿spaces＿v1＿and＿v2＿and＿test＿data.tar.gz

[blank lines inserted for {clarity in spite of text re-wrapping}]

[𝐴𝑏𝑒｀𝑠 𝑝𝑟𝑜𝑚𝑝𝑡] ./argparse_vs._spaces_v2_.py --pathname1 ./test_data/folder\ with\ ASCII\ spaces\ in\ its\ name/ test_data/folder\ with\ ASCII\ spaces\ in\ its\ name/*

Type of the parse results: <class 'argparse.Namespace'>

direct output of the parse results: Namespace(all_other_pathnames=['𝐭𝐞𝐬𝐭_𝐝𝐚𝐭𝐚/𝐟𝐨𝐥𝐝𝐞𝐫 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞/𝐟𝐢𝐥𝐞 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞', '𝐭𝐞𝐬𝐭_𝐝𝐚𝐭𝐚/𝐟𝐨𝐥𝐝𝐞𝐫 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞/𝐟𝐢𝐥𝐞_𝐰𝐢𝐭𝐡𝐎𝐔𝐓_𝐚𝐧𝐲_𝐀𝐒𝐂𝐈𝐈_𝐬𝐩𝐚𝐜𝐞𝐬_𝐢𝐧_𝐢𝐭𝐬_𝐧𝐚𝐦𝐞'], pathname1='./𝐭𝐞𝐬𝐭_𝐝𝐚𝐭𝐚/𝐟𝐨𝐥𝐝𝐞𝐫 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞/')

Length of the parse results, after conversion to a dict: 2

The parse results, after conversion to a dict: {'pathname1': './𝐭𝐞𝐬𝐭_𝐝𝐚𝐭𝐚/𝐟𝐨𝐥𝐝𝐞𝐫 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞/', 'all_other_pathnames': [ '𝐭𝐞𝐬𝐭_𝐝𝐚𝐭𝐚/𝐟𝐨𝐥𝐝𝐞𝐫 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞/𝐟𝐢𝐥𝐞 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞', '𝐭𝐞𝐬𝐭_𝐝𝐚𝐭𝐚/𝐟𝐨𝐥𝐝𝐞𝐫 𝐰𝐢𝐭𝐡 𝐀𝐒𝐂𝐈𝐈 𝐬𝐩𝐚𝐜𝐞𝐬 𝐢𝐧 𝐢𝐭𝐬 𝐧𝐚𝐦𝐞/𝐟𝐢𝐥𝐞_𝐰𝐢𝐭𝐡𝐎𝐔𝐓_𝐚𝐧𝐲_𝐀𝐒𝐂𝐈𝐈_𝐬𝐩𝐚𝐜𝐞𝐬_𝐢𝐧_𝐢𝐭𝐬_𝐧𝐚𝐦𝐞']}

Length of “parsed.all_other_pathnames”: 𝟐

   

——— Python3 code: argparse_vs._spaces_v2_.py with commented-out code removed [warning: Unicode tricks applied to prevent GitHub from removing spaces (especially syntactically-important leading spaces), so don｀t copy+paste this and expect the pasted code to actually work] ———

#!/usr/bin/env python3
if __name__=="__main__":
import argparse #, sys
parser = argparse.ArgumentParser()
parser.add_argument("--pathname1")
parser.add_argument("all_other_pathnames", nargs='*')
parsed = parser.parse_args()
print ( "Type of the parse results:", type(parsed) )
print ( "direct output of the parse results:", parsed )
d1 = vars(parsed)
print ( "Length of the parse results, after conversion to a dict:", len(d1) )
print ( " The parse results, after conversion to a dict:", d1 )
print ( "Length of “parsed.all_other_pathnames”:", len(parsed.all_other_pathnames) )

[rst0git]

@Abe149 Thank you for pointing this out. I have opened a pull request with a fix: #3249

[Abe149]

@Abe149 Thank you for pointing this out. I have opened a pull request with a fix: #3249

You are welcome. I｀m glad to be of service.