Re: [boost] [regex] patch for config/platform/hpux.hpp

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-08-24 17:28:59

John Maddock wrote:

> It makes sense to show off your latest technology though :-)

To show off technology :-), we'll install latest compiler on the
testdrive machine in the next few days. The kit is in the works
now.

> Yep, I've committed some fairly conservative changes to the release
> branch (isolated to the aCC config, and to regex).

Thanks a lot! I'll start 1.34 tests later today. Yesterday testing
ended with memory access violation in "Getting test case results out
of..." phase. This is the first time it happens since I started regular
testing in June and it looks scary. Anyway, the current tests results
on the web are the old ones.

>
> With those changes there is only one regex failure: the
> concept_check one.
> That appears to be because std::basic_string constructor doesn't
> accept
> iterator types it doesn't know about?  I'll let you investigate
> that one :-)

Will do.

> There is also a problem I noticed with WCHAR_MAX and WCHAR_MIN,
> there are a
> couple of tests that use these in preproccessing directives, but
> these
> evaluate to a typecast on both HP-UX and Tru64, and so can't be used
> in
> pp-directives in C++, even though they can in C.  If you have any
> clout with
> whoever is responsible for these, there is a trick that uses:
>
> #define WCHAR_MIN ((wchar_t)(+0))
>
> which evaluates to 0+0 in a pp-directive, but a typecast in C++ code.
>

We can certainly change the header, but on HP-UX, we may have a
solution which would not require it. There is the following code in
/usr/include/wchar.h:

/*            C99 stds require WCHAR_MAX and WCHAR_MIN to be macros which
              can be used in #if constructs, hence, can't have casts
              Retaining the old macros for compatibility
 */
#             if defined(_INCLUDE_STDC__SOURCE_199901)
#               define WCHAR_MAX  UINT_MAX  /* max value of an unsigned 
integer */
#               define WCHAR_MIN  0
#             else
#               define WCHAR_MAX  (wchar_t)UINT_MAX  /* max value of an 
unsigned integer */
#               define WCHAR_MIN  (wchar_t)0
#             endif

So, when compiling with _INCLUDE_STDC__SOURCE_199901 macro defined,
you get macro definitions you want:

bash-3.00$ cat > x.cpp
#include <wchar.h>
WCHAR_MIN
WCHAR_MAX
bash-3.00$ aCC -E x.cpp | grep "(wchar_t)"
               extern int           wcwidth (wchar_t);
         extern wint_t putwchar (wchar_t);
(wchar_t)0
(wchar_t)4294967295U
bash-3.00$ aCC -E x.cpp -D_INCLUDE_STDC__SOURCE_199901 | grep "(wchar_t)"
               extern int           wcwidth (wchar_t);
         extern wint_t putwchar (wchar_t);
bash-3.00$

I'm not sure what the impact of defining _INCLUDE_STDC__SOURCE_199901
macro in a C++ compilation is: I'll need to talk to other members of
the team. If it is safe, we can define this macro in the boost
configuration file for aCC. Or we can define it in those boost tests
that assume "good" definitions.

On Tru64, the compiler group owns cname headers, so, we can change
<cwchar> and the change will be available in the next compiler release
(no estimated date for the release yet). Changing <wchar.h> is
possible, but the change will be available only in the next release
of Tru64.

Thanks a lot for your help. FYI: I'll be off tomorrow through next
Tuesday with no access to email until Tuesday night.

Thanks again,
  Boris

----- Original Message ----- 
From: "John Maddock" <john_at_[hidden]>
To: <boost_at_[hidden]>
Cc: "Boris Gubenko" <Boris.Gubenko_at_[hidden]>
Sent: Thursday, August 24, 2006 7:11 AM
Subject: Re: [boost] [regex] patch for config/platform/hpux.hpp

> Boris Gubenko wrote:
>> John Maddock wrote:
>>>
>>> hp_acc.hpp looks hopelessly out of date: I suspect we could get a
>>> lot more
>>> tests passing with an update.  I was going to do just that, but the
>>> hp.testdrive servers appear to be down this morning :-(
>>>
>>
>> The machine is up and running now and, I suspect, you know that :-)
>> If you can update hp_acc.hpp to reflect aCC6 compiler, it would be
>> great. An unexpected help from an expert... This compiler is based on
>> EDG 3.06.
>>
>> On the testdrive machine, the compiler is A.06.07. This version of
>> aCC6 does not predefine __EDG__ and __EDG_VERSION__ macros which can
>> confuse some boost configuration headers. More recent versions of aCC6
>> do predefine these macros.
>>
>> For boost testing, I'm using A.06.12. It predefines __EDG* macros and
>> sets __HP_aCC to 61200. A.06.10 also predefines __EDG* macros and sets
>> __HP_aCC to 61000. Perhaps, we can use (__HP_aCC >= 61000) as a
>> condition for "modern" aCC6 compiler (available on ia64 only).
>>
>> I think, it would be a good idea to upgrade the compiler on the
>> testdrive machine to latest and greatest. Would you agree?
>
> Fine by me, but you would probably know best what your customers want from
> those testdrive machines.  It makes sense to show off your latest 
> technology
> though :-)
>
>>> There are some aCC specific workarounds in the regex lib that could
>>> probably
>>> be removed for recent aCC compiler releases as well.
>>>
>>
>> Currently, with hpux.hpp setting the THREADS macros, there are two
>> regex library tests failing on HP-UX: concept_check and
>> regex_token_iterator_eg_2. Both fail to compile.
>
> Yep, I've committed some fairly conservative changes to the release branch
> (isolated to the aCC config, and to regex).  I've placed some rather more
> agressive changes in cvs HEAD: so that only those config macros that 
> really
> do need to be defined are done so.  To make this work I also had to update
> some workarounds in type-traits - there may be others I've missed, which 
> is
> why this isn't going on the release branch - too great a chance of messing
> things up :-(
>
> With those changes there is only one regex failure: the concept_check one.
> That appears to be because std::basic_string constructor doesn't accept
> iterator types it doesn't know about?  I'll let you investigate that one 
> :-)
>
> There is also a problem I noticed with WCHAR_MAX and WCHAR_MIN, there are 
> a
> couple of tests that use these in preproccessing directives, but these
> evaluate to a typecast on both HP-UX and Tru64, and so can't be used in
> pp-directives in C++, even though they can in C.  If you have any clout 
> with
> whoever is responsible for these, there is a trick that uses:
>
> #define WCHAR_MIN ((wchar_t)(+0))
>
> which evaluates to 0+0 in a pp-directive, but a typecast in C++ code.
>
> All the best, John.
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>