wave gcc "bits/c++config.h" invalid name
Getting: cd ~/prog_dev/boost-release/boost_1_32_0/lje/libs/fields_visitor/test/ wave -S/usr/include/c++/3.3 test_link.cpp #line 42 "/usr/include/c++/3.3/iostream" #pragma GCC system_header /usr/include/c++/3.3/iostream(42): exception caught: boost::filesystem::path: invalid name "c++config.h" in path: "bits/c++config.h" Should the criteria for valid name be changed?
Larry Evans wrote:
cd ~/prog_dev/boost-release/boost_1_32_0/lje/libs/fields_visitor/test/ wave -S/usr/include/c++/3.3 test_link.cpp #line 42 "/usr/include/c++/3.3/iostream" #pragma GCC system_header /usr/include/c++/3.3/iostream(42): exception caught: boost::filesystem::path: invalid name "c++config.h" in path: "bits/c++config.h"
Should the criteria for valid name be changed?
The same was reported already for a Windows system, where the '+' makes the boost::filesystem to throw as well (Wave uses the boost::filesystem::native path validator, i.e. system dependant validation is performed). I've already tried to get in contact with Beman, but got no response so far. Regards Hartmut
On 02/16/2005 01:20 PM, Hartmut Kaiser wrote: [snip]
The same was reported already for a Windows system, where the '+' makes the OK. I should have searched the previous reports. [snip] I've already tried to get in contact with Beman, but got no response so far. I went ahead and made the change; however, now wave runs a long time and then... well here's the Makefile output:
cd /home/evansl/prog_dev/boost-release/boost_1_32_0/lje/libs/fields_visitor/test/ make wave wave --traceto wave.trace.out --output test_wave.out -S /usr/include/c++/3.3 -S /usr/include/c++/3.3/i486-linux -S /usr/include test_wave.cpp make: *** [wave] Killed Compilation exited abnormally with code 2 at Wed Feb 16 15:00:28 The wave.trace.out is empty and test_wave.out contains: #line 42 "/usr/include/c++/3.3/iostream" #pragma GCC system_header Any ideas?
Larry Evans wrote:
cd /home/evansl/prog_dev/boost-release/boost_1_32_0/lje/libs/fiel ds_visitor/test/ make wave wave --traceto wave.trace.out --output test_wave.out -S /usr/include/c++/3.3 -S /usr/include/c++/3.3/i486-linux -S /usr/include test_wave.cpp make: *** [wave] Killed
Compilation exited abnormally with code 2 at Wed Feb 16 15:00:28
The wave.trace.out is empty and test_wave.out contains:
#line 42 "/usr/include/c++/3.3/iostream" #pragma GCC system_header
Any ideas?
Does the compilaton fail or does wave execution hang? Could you provide the files you're try to preprocess? Please make sure to use a release build of wave, otherwise it's too slow. For gcc it might be result in faster runs not to use the flex_string class but the std::string class from the C++Std library (which is based on a copy on write implementation). Regards Hartmut
On 02/16/2005 10:57 PM, Hartmut Kaiser wrote:
Does the compilaton fail or does wave execution hang? Could you provide the
Wave hangs, I guess. I didn't issue the Kill instruction or what it was that caused the compilation to stop.
files you're try to preprocess? Please make sure to use a release build of
Well, since the same problem occurs with a simpler input, and the input file was shown in post with subject, "wave works on simple_fun fails in pp_enum_params", I guess that's enough.
wave, otherwise it's too slow. For gcc it might be result in faster runs not
OK. I was using the whatever was requested by the Jamfile.v2 in tools/wave/build.
to use the flex_string class but the std::string class from the C++Std library (which is based on a copy on write implementation).
I guess I need to read the docs about how to use std::string instead of flex_string in wave? :( BTW, I'll be out-of-town till Monday; so, I won't be able to provide much feedback till then.
At 03:20 PM 2/16/2005, Hartmut Kaiser wrote:
Larry Evans wrote:
cd ~/prog_dev/boost-release/boost_1_32_0/lje/libs/fields_visitor/test/ wave -S/usr/include/c++/3.3 test_link.cpp #line 42 "/usr/include/c++/3.3/iostream" #pragma GCC system_header /usr/include/c++/3.3/iostream(42): exception caught: boost::filesystem::path: invalid name "c++config.h" in path: "bits/c++config.h"
Should the criteria for valid name be changed?
The same was reported already for a Windows system, where the '+' makes
the
boost::filesystem to throw as well (Wave uses the boost::filesystem::native path validator, i.e. system dependant validation is performed).
Hum... Are you sure that '+' is causing an exception for boost::filesystem::native on Windows? I inspected the code, and '+' is not one of the invalid characters for Windows. I also just added a regression test case, and it is not failing. My guess is that there is a path through the program where native is not being set.
I've already tried to get in contact with Beman, but got no response so far.
I haven't gotten any email from you recently. Please try again, and I'll check to make sure my ISP isn't blocking your email address. --Beman
Beman Dawes wrote:
The same was reported already for a Windows system, where the '+' makes the >boost::filesystem to throw as well (Wave uses the boost::filesystem::native >path validator, i.e. system dependant validation is performed).
Hum... Are you sure that '+' is causing an exception for boost::filesystem::native on Windows? I inspected the code, and '+' is not one of the invalid characters for Windows. I also just added a regression test case, and it is not failing.
My guess is that there is a path through the program where native is not being set.
You are right! I haven't realised, that the path::operator/=() implicitly calls the path() constructor when used with a string on the right sight: fs::path p; std::string s; ... p /= s; // uses the default name checker here This problem is fixed now (at least for the Windows environment). Thanks!
I've already tried to get in contact with Beman, but got no response so >far.
I haven't gotten any email from you recently. Please try again, and I'll check to make sure my ISP isn't blocking your email address.
Never mind... I've simply CC'ed my reply to the [boost] list to you, perhaps you haven't seen it for this reason. Regards Hartmut
On Sat, Feb 19, 2005 at 12:41:57PM +0100, Hartmut Kaiser <HartmutKaiser@t-online.de> wrote:
You are right! I haven't realised, that the path::operator/=() implicitly calls the path() constructor when used with a string on the right sight:
fs::path p; std::string s; ...
p /= s; // uses the default name checker here
This problem is fixed now (at least for the Windows environment). Thanks! Thats the most common problem with boost::fs, whats the rationale behind op/= not using the path checker of the existing path object?
Regards Andreas
At 03:22 AM 2/20/2005, Andreas Pokorny wrote:
On Sat, Feb 19, 2005 at 12:41:57PM +0100, Hartmut Kaiser <HartmutKaiser@t-online.de> wrote:
You are right! I haven't realised, that the path::operator/=() implicitly calls the path() constructor when used with a string on the right sight:
fs::path p; std::string s; ...
p /= s; // uses the default name checker here
This problem is fixed now (at least for the Windows environment). Thanks! Thats the most common problem with boost::fs, whats the rationale behind op/= not using the path checker of the existing path object?
It isn't retained. The problem will go away with the next major revision, which is coming along nicely. I've successfully created test directories and files on my Windows XP box that Windows Explorer shows as nice Unicode symbols like a circle with numbers inside (Unicode 0x2780, etc.) --Beman
On 02/16/2005 01:07 PM, Larry Evans wrote:
Getting: [snip]
boost::filesystem::path: invalid name "c++config.h" in path:
The offending character is probably '+' since, in libs/filesystem/src /path_posix_windows.cpp there's this code: const std::string valid_posix( "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789._-" ); Anybody have suggested workarounds other than adding + to the above and remaking (or rebjaming) filesystem?
At 03:41 PM 2/16/2005, Larry Evans wrote:
On 02/16/2005 01:07 PM, Larry Evans wrote:
Getting: [snip]
boost::filesystem::path: invalid name "c++config.h" in path:
The offending character is probably '+' since, in libs/filesystem/src /path_posix_windows.cpp there's this code:
const std::string valid_posix( "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789._-" );
Anybody have suggested workarounds other than adding + to the above and remaking (or rebjaming) filesystem?
That wouldn't be the correct fix. '+' is clearly not in the POSIX Portable Filename Character Set. See http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_0... The correct fix is to change to a different name checker, possibly native or no_check. By the way, this kind of SNAFU is one of the reasons I've decided to remove the checking functionality from class path. They will still be available as free functions. --Beman
participants (4)
-
Andreas Pokorny -
Beman Dawes -
Hartmut Kaiser -
Larry Evans