Re: CVS commit: src/share/man/man3
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 ?? regards, iain
Re: CVS commit: src/share/man/man3
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 platform with a larger uintmax_t could appear one day. --apb (Alan Barrett)
Re: CVS commit: src/share/man/man3
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 improvement, thanks! Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/share/man/man3
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 ENOTSUP. Presently, for instance timer_create(2) with SIGEV_THREAD appears to be successful for a libc/librt user-caller, which is not the case in reality. - Jukka.
Re: CVS commit: src/share/man/man3
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
Re: CVS commit: src/share/man/man3
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 if it is used for C or C++. In my man-page the title of gcc(1) reads: gcc - GNU project C and C++ compiler.
re: CVS commit: src/share/man/man3
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 talking about GCC the being, not the specific instance we have installed. same with tgmath.3 change. .mrg.
Re: CVS commit: src/share/man/man3
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 why I wrote the manual page in the first place. Linux is (in)famous for not following any kind of const correctness. And as we have third-party code developed on Linux, and largely for Linux, these issues creep also to NetBSD. Fixing these problems in highly complex third-party code is not a trivial nor rewarding task, especially if the upstream refuses to acknowledge the issue. So from a practical point of view, __UNCONST() has its virtues. - Jukka.
Re: CVS commit: src/share/man/man3
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 change the
entire language -- All that may really be needed is a new kind of
qualifier, one that tells the compiler a return value (or other internal
variable) has the same const status as some given input parameter
(const_if_{parameter-name}_const or some such similar nonsense).
That *is* a stronger type system, one with parametric polymorphism for
type qualifiers.
While strchr()'s interface, and that of strrchr() of course, are indeed
excellent examples this issue, the use of __UNCONST() within their
implementation to hide silly warnings that might be encountered by
compiling their implementations doesn't really fix anything except the
silly warnings. The code _must_ do what it _should_ not do. :-)
Well right...
And so I think what I said about __UNCONST() being unnecessary
remains.
...but that makes it necessary. At least given the concept of
necessary that I'm familiar with :-)
--
David A. Holland
dholl...@netbsd.org
Re: CVS commit: src/share/man/man3
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 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 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 change the
entire language -- All that may really be needed is a new kind of
qualifier, one that tells the compiler a return value (or other internal
variable) has the same const status as some given input parameter
(const_if_{parameter-name}_const or some such similar nonsense).
While strchr()'s interface, and that of strrchr() of course, are indeed
excellent examples this issue, the use of __UNCONST() within their
implementation to hide silly warnings that might be encountered by
compiling their implementations doesn't really fix anything except the
silly warnings. The code _must_ do what it _should_ not do. :-) And so
I think what I said about __UNCONST() being unnecessary remains. The
warning it hides is really still valid. IMO it's just sad that all
users of those functions won't normally (i.e. by default, with the
ability to turn it off) see a similar warning when they use these
functions so as to be made aware of the limitations of their
declarations.
I.e. the users of strchr() and strrchr() must understand that their
return values really cannot be considered to point to writable storage,
regardless of the lack of a const qualifier on their return type
declarations.
As Harbison and Steele say, The return value of these functions is a
pointer to non-const, but in fact the object designated will be const if
the first argument points to a const object. In that case, storing a
value into the object designated by the return pointer will result in
undefined behaviour. The const qualifier on the function's first
parameter is after all just a promise by strchr() that _it_ will not
modify what that pointer points at, and nothing more. Unfortunately
because of the choices made in the standard, the compiler cannot help
the user make similar promises about the use of the return value when
and if necessary.
A similar warning should probably appear in strchr(3) and strrchr(3) and
the manual pages of any other functions with similar limitations.
Similar kinds of discussion might also be appropriate in __UNCONST(3)
such that users defining functions with similar issues as strchr(3) et
al can also make appropriate choices.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http://www.planix.com/
pgpmZVDnfMUFT.pgp
Description: PGP signature
Re: CVS commit: src/share/man/man3
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 Added Files: src/share/man/man3: __UNCONST.3 Log Message: Document __UNCONST and __UNVOLATILE. XXX: If there is anything to add or correct, please do so! could you use some stronger wording about avoiding using these unless absolutely necessary, and please note that they can also be used for variable assignment, not just for function calls. Perhaps it would also be good to suggest correct ways to avoid const mismatches in the first place, such as in variable assignments by copying strings into non-const (eg. allocated) storage instead of trying to assign pointers to them to a char *. 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. -- Greg A. Woods Planix, Inc. wo...@planix.com +1 416 218 0099http://www.planix.com/ pgpP7uiHUBnzO.pgp Description: PGP signature
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 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 without __UNCONST. I'm talking about writev -- if you have to copy all constants first, because struct iovec has a void * as iov_base, it stops making sense to use writev in first place. There is the general issue of const char ** vs char * const * in POSIX to be considered as well. Joerg
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 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 type system. See for example strchr(3). -- David A. Holland dholl...@netbsd.org
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 Added Files: src/share/man/man3: __UNCONST.3 Log Message: Document __UNCONST and __UNVOLATILE. XXX: If there is anything to add or correct, please do so! could you use some stronger wording about avoiding using these unless absolutely necessary, and please note that they can also be used for variable assignment, not just for function calls. thanks. .mrg.
