On Mon, Aug 29, 2016 at 03:50:05AM +, David A. Holland wrote:
> Module Name: src
> Committed By: dholland
> Date: Mon Aug 29 03:50:05 UTC 2016
>
> Modified Files:
> src/share/man/man3: rbtree.3
>
> Log Message:
> Clarify the usage, so hopefully nobody else makes the set of wron
(2012/10/17 4:13), Alan Barrett wrote:
> 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 ui
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 pl
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 uintm
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
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 ENOTS
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 a
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
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 Sat, Mar 20, 2010 at 10:26:06AM +, Jukka Ruohonen wrote:
> Module Name: src
> Committed By: jruoho
> Date: Sat Mar 20 10:26:06 UTC 2010
>
> Modified Files:
> src/share/man/man3: fast_divide32.3
>
> Log Message:
> Add the (ACM) journal where this appeared. Fix URL.
Without p
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
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
reaso
At Thu, 4 Mar 2010 02:22:35 +, David Holland
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 sometimes save
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
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
At Tue, 02 Mar 2010 07:57:42 +1100, matthew green 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/m
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 the
On Sun, Jan 24, 2010 at 01:48:28PM +0200, Jukka Ruohonen wrote:
> On Sun, Jan 24, 2010 at 11:14:04AM +, Jukka Ruohonen wrote:
> > Log Message:
> > Add timeradd(3) from FreeBSD. Needs proofreading.
>
> The $Id$ field is not present in this file. How it should be added?
First line of the man pa
On Sun, Jan 24, 2010 at 11:14:04AM +, Jukka Ruohonen wrote:
> Log Message:
> Add timeradd(3) from FreeBSD. Needs proofreading.
The $Id$ field is not present in this file. How it should be added?
Actually, it is a little unclear to me should one always include a template
$Id$ for new files, an
19 matches
Mail list logo
