Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-10-10 18:20:56

--- In boost_at_y..., "George A. Heintzelman" <georgeh_at_a...> wrote:
> Hi Boosters, and Boost threaders. I'm trying to make use of
> Boost.Threads in a Solaris environment, compiling with g++-2.95.2
> --pedantic. We have pthreads, but there are a few problems:

The good news is that most of these are already known and I'm in the
process of addressing them.

> 1) (Less serious) the statement
> pthread_once_t once = PTHREAD_ONCE_INIT ;
> (occurs twice) triggers a warning:
> /work/nova/2465/once.cpp:27: warning: aggregate has a partly
> initializer
> I think this is a defect in the locally installed pthreads headers,
> this statement is identical to one in the documentation. (I *think*
> is technically correct to diagnose this -- the pthread_once_t is
> { <someintegertype> __xxx[4] } on this system. Is this a difference
> between C and C++ here?). In any case, using { PTHREAD_ONCE_INIT }
> instead fixes this problem. I don't think Boost ought to do
> about this error, but Solaris people might be interested in it.

This code is straight from the POSIX standard and so should work.
However, if it's a known issue on a platform I'm not adverse to
including work arounds for that platform. I just need more info on
why this is occuring, what possible side effects the "fix" might
cause to other platforms, and if we can use the Boost.Config system
to fix only the broken platform. If you can answer these and give me
a patch I'll move it into the base code.
> 2) (More troublesome) in once.cpp,
> once_callback cb = reinterpret_cast<once_callback>
> ey));
> fires an error, complaining that:
> /work/nova/2465/once.cpp: In function `void {anonymous}::do_once()':
> /work/nova/2465/once.cpp:41: ANSI C++ forbids casting between
> to functions and objects
> This is, I think, strictly correct. It is arguably a flaw in the
> standard that a pointer to an extern "C" function cannot be
> back and forth with a void *, since C allows that behavior, but I
> find nothing in the standard that excepted extern "C" functions
> the conversion rules.
> I'm not sure I understand the subtleties of this code, so I was
> reluctant to simply add the proverbial extra layer of indirection.
> think it will require dynamic allocation, which may just screw up
> whole point (?). Comments, thoughts?

I'm currently looking into this one. I'm not sure how simple the fix
will be so if anyone has a patch I'd be happy. In any event this one
will be fixed before the next release.
> 3) (Smallish issue) In timeconv.inl, I get complaints about
comparing a
> signed to an unsigned, comparing the members of xtime with the
> locally-defined consts. Recognizing that a 32-bit signed int can
> +10^9 (nanoseconds per second), or even 2*10^9 (adding two 10^9 - 1
> nano-second numbers), I just changed the consts to be straight
> Other fixes are possible, of course.

I'm aware of this one and had thought I'd fixed most of the signed
problems, but I'll check again.
> 4) (Not serious at all, but would be nice to have fixed): There are
> unused-variable warnings in mutex.cpp, where state is not used in
> three do_lock functions.

This is the one for which I started the thread about
boost::unused_variable<>. I will eliminate these warnings before the
next release but I'm waiting to figure out which solution to use.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at