CVS commit: src/common/lib/libc/string
Module Name:src Committed By: andvar Date: Sat Jan 15 10:38:56 UTC 2022 Modified Files: src/common/lib/libc/string: memset2.c Log Message: fix typos in comments. To generate a diff of this commit: cvs rdiff -u -r1.10 -r1.11 src/common/lib/libc/string/memset2.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/common/lib/libc/string
Module Name:src
Committed By: andvar
Date: Sat Jan 15 10:38:56 UTC 2022
Modified Files:
src/common/lib/libc/string: memset2.c
Log Message:
fix typos in comments.
To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 src/common/lib/libc/string/memset2.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/common/lib/libc/string/memset2.c
diff -u src/common/lib/libc/string/memset2.c:1.10 src/common/lib/libc/string/memset2.c:1.11
--- src/common/lib/libc/string/memset2.c:1.10 Mon Apr 19 01:12:10 2021
+++ src/common/lib/libc/string/memset2.c Sat Jan 15 10:38:56 2022
@@ -1,4 +1,4 @@
-/* $NetBSD: memset2.c,v 1.10 2021/04/19 01:12:10 simonb Exp $ */
+/* $NetBSD: memset2.c,v 1.11 2022/01/15 10:38:56 andvar Exp $ */
/*-
* Copyright (c) 2009 The NetBSD Foundation, Inc.
@@ -31,7 +31,7 @@
#include
#if defined(LIBC_SCCS) && !defined(lint)
-__RCSID("$NetBSD: memset2.c,v 1.10 2021/04/19 01:12:10 simonb Exp $");
+__RCSID("$NetBSD: memset2.c,v 1.11 2022/01/15 10:38:56 andvar Exp $");
#endif /* LIBC_SCCS and not lint */
#include
@@ -95,7 +95,7 @@ memset(void *addr, int c, size_t len)
/*
* Pad out the fill byte (v) across a memword_t.
- * The conditional at the end prevents GCC from complaing about
+ * The conditional at the end prevents GCC from complaining about
* shift count >= width of type
*/
fill = (unsigned char)c;
@@ -183,13 +183,13 @@ memset(void *addr, int c, size_t len)
/*
* We want to clear leading bytes in the word.
* On big/little endian, these are the most/least significant
- * bits, respectively, But as we want the mask of the bytes to
+ * bits, respectively. But as we want the mask of the bytes to
* keep, we have to complement the mask. So after we shift,
* the keep_mask will only have bits set for the bytes we won't
* be filling.
*
* But the keep_mask could already have bytes to preserve
- * if the amount to fill was less than the amount of traiing
+ * if the amount to fill was less than the amount of trailing
* space in the first word.
*/
#if BYTE_ORDER == BIG_ENDIAN
CVS commit: src/common/lib/libc/string
Module Name:src Committed By: christos Date: Sat Jan 20 14:55:11 UTC 2024 Modified Files: src/common/lib/libc/string: strpbrk.c Log Message: Add __UNCONST To generate a diff of this commit: cvs rdiff -u -r1.2 -r1.3 src/common/lib/libc/string/strpbrk.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/common/lib/libc/string
Module Name:src
Committed By: christos
Date: Sat Jan 20 14:55:11 UTC 2024
Modified Files:
src/common/lib/libc/string: strpbrk.c
Log Message:
Add __UNCONST
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/common/lib/libc/string/strpbrk.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/common/lib/libc/string/strpbrk.c
diff -u src/common/lib/libc/string/strpbrk.c:1.2 src/common/lib/libc/string/strpbrk.c:1.3
--- src/common/lib/libc/string/strpbrk.c:1.2 Sat Feb 3 20:13:45 2018
+++ src/common/lib/libc/string/strpbrk.c Sat Jan 20 09:55:11 2024
@@ -1,4 +1,4 @@
-/* $NetBSD: strpbrk.c,v 1.2 2018/02/04 01:13:45 mrg Exp $ */
+/* $NetBSD: strpbrk.c,v 1.3 2024/01/20 14:55:11 christos Exp $ */
/*-
* Copyright (c) 2008 Joerg Sonnenberger
@@ -26,7 +26,7 @@
*/
#include
-__RCSID("$NetBSD: strpbrk.c,v 1.2 2018/02/04 01:13:45 mrg Exp $");
+__RCSID("$NetBSD: strpbrk.c,v 1.3 2024/01/20 14:55:11 christos Exp $");
#if !defined(_KERNEL) && !defined(_STANDALONE)
#include
@@ -64,7 +64,7 @@ strpbrk(const char *s, const char *chars
if (charset[0] == '\0')
return NULL;
if (charset[1] == '\0')
- return strchr(s, charset[0]);
+ return __UNCONST(strchr(s, charset[0]));
for (; *charset != '\0'; ++charset)
ADD_TO_SET(UC(*charset));
CVS commit: src/common/lib/libc/string
Module Name:src
Committed By: rillig
Date: Sun Jun 18 22:18:13 UTC 2023
Modified Files:
src/common/lib/libc/string: strspn.c
Log Message:
strspn: fix typo in comment
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/common/lib/libc/string/strspn.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/common/lib/libc/string/strspn.c
diff -u src/common/lib/libc/string/strspn.c:1.2 src/common/lib/libc/string/strspn.c:1.3
--- src/common/lib/libc/string/strspn.c:1.2 Sun Feb 4 01:13:45 2018
+++ src/common/lib/libc/string/strspn.c Sun Jun 18 22:18:13 2023
@@ -1,4 +1,4 @@
-/* $NetBSD: strspn.c,v 1.2 2018/02/04 01:13:45 mrg Exp $ */
+/* $NetBSD: strspn.c,v 1.3 2023/06/18 22:18:13 rillig Exp $ */
/*-
* Copyright (c) 2008 Joerg Sonnenberger
@@ -26,7 +26,7 @@
*/
#include
-__RCSID("$NetBSD: strspn.c,v 1.2 2018/02/04 01:13:45 mrg Exp $");
+__RCSID("$NetBSD: strspn.c,v 1.3 2023/06/18 22:18:13 rillig Exp $");
#if !defined(_KERNEL) && !defined(_STANDALONE)
#include
@@ -114,7 +114,7 @@ strspn_x(const char *s_s, const char *ch
/*
* We could do remove the lsb from m_0 to terminate at the
* end of the input string.
- * However prefetching the next char is benifitial and we must
+ * However prefetching the next char is beneficial and we must
* not read the byte after the \0 - as it might fault!
* So we take the 'hit' of the compare against 0.
*/
CVS commit: src/common/lib/libc/string
Module Name:src Committed By: rillig Date: Sun Jun 18 22:18:13 UTC 2023 Modified Files: src/common/lib/libc/string: strspn.c Log Message: strspn: fix typo in comment To generate a diff of this commit: cvs rdiff -u -r1.2 -r1.3 src/common/lib/libc/string/strspn.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/common/lib/libc/string
On Sun, Aug 21, 2011 at 09:25:04PM +, David A. Holland wrote: > Module Name: src > Committed By: dholland > Date: Sun Aug 21 21:25:04 UTC 2011 > > Modified Files: > src/common/lib/libc/string: popcount32.c popcount64.c > > Log Message: > Requires stdint.h. > > > To generate a diff of this commit: > cvs rdiff -u -r1.3 -r1.4 src/common/lib/libc/string/popcount32.c > cvs rdiff -u -r1.5 -r1.6 src/common/lib/libc/string/popcount64.c No? Joerg
Re: CVS commit: src/common/lib/libc/string
On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > > Modified Files: > >src/common/lib/libc/string: popcount32.c popcount64.c > > > > Log Message: > > Requires stdint.h. > > No? uh what? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/common/lib/libc/string
On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > > > Modified Files: > > > src/common/lib/libc/string: popcount32.c popcount64.c > > > > > > Log Message: > > > Requires stdint.h. > > > > No? > > uh what? It doesn't. The prototypes in strings.h already ensure that uint32_t/uint64_t are present and that's the only thing it could ever need from stdint.h. Joerg
Re: CVS commit: src/common/lib/libc/string
On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > > > > Modified Files: > > > > src/common/lib/libc/string: popcount32.c popcount64.c > > > > > > > > Log Message: > > > > Requires stdint.h. > > > > > > No? > > > > uh what? > > It doesn't. The prototypes in strings.h already ensure that > uint32_t/uint64_t are present and that's the only thing it could ever > need from stdint.h. Yes it does. strings.h is included by string.h and is therefore not allowed to include stdint.h itself. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/common/lib/libc/string
On Mon, Aug 22, 2011 at 01:26:24AM +, David Holland wrote: > On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: > > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: > > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > > > > > Modified Files: > > > > > src/common/lib/libc/string: popcount32.c popcount64.c > > > > > > > > > > Log Message: > > > > > Requires stdint.h. > > > > > > > > No? > > > > > > uh what? > > > > It doesn't. The prototypes in strings.h already ensure that > > uint32_t/uint64_t are present and that's the only thing it could ever > > need from stdint.h. > > Yes it does. strings.h is included by string.h and is therefore not > allowed to include stdint.h itself. You are skinning the wrong cat. string.h shouldn't include strings.h in first place. Joerg
Re: CVS commit: src/common/lib/libc/string
On Mon, Aug 22, 2011 at 12:48:22 +0200, Joerg Sonnenberger wrote: > On Mon, Aug 22, 2011 at 01:26:24AM +, David Holland wrote: > > On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: > > > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: > > > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > > > > > > Modified Files: > > > > > > src/common/lib/libc/string: popcount32.c popcount64.c > > > > > > > > > > > > Log Message: > > > > > > Requires stdint.h. > > > > > > > > > > No? > > > > > > > > uh what? > > > > > > It doesn't. The prototypes in strings.h already ensure that > > > uint32_t/uint64_t are present and that's the only thing it could ever > > > need from stdint.h. > > > > Yes it does. strings.h is included by string.h and is therefore not > > allowed to include stdint.h itself. > > You are skinning the wrong cat. string.h shouldn't include strings.h in > first place. #if defined(_NETBSD_SOURCE) #include /* for backwards-compatibilty */ ... -uwe
Re: CVS commit: src/common/lib/libc/string
In article <20110822104822.gb15...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Mon, Aug 22, 2011 at 01:26:24AM +, David Holland wrote: >> On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: >> > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: >> > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: >> > > > > Modified Files: >> > > > >src/common/lib/libc/string: popcount32.c popcount64.c >> > > > > >> > > > > Log Message: >> > > > > Requires stdint.h. >> > > > >> > > > No? >> > > >> > > uh what? >> > >> > It doesn't. The prototypes in strings.h already ensure that >> > uint32_t/uint64_t are present and that's the only thing it could ever >> > need from stdint.h. >> >> Yes it does. strings.h is included by string.h and is therefore not >> allowed to include stdint.h itself. > >You are skinning the wrong cat. string.h shouldn't include strings.h in >first place. I agree. It is wrong for string.h to include strings.h since it exposes the old bsd functions. christos
Re: CVS commit: src/common/lib/libc/string
On Mon, Aug 22, 2011 at 04:48:02PM +0400, Valeriy E. Ushakov wrote: > > > > It doesn't. The prototypes in strings.h already ensure that > > > > uint32_t/uint64_t are present and that's the only thing it could ever > > > > need from stdint.h. > > > > > > Yes it does. strings.h is included by string.h and is therefore not > > > allowed to include stdint.h itself. > > > > You are skinning the wrong cat. string.h shouldn't include strings.h in > > first place. > > #if defined(_NETBSD_SOURCE) > #include /* for backwards-compatibilty */ > ... I'm aware of that. It was pointed out the last time this behavior was *properly* discussed. I wouldn't mind killing that part completely, but I completely disagree with David's changed for strings.h. Joerg
Re: CVS commit: src/common/lib/libc/string
On Mon, Aug 22, 2011 at 16:48:02 +0400, Valeriy E. Ushakov wrote: > On Mon, Aug 22, 2011 at 12:48:22 +0200, Joerg Sonnenberger wrote: [...] > > You are skinning the wrong cat. string.h shouldn't include strings.h in > > first place. > > #if defined(_NETBSD_SOURCE) > #include /* for backwards-compatibilty */ > ... Bah, never mind, I misread. I agree, it shouldn't. -uwe
Re: CVS commit: src/common/lib/libc/string
On Mon, Aug 22, 2011 at 12:48:22PM +0200, Joerg Sonnenberger wrote: > > > > > > Requires stdint.h. > > > > > > > > > > No? > > > > > > > > uh what? > > > > > > It doesn't. The prototypes in strings.h already ensure that > > > uint32_t/uint64_t are present and that's the only thing it could ever > > > need from stdint.h. > > > > Yes it does. strings.h is included by string.h and is therefore not > > allowed to include stdint.h itself. > > You are skinning the wrong cat. string.h shouldn't include strings.h in > first place. That's nice but totally at variance with historical practice and the expectations of third-party software. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/common/lib/libc/string
[Yay, catching up with a month's worth of source-changes...] On Mon, Aug 22, 2011 at 12:46:21PM +, Christos Zoulas wrote: > In article <20110822104822.gb15...@britannica.bec.de>, > Joerg Sonnenberger wrote: > >On Mon, Aug 22, 2011 at 01:26:24AM +, David Holland wrote: > >> On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: > >> > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: > >> > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > >> > > > > Modified Files: > >> > > > > src/common/lib/libc/string: popcount32.c popcount64.c > >> > > > > > >> > > > > Log Message: > >> > > > > Requires stdint.h. > >> > > > > >> > > > No? > >> > > > >> > > uh what? > >> > > >> > It doesn't. The prototypes in strings.h already ensure that > >> > uint32_t/uint64_t are present and that's the only thing it could ever > >> > need from stdint.h. > >> > >> Yes it does. strings.h is included by string.h and is therefore not > >> allowed to include stdint.h itself. > > > >You are skinning the wrong cat. string.h shouldn't include strings.h in > >first place. > > I agree. It is wrong for string.h to include strings.h since it exposes > the old bsd functions. To provide some perspective, the way the headers were laid out Back Then was meant to achieve near-conformance while (at the same time) to avoid breaking too much existing code. The latter situation ought to have improved since, though. :-) However, the issue I'm having with this is the addition of a new interface (popcount(3)) to what ought to be considered a mostly legacy (but still standard-defined) header (), which gives us the worst of both worlds. (I'd have voiced my concerns in time if I hadn't managed to entirely miss the introduction. *sigh*) - Klaus
Re: CVS commit: src/common/lib/libc/string
In article <20110923163839.ga4...@kleink.org>, Klaus Klein wrote: >[Yay, catching up with a month's worth of source-changes...] > >On Mon, Aug 22, 2011 at 12:46:21PM +, Christos Zoulas wrote: >> In article <20110822104822.gb15...@britannica.bec.de>, >> Joerg Sonnenberger wrote: >> >On Mon, Aug 22, 2011 at 01:26:24AM +, David Holland wrote: >> >> On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: >> >> > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: >> >> > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: >> >> > > > > Modified Files: >> >> > > > > src/common/lib/libc/string: popcount32.c popcount64.c >> >> > > > > >> >> > > > > Log Message: >> >> > > > > Requires stdint.h. >> >> > > > >> >> > > > No? >> >> > > >> >> > > uh what? >> >> > >> >> > It doesn't. The prototypes in strings.h already ensure that >> >> > uint32_t/uint64_t are present and that's the only thing it could ever >> >> > need from stdint.h. >> >> >> >> Yes it does. strings.h is included by string.h and is therefore not >> >> allowed to include stdint.h itself. >> > >> >You are skinning the wrong cat. string.h shouldn't include strings.h in >> >first place. >> >> I agree. It is wrong for string.h to include strings.h since it exposes >> the old bsd functions. > >To provide some perspective, the way the headers were laid out Back Then >was meant to achieve near-conformance while (at the same time) to avoid >breaking too much existing code. The latter situation ought to have >improved since, though. :-) > >However, the issue I'm having with this is the addition of a new >interface (popcount(3)) to what ought to be considered a mostly legacy >(but still standard-defined) header (), which gives us the >worst of both worlds. (I'd have voiced my concerns in time if I hadn't >managed to entirely miss the introduction. *sigh*) It is not too late to fix. We should add a comment in so people stop addding stuff to it, and we should move those out to . christos
Re: CVS commit: src/common/lib/libc/string
On Fri, Sep 23, 2011 at 08:33:22PM +, Christos Zoulas wrote: > In article <20110923163839.ga4...@kleink.org>, > Klaus Klein wrote: > >[Yay, catching up with a month's worth of source-changes...] > > > >On Mon, Aug 22, 2011 at 12:46:21PM +, Christos Zoulas wrote: > >> In article <20110822104822.gb15...@britannica.bec.de>, > >> Joerg Sonnenberger wrote: > >> >On Mon, Aug 22, 2011 at 01:26:24AM +, David Holland wrote: > >> >> On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote: > >> >> > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote: > >> >> > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote: > >> >> > > > > Modified Files: > >> >> > > > > src/common/lib/libc/string: popcount32.c popcount64.c > >> >> > > > > > >> >> > > > > Log Message: > >> >> > > > > Requires stdint.h. > >> >> > > > > >> >> > > > No? > >> >> > > > >> >> > > uh what? > >> >> > > >> >> > It doesn't. The prototypes in strings.h already ensure that > >> >> > uint32_t/uint64_t are present and that's the only thing it could ever > >> >> > need from stdint.h. > >> >> > >> >> Yes it does. strings.h is included by string.h and is therefore not > >> >> allowed to include stdint.h itself. > >> > > >> >You are skinning the wrong cat. string.h shouldn't include strings.h in > >> >first place. > >> > >> I agree. It is wrong for string.h to include strings.h since it exposes > >> the old bsd functions. > > > >To provide some perspective, the way the headers were laid out Back Then > >was meant to achieve near-conformance while (at the same time) to avoid > >breaking too much existing code. The latter situation ought to have > >improved since, though. :-) > > > >However, the issue I'm having with this is the addition of a new > >interface (popcount(3)) to what ought to be considered a mostly legacy > >(but still standard-defined) header (), which gives us the > >worst of both worlds. (I'd have voiced my concerns in time if I hadn't > >managed to entirely miss the introduction. *sigh*) > > It is not too late to fix. We should add a comment in so people > stop addding stuff to it, and we should move those out to . The reason for popcount being in strings.h is that it matches ffs. ffs is in strings.h according to SUS. Joerg
Re: CVS commit: src/common/lib/libc/string
In article <20110924094308.ga30...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Fri, Sep 23, 2011 at 08:33:22PM +, Christos Zoulas wrote:
>> In article <20110923163839.ga4...@kleink.org>,
>> Klaus Klein wrote:
>> >[Yay, catching up with a month's worth of source-changes...]
>> >
>> >On Mon, Aug 22, 2011 at 12:46:21PM +, Christos Zoulas wrote:
>> >> In article <20110822104822.gb15...@britannica.bec.de>,
>> >> Joerg Sonnenberger wrote:
>> >> >On Mon, Aug 22, 2011 at 01:26:24AM +, David Holland wrote:
>> >> >> On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote:
>> >> >> > On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote:
>> >> >> > > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger
>> >> >> wrote:
>> >> >> > > > > Modified Files:
>> >> >> > > > > src/common/lib/libc/string: popcount32.c popcount64.c
>> >> >> > > > >
>> >> >> > > > > Log Message:
>> >> >> > > > > Requires stdint.h.
>> >> >> > > >
>> >> >> > > > No?
>> >> >> > >
>> >> >> > > uh what?
>> >> >> >
>> >> >> > It doesn't. The prototypes in strings.h already ensure that
>> >> >> > uint32_t/uint64_t are present and that's the only thing it could
>> >> >> ever
>> >> >> > need from stdint.h.
>> >> >>
>> >> >> Yes it does. strings.h is included by string.h and is therefore not
>> >> >> allowed to include stdint.h itself.
>> >> >
>> >> >You are skinning the wrong cat. string.h shouldn't include strings.h in
>> >> >first place.
>> >>
>> >> I agree. It is wrong for string.h to include strings.h since it exposes
>> >> the old bsd functions.
>> >
>> >To provide some perspective, the way the headers were laid out Back Then
>> >was meant to achieve near-conformance while (at the same time) to avoid
>> >breaking too much existing code. The latter situation ought to have
>> >improved since, though. :-)
>> >
>> >However, the issue I'm having with this is the addition of a new
>> >interface (popcount(3)) to what ought to be considered a mostly legacy
>> >(but still standard-defined) header (), which gives us the
>> >worst of both worlds. (I'd have voiced my concerns in time if I hadn't
>> >managed to entirely miss the introduction. *sigh*)
>>
>> It is not too late to fix. We should add a comment in so people
>> stop addding stuff to it, and we should move those out to .
>
>The reason for popcount being in strings.h is that it matches ffs. ffs
>is in strings.h according to SUS.
Perhaps it is better then to move ffs() and str{n,}casecmp() to string.h,
have strings.h always include string.h, and only leave the legacy functions
(rindex,index,bcopy,bzero,bcmp) in strings.h, and remove the inclusion of
strings.h from string.h.
christos
Re: CVS commit: src/common/lib/libc/string
On Fri, Mar 02, 2012 at 08:10:19PM +0200, Jukka Ruohonen wrote: > And what was the resolution with all this? (cf. useless changes?). > And to the point: time to change VCS? - Jukka.
Re: CVS commit: src/common/lib/libc/string
qOn Fri, Mar 02, 2012 at 04:19:15PM +, Alan Barrett wrote: > Module Name: src > Committed By: apb > Date: Fri Mar 2 16:19:15 UTC 2012 > > Modified Files: > src/common/lib/libc/string: memset2.c > > Log Message: > Change CTASSERT to __CTASSERT (the spelling used in ), > include so that it will be defined, > and move it to a better place. > > The previous CTASSERT would never have been used because > of the ifdef. If it had been used, it would have had > unwanted effects from being just after the "static inline" > that appears when BZERO is defined. > > Also move the __RCSID to a more conventional location. And what was the resolution with all this? (cf. useless changes?). Please change the documentation too (and most of all, !). - Jukka.
Re: CVS commit: src/common/lib/libc/string
On Fri, 02 Mar 2012, Jukka Ruohonen wrote: Log Message: Change CTASSERT to __CTASSERT (the spelling used in ), include so that it will be defined, and move it to a better place. The previous CTASSERT would never have been used because of the ifdef. If it had been used, it would have had unwanted effects from being just after the "static inline" that appears when BZERO is defined. Also move the __RCSID to a more conventional location. And what was the resolution with all this? (cf. useless changes?). Sorry, I don't understand what you mean. Please change the documentation too (and most of all, !). It seems taht CTASSERT is defined in libkern.h, so is available to kernel code. I'll fix the documentation. --apb (Alan Barrett)
Re: CVS commit: src/common/lib/libc/string
On Mar 2, 2012, at 11:15 AM, Alan Barrett wrote: > On Fri, 02 Mar 2012, Jukka Ruohonen wrote: >>> Log Message: >>> Change CTASSERT to __CTASSERT (the spelling used in ), >>> include so that it will be defined, >>> and move it to a better place. >>> >>> The previous CTASSERT would never have been used because >>> of the ifdef. If it had been used, it would have had >>> unwanted effects from being just after the "static inline" >>> that appears when BZERO is defined. >>> >>> Also move the __RCSID to a more conventional location. >> >> And what was the resolution with all this? (cf. useless changes?). > > Sorry, I don't understand what you mean. > >> Please change the documentation too (and most of all, !). > > It seems taht CTASSERT is defined in libkern.h, so is available to > kernel code. I'll fix the documentation. __CTASSERT is available everywhere
Re: CVS commit: src/common/lib/libc/string
On Mon, 14 Apr 2014, Joerg Sonnenberger wrote: Modified Files: src/common/lib/libc/string: bcopy.c Log Message: Using bcopy/memcpy with NULL arguments is valid as long as the size is also 0. No, it's undefined behaviour. C99 section 7.21.1: Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. and 7.1.4 says: If an argument to a function has an invalid value (such as ... a null pointer ...) ..., the behavior is undefined. and 7.21.2.1 "The memcpy function" does not give any explicit permission for use of null pointers. I don't object if the implementation wants to allow null pointers with zero size as an extension, but it should be clear that this is non-standard. --apb (Alan Barrett)
Re: CVS commit: src/common/lib/libc/string
Hello, "Joerg Sonnenberger" wrote: |Module Name: src |Committed By: joerg |Date: Mon Apr 14 18:18:58 UTC 2014 | |Modified Files: | src/common/lib/libc/string: bcopy.c | |Log Message: |Using bcopy/memcpy with NULL arguments is valid as long as the size is |also 0. This is great interface design and easy to use, but it is not specified in neither POSIX nor ISO C (11). And worse i'm afraid that the ISO C people would actively veto this very behaviour given that wmemcpy(3) is standardized as If n is zero, the application shall ensure that ws1 and ws2 are valid pointers, and the function shall copy zero wide characters. --steffen
Re: CVS commit: src/common/lib/libc/string
P.S.: i wasn't subscribed to this list (until hopefully now), so i haven't seen that Alan Barrett already commented. But now that i read it, ISO C 2011 states the same (7.24.1). --steffen
Re: CVS commit: src/common/lib/libc/string
On Tue, Apr 15, 2014 at 08:06:57AM +0200, Alan Barrett wrote: > On Mon, 14 Apr 2014, Joerg Sonnenberger wrote: > >Modified Files: > > src/common/lib/libc/string: bcopy.c > > > >Log Message: > >Using bcopy/memcpy with NULL arguments is valid as long as the size is > >also 0. > > No, it's undefined behaviour. C99 section 7.21.1: > >Unless explicitly stated otherwise in the description of a >particular function in this subclause, pointer arguments on >such a call shall still have valid values, as described in >7.1.4. > > and 7.1.4 says: > >If an argument to a function has an invalid value (such as ... >a null pointer ...) ..., the behavior is undefined. > > and 7.21.2.1 "The memcpy function" does not give any explicit > permission for use of null pointers. > > I don't object if the implementation wants to allow null pointers > with zero size as an extension, but it should be clear that this is > non-standard. I remember a discussion about this topic from the LLVM lists and the reasons for the standard language on this are extremely weak. IIRC the *only* justification was for some platforms with broken (trapping) prefetch instructions. Joerg
Re: CVS commit: src/common/lib/libc/string
On Tue, Apr 15, 2014 at 03:41:55PM +0200, Joerg Sonnenberger wrote: > > I remember a discussion about this topic from the LLVM lists and the > reasons for the standard language on this are extremely weak. IIRC the > *only* justification was for some platforms with broken (trapping) > prefetch instructions. That can only possibly matter if memcpy() is implemented with something (equivalent to) 'rep movsb' - otherwise the broken prefetch would happen during normal code sequences. I'd have thought a zero length memcpy() would also be valid with (the valid) pointer to 'just beyond' and item. A prefetch there could also fault. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/common/lib/libc/string
(yes, change is from January, I'm hugely behind) On Mon, Jan 27, 2020 at 10:22:03PM +, Andrew Doran wrote: > Modified Files: > src/common/lib/libc/string: bcmp.c memcmp.c > > Log Message: > Drop the alignment check if __NO_STRICT_ALIGNMENT (x86, m68k, vax). Even on machines that allow unaligned accesses, aligned accesses are usually faster, so would it be worthwhile to do a few byte comparisons first until at least one of the arguments is aligned? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/common/lib/libc/string
On Fri, May 29, 2015 at 07:39:41PM +, Matt Thomas wrote: > Module Name: src > Committed By: matt > Date: Fri May 29 19:39:41 UTC 2015 > > Modified Files: > src/common/lib/libc/string: popcount32.c popcount64.c > > Log Message: > Don't compile if there is a macro of the same name. At least for libc, we definitely want to include the symbols. Joerg
Re: CVS commit: src/common/lib/libc/string
> On May 29, 2015, at 12:46 PM, Joerg Sonnenberger > wrote: > > On Fri, May 29, 2015 at 07:39:41PM +, Matt Thomas wrote: >> Module Name: src >> Committed By:matt >> Date:Fri May 29 19:39:41 UTC 2015 >> >> Modified Files: >> src/common/lib/libc/string: popcount32.c popcount64.c >> >> Log Message: >> Don't compile if there is a macro of the same name. > > At least for libc, we definitely want to include the symbols. which does happen since C doesn’t include libkern.h which defines them.
Re: CVS commit: src/common/lib/libc/string
On Wed, Oct 12, 2016 at 04:01:40PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Oct 12 20:01:40 UTC 2016 > > Added Files: > src/common/lib/libc/string: strchrnul.c > > Log Message: > Add strchrnul This seems to be completely pointless GNU crap. Why do we need it? Joerg
Re: CVS commit: src/common/lib/libc/string
On Thu, Oct 13, 2016 at 12:01:58AM +0200, Joerg Sonnenberger wrote: > On Wed, Oct 12, 2016 at 04:01:40PM -0400, Christos Zoulas wrote: > > Module Name:src > > Committed By: christos > > Date: Wed Oct 12 20:01:40 UTC 2016 > > > > Added Files: > > src/common/lib/libc/string: strchrnul.c > > > > Log Message: > > Add strchrnul > > This seems to be completely pointless GNU crap. Why do we need it? So strchrnul(a,b) seems to be a + strcspn(a,b), just in a non-portable way. I don't see the point of it at all. Please revert this. Also hit anyone using strchrnul with a cluebat please... Joerg
Re: CVS commit: src/common/lib/libc/string
In article <20161012220744.gb...@britannica.bec.de>, Joerg Sonnenberger wrote: >So strchrnul(a,b) seems to be a + strcspn(a,b), just in a non-portable >way. I don't see the point of it at all. Please revert this. Also hit >anyone using strchrnul with a cluebat please... That would be gdb... I can revert, but then I will have to add more hacks to gnu software... christos
Re: CVS commit: src/common/lib/libc/string
On Thu, Oct 13, 2016 at 01:27:00AM +, Christos Zoulas wrote: > In article <20161012220744.gb...@britannica.bec.de>, > Joerg Sonnenberger wrote: > > >So strchrnul(a,b) seems to be a + strcspn(a,b), just in a non-portable > >way. I don't see the point of it at all. Please revert this. Also hit > >anyone using strchrnul with a cluebat please... > > That would be gdb... I can revert, but then I will have to add more hacks > to gnu software... Given that the workaround is a trivial inline function, I'd strongly prefer that. The cluebat should still be applied. Joerg
Re: CVS commit: src/common/lib/libc/string
On Thu, Oct 13, 2016 at 01:27:00AM +, Christos Zoulas wrote: > That would be gdb... I can revert, but then I will have to add more hacks > to gnu software... That wouldn't have been more hacks because gdb expects to buidl on more than just GNU/Linux and would have accepted your patch As a result of using this being the chosen workaround the latest gdb doesn't work on netbsd-7 so I would need to do it anyway, but now we get to carry this function for decades to come.
Re: CVS commit: src/common/lib/libc/string
Although now I see that strchrnul is p widely accepted so I guess it's not that bad (freebsd and illumos have it, too)
