|
Boost Users : |
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2007-07-04 10:25:37
Hello Hartmut!
I have a file delived from some processor manufacturer which I can not change. In the file I have
following defines, which wave can't parse:
#define UINT_MAX 4294967295U
#define ULONG_MAX 1099511627775U
First error which happens during parsing of UINT_MAX is:
description: error: ill formed integer literal or integer constant too large: 4294967295U
I do not understand why I get the first error, since the value 4294967295U is 0xFFFFFFFF which is
32 bits long and should be fine (since it is also marked as unsigned for the preprocessor)...
Clearly the ULONG_MAX has a wrong numeric format (should be 1099511627775UL or 1099511627775ul),
but unfortunately this file comes from some vendor and is deeply incorporated into the build
process, so that it can not easily be changed. What do you think, could be the possible solution
in this case?
My other question would be:
Is there any change to allow the hooking interface to specify, which preprocessor directives
should be expanded, an which not. Let me summarize:
I need some few macros to be expanded, which are defined in some 2-3 headers and I do not want
wave to preprocess everything (huge source dir). Ideally, it would be great to have some
functionality, which can notify the preprocessor whether to skip the preprocessing directive or
not, e.g. function
void found_include_directive(std::string const &filename, bool include_next);
(as well as other functions like expanding_function_like_macro) from the
default_preprocessing_hooks interface could additionaly return bool value, which would notify the
preprocessor whether to include and expand the file/macro or not. May be in this second case I
could solve the first problem as well, since I don't really need these defines, they are parsed as
part of dependency, which is not required in my case.
With Kind Regards,
Ovanes Markarian
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net