On Tue, 16 Oct 2012, SAITOH Masanobu wrote:
Module Name: src
Committed By: msaitoh
Date: Tue Oct 16 17:39:35 UTC 2012
Modified Files:
src/share/man/man3: bits.3
Log Message:
Return value of __BIT() and __BITS() is not uint32_t but uint64_t.
but surely, it is uintmax_t ??
On Tue, 16 Oct 2012, SAITOH Masanobu wrote:
Modified Files:
src/share/man/man3: bits.3
Log Message:
Return value of __BIT() and __BITS() is not uint32_t but uint64_t.
No, they are uintmax_t.
uintmax_t happens to be the same as uint64_t on all present day NetBSD
platforms, but a new
On Fri, Aug 27, 2010 at 09:13:38AM +, Jukka Ruohonen wrote:
Module Name: src
Committed By: jruoho
Date: Fri Aug 27 09:13:38 UTC 2010
Modified Files:
src/share/man/man3: bits.3
Log Message:
Replace the example with something more generic and perceptual.
That's a big
On Wed, May 19, 2010 at 08:02:47AM +, Jukka Ruohonen wrote:
Continue the discussion w.r.t. SIGEV_THREAD by nothing that pthread_join(3)
should be out of the question and that thread stack cannot be recovered.
What is the status of SIGEV_THREAD?
It should at least fail with EINVAL or
On Wed, Apr 14, 2010 at 08:26:42AM +, Jukka Ruohonen wrote:
Log Message:
EXAMPLE - EXAMPLES, GCC - gcc(1), and minor markup changes.
I disagree with the second part. This is not about the frontend. It
doesn't matter if it is used for C or C++.
Joerg
On Wed, Apr 14, 2010 at 03:08:43PM +0200, Joerg Sonnenberger wrote:
On Wed, Apr 14, 2010 at 08:26:42AM +, Jukka Ruohonen wrote:
Log Message:
EXAMPLE - EXAMPLES, GCC - gcc(1), and minor markup changes.
I disagree with the second part. This is not about the frontend. It
doesn't matter
On Wed, Apr 14, 2010 at 08:26:42AM +, Jukka Ruohonen wrote:
Log Message:
EXAMPLE - EXAMPLES, GCC - gcc(1), and minor markup changes.
I disagree with the second part. This is not about the frontend. It
doesn't matter if it is used for C or C++.
i agree. the comments are
On Thu, Mar 04, 2010 at 05:26:02PM -0500, Greg A. Woods wrote:
silly warnings. The code _must_ do what it _should_ not do. :-) And so
I think what I said about __UNCONST() being unnecessary remains. The
I agree.
As for the legitimate reasons of usage, third-party code was largely the
reason
On Thu, Mar 04, 2010 at 05:26:02PM -0500, Greg A. Woods wrote:
No such luck, at least not until C grows a stronger type system. See
for example strchr(3).
I don't think a stronger type system would really change this issue
fundamentally unless it was one which was so radical as to
At Thu, 4 Mar 2010 02:22:35 +, David Holland
dholland-sourcechan...@netbsd.org wrote:
Subject: Re: CVS commit: src/share/man/man3
On Wed, Mar 03, 2010 at 12:58:33PM -0500, Greg A. Woods wrote:
I believe that __UNCONST() in particular is _never_ absolutely necessary
-- it may
At Tue, 02 Mar 2010 07:57:42 +1100, matthew green m...@eterna.com.au wrote:
Subject: re: CVS commit: src/share/man/man3
Module Name: src
Committed By: jruoho
Date: Mon Mar 1 13:44:10 UTC 2010
Modified Files:
src/share/man/man3: Makefile
On Wed, Mar 03, 2010 at 12:58:33PM -0500, Greg A. Woods wrote:
I believe that __UNCONST() in particular is _never_ absolutely necessary
-- it may sometimes save a very few cycles and a few bytes of storage,
but that's the best it can do.
At least one important interface would use its purpose
On Wed, Mar 03, 2010 at 12:58:33PM -0500, Greg A. Woods wrote:
I believe that __UNCONST() in particular is _never_ absolutely necessary
-- it may sometimes save a very few cycles and a few bytes of storage,
but that's the best it can do.
No such luck, at least not until C grows a stronger
Module Name: src
Committed By:jruoho
Date:Mon Mar 1 13:44:10 UTC 2010
Modified Files:
src/share/man/man3: Makefile
Added Files:
src/share/man/man3: __UNCONST.3
Log Message:
Document __UNCONST and __UNVOLATILE.
XXX: If
14 matches
Mail list logo
