Re: svn commit: r286715 - head/lib/libc/string
On 13 Aug 2015, at 08:56, Marcelo Araujo araujobsdp...@gmail.com wrote: So it means, this commit here was right already: https://svnweb.freebsd.org/base?view=revisionrevision=286651 Although I made a mistake with the date. More or less. I partly agree with Bruce that suggesting memcpy is misleading. I’d prefer something like: This function is deprecated (marked as LEGACY in POSIX.1-2001): use .Xr memmove 3 in new programs. If you can guarantee that the input and output buffers do not overlap, then .Xr memcpy 3 may be more efficient. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r286715 - head/lib/libc/string
On 13 Aug 2015, at 08:11, Marcelo Araujo araujobsdp...@gmail.com wrote: The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std 1003.1-2001. In my understood it is obsolete on POSIX, but not truly obsolete for FreeBSD. So I believe, this patch now address it in the correct way. Its use should be strongly discouraged in FreeBSD (or, ideally, replaced with the macro from the POSIX man page). LLVM does a load of optimisations for memmove and memcpy - using bcopy is a really good way of bypassing all of these. David ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r286715 - head/lib/libc/string
Hi David, So it means, this commit here was right already: https://svnweb.freebsd.org/base?view=revisionrevision=286651 Although I made a mistake with the date. All the best. 2015-08-13 15:24 GMT+08:00 David Chisnall thera...@freebsd.org: On 13 Aug 2015, at 08:11, Marcelo Araujo araujobsdp...@gmail.com wrote: The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std 1003.1-2001. In my understood it is obsolete on POSIX, but not truly obsolete for FreeBSD. So I believe, this patch now address it in the correct way. Its use should be strongly discouraged in FreeBSD (or, ideally, replaced with the macro from the POSIX man page). LLVM does a load of optimisations for memmove and memcpy - using bcopy is a really good way of bypassing all of these. David -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org http://www.freebsd.org/ \/ \ ^ Power To Server. .\. /_) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r286715 - head/lib/libc/string
2015-08-13 14:51 GMT+08:00 Marcelo Araujo araujobsdp...@gmail.com: Hi Bruce, I sent it already in private to you, as we were talking about the implementation of bcopy(3) on BSD and the POSIX one. So, I will send the patch again here, to let other developer give their opinion about it. Thanks to explain over and over again. Now it is clear to me. All the best. 2015-08-13 12:46 GMT+08:00 Bruce Evans b...@optusnet.com.au: On Thu, 13 Aug 2015, Marcelo Araujo wrote: Author: araujo Date: Thu Aug 13 02:31:23 2015 New Revision: 286715 URL: https://svnweb.freebsd.org/changeset/base/286715 Log: Remove the mention of memcpy(3) that is build on top of bcopy(3). Fix some phrases to make it more clear. Differential Revision: D3378 Reported by: bde@ Reviewed by: wblock Approved by: bapt, rodrigc (mentor) Sponsored by: gandi.net I don't like this version either :-). Modified: head/lib/libc/string/bcopy.3 == --- head/lib/libc/string/bcopy.3Thu Aug 13 01:04:26 2015 (r286714) +++ head/lib/libc/string/bcopy.3Thu Aug 13 02:31:23 2015 (r286715) @@ -31,7 +31,7 @@ .\ @(#)bcopy.3 8.1 (Berkeley) 6/4/93 .\ $FreeBSD$ .\ -.Dd August 11, 2015 +.Dd August 13, 2015 .Dt BCOPY 3 .Os .Sh NAME @@ -58,16 +58,14 @@ If .Fa len is zero, no bytes are copied. .Pp -This function is deprecated (marked as LEGACY in -POSIX.1-2001): use -.Xr memcpy 3 -or +This function is obsolete (marked as LEGACY in +POSIX.1-2001): please use This function is not obsolete, but is fully supported in FreeBSD. Its obsoletely doesn't follow at all from the clause in parentheses. LEGACY doesn't even mean obsolencent. In computerspeak it means old stuff that we don't like. I think you got the obsolete wording from NetBSD. But I think NetBSD started deprecating it in 1995. It might really be obsolete for them after 20 years of deprecation. Please don't use pleasant nonsenses like please in man pages or comments. .Xr memmove 3 in new programs. Still not quite right. New programs should use the best function and that is usually memcpy(). Only old programs that are being roto-tilled should convert bcopy() to memmove() (so as to avoid having to understand them well enough to know if they do overlapped copies). -Note that the first two arguments are -interchanged for -.Xr memcpy 3 -and +Note that +.Fn bcopy +takes its src and dst arguments in the opposite +order from .Xr memmove 3 . OK, except Xr should be Fn. .Xr memmove 3 is a man page, not a function. Man pages don't take src and dst arguments :-). This normally shows up in the rendering -- in text mode, Fn gives highlighting but Xr doesn't. Now I notice more markup problems: the src and dst arguments are not marked up. In text mode, Fa gives highlighting for args. POSIX.1-2008 removes the specification of .Fn bcopy . Better put this before the LEGACY statement and maybe merge the LEGACY statement into the HISTORY section. Since I don't want to deprecate bcopy(), I would put this in the history section too. Technically, this function is not deprecated since it is still a standard BSD function in strings.h. The ifdef for this is already quite complicated and broken, thoough it only attempts to keep up with some of the POSIX churn: from strings.h: #if __BSD_VISIBLE || __POSIX_VISIBLE = 200112 int bcmp(const void *, const void *, size_t) __pure; /* LEGACY */ void bcopy(const void *, void *, size_t); /* LEGACY */ void bzero(void *, size_t); /* LEGACY */ #endif It is POSIX LEGACY, but standard BSD. The POSIX ifdef is quite broken: - before 1996, POSIX didn't have this function, but it also didn't have strings.h so there is no problem (the ifdef is vacuously correct) - between 1996 and 2001, there was an XSI version there may have been a POSIX version that had this function and strings.h too. The ifdef is wrong for any such version since it doesn't mention XSI. Such versions are just unsupported. - between 2001 and 2008, POSIX apparently required bcopy() (and the other functions) but didn't declare them anywhere, except in the XSI case it requires them to be declared in strings.h. The above supports the non-XSI case of this. The XSI case is broken as in any 1996-2001 versions. - the ifdef is not up to date with changing LEGACY to OBSOLETE, but since LEGACY already resulted in omission of the prototypes in the non-XSI case, nothing needed to be changed in this case, and since the XSI case is unsupported nothing need to be changed to turn off the prototypes for XSI either. Correct code here wouldn't have the POSIX ifdef or LEGACY comments, but might having a comment saying that XSI is intentionally unsupported. XSI messes elswhere are
Re: svn commit: r286715 - head/lib/libc/string
Hi Bruce, I sent it already in private to you, as we were talking about the implementation of bcopy(3) on BSD and the POSIX one. So, I will send the patch again here, to let other developer give their opinion about it. Thanks to explain over and over again. Now it is clear to me. All the best. 2015-08-13 12:46 GMT+08:00 Bruce Evans b...@optusnet.com.au: On Thu, 13 Aug 2015, Marcelo Araujo wrote: Author: araujo Date: Thu Aug 13 02:31:23 2015 New Revision: 286715 URL: https://svnweb.freebsd.org/changeset/base/286715 Log: Remove the mention of memcpy(3) that is build on top of bcopy(3). Fix some phrases to make it more clear. Differential Revision: D3378 Reported by: bde@ Reviewed by: wblock Approved by: bapt, rodrigc (mentor) Sponsored by: gandi.net I don't like this version either :-). Modified: head/lib/libc/string/bcopy.3 == --- head/lib/libc/string/bcopy.3Thu Aug 13 01:04:26 2015 (r286714) +++ head/lib/libc/string/bcopy.3Thu Aug 13 02:31:23 2015 (r286715) @@ -31,7 +31,7 @@ .\ @(#)bcopy.3 8.1 (Berkeley) 6/4/93 .\ $FreeBSD$ .\ -.Dd August 11, 2015 +.Dd August 13, 2015 .Dt BCOPY 3 .Os .Sh NAME @@ -58,16 +58,14 @@ If .Fa len is zero, no bytes are copied. .Pp -This function is deprecated (marked as LEGACY in -POSIX.1-2001): use -.Xr memcpy 3 -or +This function is obsolete (marked as LEGACY in +POSIX.1-2001): please use This function is not obsolete, but is fully supported in FreeBSD. Its obsoletely doesn't follow at all from the clause in parentheses. LEGACY doesn't even mean obsolencent. In computerspeak it means old stuff that we don't like. I think you got the obsolete wording from NetBSD. But I think NetBSD started deprecating it in 1995. It might really be obsolete for them after 20 years of deprecation. Please don't use pleasant nonsenses like please in man pages or comments. .Xr memmove 3 in new programs. Still not quite right. New programs should use the best function and that is usually memcpy(). Only old programs that are being roto-tilled should convert bcopy() to memmove() (so as to avoid having to understand them well enough to know if they do overlapped copies). -Note that the first two arguments are -interchanged for -.Xr memcpy 3 -and +Note that +.Fn bcopy +takes its src and dst arguments in the opposite +order from .Xr memmove 3 . OK, except Xr should be Fn. .Xr memmove 3 is a man page, not a function. Man pages don't take src and dst arguments :-). This normally shows up in the rendering -- in text mode, Fn gives highlighting but Xr doesn't. Now I notice more markup problems: the src and dst arguments are not marked up. In text mode, Fa gives highlighting for args. POSIX.1-2008 removes the specification of .Fn bcopy . Better put this before the LEGACY statement and maybe merge the LEGACY statement into the HISTORY section. Since I don't want to deprecate bcopy(), I would put this in the history section too. Technically, this function is not deprecated since it is still a standard BSD function in strings.h. The ifdef for this is already quite complicated and broken, thoough it only attempts to keep up with some of the POSIX churn: from strings.h: #if __BSD_VISIBLE || __POSIX_VISIBLE = 200112 int bcmp(const void *, const void *, size_t) __pure; /* LEGACY */ void bcopy(const void *, void *, size_t); /* LEGACY */ void bzero(void *, size_t); /* LEGACY */ #endif It is POSIX LEGACY, but standard BSD. The POSIX ifdef is quite broken: - before 1996, POSIX didn't have this function, but it also didn't have strings.h so there is no problem (the ifdef is vacuously correct) - between 1996 and 2001, there was an XSI version there may have been a POSIX version that had this function and strings.h too. The ifdef is wrong for any such version since it doesn't mention XSI. Such versions are just unsupported. - between 2001 and 2008, POSIX apparently required bcopy() (and the other functions) but didn't declare them anywhere, except in the XSI case it requires them to be declared in strings.h. The above supports the non-XSI case of this. The XSI case is broken as in any 1996-2001 versions. - the ifdef is not up to date with changing LEGACY to OBSOLETE, but since LEGACY already resulted in omission of the prototypes in the non-XSI case, nothing needed to be changed in this case, and since the XSI case is unsupported nothing need to be changed to turn off the prototypes for XSI either. Correct code here wouldn't have the POSIX ifdef or LEGACY comments, but might having a comment saying that XSI is intentionally unsupported. XSI messes elswhere are supported, and I am suprised that not supporting it here doesn't cause
Re: svn commit: r286715 - head/lib/libc/string
On Thu, 13 Aug 2015, David Chisnall wrote: On 13 Aug 2015, at 08:11, Marcelo Araujo araujobsdp...@gmail.com wrote: The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std 1003.1-2001. In my understood it is obsolete on POSIX, but not truly obsolete for FreeBSD. So I believe, this patch now address it in the correct way. Its use should be strongly discouraged in FreeBSD (or, ideally, replaced with the macro from the POSIX man page). LLVM does a load of optimisations for memmove and memcpy - using bcopy is a really good way of bypassing all of these. That is a good reason to use bcopy. Compilers are clueless about caches, so their optimizations tend to be negative. clang has a nice one now, not related to caches. It uses SSE if possible for small fixed-size memcpy's, so takes a few hundred cycles longer for the first memcpy per context switch if SSE would not have otherwise be used. Compilers cannot know if this is a good optimization. If this were important, then someone except me would have noticed that switching to -ffreestanding in the kernel turned off all builtins including the one for memcpy(). But it really is unimportant. Most copying in the kernel is done by pagecopy(), and the possible gains from optimizing that are on the order of 1% except in micro-benchmarks that arrange to do excessive pagecopy()s. The possible gains from optimizations in the memcpy() builtin are much smaller. The possible gains from restoring all builtins may be as much as 1%. I recently noticed bcmp() showing up in benchmarks. Only 1% for makeworld, but that is a lot for a single function. clang doesn't bother optimizing memcmp() and calls the library. gcc-4.2.1 pessimizes memcmp using rep cmpsb on x86 (gcc used to use a similar pessimization for memcpy(), but learned better. Strangely, rep movsb is now the best method on Haswell except for small counts where gcc used to use it). The library and kernel memcmp()s are not as bad as gcc's, but they still use rep movs[lq] and this is still slow on Haswell. Simple C code is more than 6 times faster in micro-benchmarks on Haswell. The FreeBSD library MI C code is a little too simple. It uses bytewise compares, so it it beats rep cmpsb but not rep cmpsl. Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r286715 - head/lib/libc/string
FWIW; I think the posix manpage is in the right direction. For a more detailed discussion about replacing bcopys you may read Ted Unangst's blog post[1], but of course OpenBSD is not FreeBSD. I honesly would sepnd much time in bcopy, it is one of those things that will stay in FreeBSD for a long while. I would focus on strtoq() and strtouq() which carry this *comical* notice in stdlib.h : /* Deprecated interfaces, to be removed in FreeBSD 6.0. */ Cheers, Pedro. [1] http://www.tedunangst.com/flak/post/memcpy-vs-memmove On 13/08/2015 02:56 a.m., Marcelo Araujo wrote: Hi David, So it means, this commit here was right already: https://svnweb.freebsd.org/base?view=revisionrevision=286651 Although I made a mistake with the date. All the best. 2015-08-13 15:24 GMT+08:00 David Chisnall thera...@freebsd.org mailto:thera...@freebsd.org: On 13 Aug 2015, at 08:11, Marcelo Araujo araujobsdp...@gmail.com mailto:araujobsdp...@gmail.com wrote: The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std 1003.1-2001. In my understood it is obsolete on POSIX, but not truly obsolete for FreeBSD. So I believe, this patch now address it in the correct way. Its use should be strongly discouraged in FreeBSD (or, ideally, replaced with the macro from the POSIX man page). LLVM does a load of optimisations for memmove and memcpy - using bcopy is a really good way of bypassing all of these. David -- -- Marcelo Araujo(__) ara...@freebsd.org mailto:ara...@freebsd.org \\\'',) http://www.FreeBSD.org http://www.freebsd.org/\/ \ ^ Power To Server. .\. /_) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r286715 - head/lib/libc/string
On Thu, 13 Aug 2015, Marcelo Araujo wrote: Author: araujo Date: Thu Aug 13 02:31:23 2015 New Revision: 286715 URL: https://svnweb.freebsd.org/changeset/base/286715 Log: Remove the mention of memcpy(3) that is build on top of bcopy(3). Fix some phrases to make it more clear. Differential Revision: D3378 Reported by: bde@ Reviewed by: wblock Approved by: bapt, rodrigc (mentor) Sponsored by: gandi.net I don't like this version either :-). Modified: head/lib/libc/string/bcopy.3 == --- head/lib/libc/string/bcopy.3Thu Aug 13 01:04:26 2015 (r286714) +++ head/lib/libc/string/bcopy.3Thu Aug 13 02:31:23 2015 (r286715) @@ -31,7 +31,7 @@ .\ @(#)bcopy.38.1 (Berkeley) 6/4/93 .\ $FreeBSD$ .\ -.Dd August 11, 2015 +.Dd August 13, 2015 .Dt BCOPY 3 .Os .Sh NAME @@ -58,16 +58,14 @@ If .Fa len is zero, no bytes are copied. .Pp -This function is deprecated (marked as LEGACY in -POSIX.1-2001): use -.Xr memcpy 3 -or +This function is obsolete (marked as LEGACY in +POSIX.1-2001): please use This function is not obsolete, but is fully supported in FreeBSD. Its obsoletely doesn't follow at all from the clause in parentheses. LEGACY doesn't even mean obsolencent. In computerspeak it means old stuff that we don't like. I think you got the obsolete wording from NetBSD. But I think NetBSD started deprecating it in 1995. It might really be obsolete for them after 20 years of deprecation. Please don't use pleasant nonsenses like please in man pages or comments. .Xr memmove 3 in new programs. Still not quite right. New programs should use the best function and that is usually memcpy(). Only old programs that are being roto-tilled should convert bcopy() to memmove() (so as to avoid having to understand them well enough to know if they do overlapped copies). -Note that the first two arguments are -interchanged for -.Xr memcpy 3 -and +Note that +.Fn bcopy +takes its src and dst arguments in the opposite +order from .Xr memmove 3 . OK, except Xr should be Fn. .Xr memmove 3 is a man page, not a function. Man pages don't take src and dst arguments :-). This normally shows up in the rendering -- in text mode, Fn gives highlighting but Xr doesn't. Now I notice more markup problems: the src and dst arguments are not marked up. In text mode, Fa gives highlighting for args. POSIX.1-2008 removes the specification of .Fn bcopy . Better put this before the LEGACY statement and maybe merge the LEGACY statement into the HISTORY section. Since I don't want to deprecate bcopy(), I would put this in the history section too. Technically, this function is not deprecated since it is still a standard BSD function in strings.h. The ifdef for this is already quite complicated and broken, thoough it only attempts to keep up with some of the POSIX churn: from strings.h: #if __BSD_VISIBLE || __POSIX_VISIBLE = 200112 int bcmp(const void *, const void *, size_t) __pure; /* LEGACY */ void bcopy(const void *, void *, size_t); /* LEGACY */ void bzero(void *, size_t); /* LEGACY */ #endif It is POSIX LEGACY, but standard BSD. The POSIX ifdef is quite broken: - before 1996, POSIX didn't have this function, but it also didn't have strings.h so there is no problem (the ifdef is vacuously correct) - between 1996 and 2001, there was an XSI version there may have been a POSIX version that had this function and strings.h too. The ifdef is wrong for any such version since it doesn't mention XSI. Such versions are just unsupported. - between 2001 and 2008, POSIX apparently required bcopy() (and the other functions) but didn't declare them anywhere, except in the XSI case it requires them to be declared in strings.h. The above supports the non-XSI case of this. The XSI case is broken as in any 1996-2001 versions. - the ifdef is not up to date with changing LEGACY to OBSOLETE, but since LEGACY already resulted in omission of the prototypes in the non-XSI case, nothing needed to be changed in this case, and since the XSI case is unsupported nothing need to be changed to turn off the prototypes for XSI either. Correct code here wouldn't have the POSIX ifdef or LEGACY comments, but might having a comment saying that XSI is intentionally unsupported. XSI messes elswhere are supported, and I am suprised that not supporting it here doesn't cause problems. Ifdefs for historical mistakes would cause much larger messes if they were complete. Just near here, there is the mess of the string.h and strings.h. 1980's source code had messy ifdefs in applications for this. C90 didn't exactly help by standardizing the SYSVish string.h. POSIX.1-2001 actively harmed by restoring the BSDish strings.h. FreeBSD handles this problem by including strings.h in string.h if __BSD_VISIBLE and not documenting
