[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: definition of _GLIBCXX_HAVE_SWPRINTF
Perry E. Metzger writes:
> Well, I'll point out that NetBSD doesn't use glibc, so it would be an
> odd thing to define. That said, something might be done so that the
> include file knows that swprintf is available.
So perhaps I asked the question a bit wrongly. Here is a snippet of
code from /usr/include/g++/cwchar on my NetBSD 4.0 box. It is greatly
abridged for clarity. Note that c++config.h defines both
_GLIBCXX_HAVE_WCHAR_H and_GLIBCXX_USE_WCHAR_T to 1 but does not define
_GLIBCXX_HAVE_SWPRINTF. It is also the case that there are a number
of other symbols protected by similar _GLIBCXX_HAVE_* macros that may
have similar problems.
# undef swprintf
The net effect of this is that client code cannot make use of the
identifier std::swprintf(), because it has not been imported into
namespace std, even though wchar.h defines ::swprintf() and it would
work perfectly if in fact _GLIBCXX_HAVE_SWPRINTF were defined to 1,
for example in c++config.h.
In a later post, it was suggested that this might reflect a
configuration issue with gcc. It is also the case that there is no
mention of _GLIBCXX_HAVE_SWPRINTF in c++config.h, even as an undefined
macro. Thus, it would seem that gcc configuration may not even be
trying to test for this.
So, the question is, what is to be done? Is this in fact a correct
analysis indicating a deficiency? If so, how should it be fixed?
Perhaps the most expedient method is for me to define
_GLIBCXX_HAVE_SWPRINTF in my client code. This seems like an
undesirable hack, though, and a solution should be found in the
toolchain itself. Please help identify the correct solution here.
Thanks alot for your comments and suggestions.
Main Index |
Thread Index |