On Fri, Oct 29, 2021 at 10:11:57AM +, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Fri Oct 29 10:11:57 UTC 2021
>
> Modified Files:
> src/lib/libc/string: wcsdup.c
>
> Log Message:
> wcsdup(3): use reallocarr to catch integer overflow
Except that no such in
Date:Sat, 4 Apr 2020 21:16:45 +
From:David Holland
Message-ID: <20200404211645.ga19...@netbsd.org>
| I fail to see any scenario in which it's legitimate for an application
| to scribble in internal data belonging to libc. Why should this be
| permitted?
You
On Thu, Mar 26, 2020 at 10:54:21AM +0700, Robert Elz wrote:
> | I don't agree -- because applications shouldn't attempt to modify the
> | result, it should be const.
>
> The only reason apps shouldn't modify the string is in case of
> porting the app to an (well, some) ancient implementat
On Thu, Mar 26, 2020 at 10:54:21AM +0700, Robert Elz wrote:
> Date:Wed, 25 Mar 2020 20:51:25 +
> From:David Holland
> Message-ID: <20200325205125.ga11...@netbsd.org>
>
> | I don't agree -- because applications shouldn't attempt to modify the
> | result, it sho
Date:Wed, 25 Mar 2020 20:51:25 +
From:David Holland
Message-ID: <20200325205125.ga11...@netbsd.org>
| I don't agree -- because applications shouldn't attempt to modify the
| result, it should be const.
The only reason apps shouldn't modify the string is in ca
On Wed, Mar 25, 2020 at 06:50:47PM +, Robert Elz wrote:
> Modified Files:
> src/lib/libc/string: strerror.3
>
> Log Message:
> Delete the BUGS paragraph about the "missing" const qualifier for the
> result type of strerror() (and strerror_l()). While that once should
> really hav
On Jun 24, 4:35am, riastr...@netbsd.org (Taylor R Campbell) wrote:
-- Subject: Re: CVS commit: src/lib/libc/string
| Oops, that was silly of me -- the libc symbols actually have a double-
| underscore prefix, presumably meaning `these are internal; do not
| use'. Should I move the man pag
On Jun 24, 3:54am, riastr...@netbsd.org (Taylor R Campbell) wrote:
-- Subject: Re: CVS commit: src/lib/libc/string
|Date: Mon, 24 Jun 2013 01:36:29 + (UTC)
|From: chris...@astron.com (Christos Zoulas)
|
|I've objected many times railroading those in and casting the into
On Mon, 24 Jun 2013, Taylor R Campbell wrote:
Discuss on tech-userlevel?
Yes please.
--apb (Alan Barrett)
Oops, that was silly of me -- the libc symbols actually have a double-
underscore prefix, presumably meaning `these are internal; do not
use'. Should I move the man pages to section 9, or do we want these
exposed in libc, presumably requiring some weak aliasing cruft?
Discuss on tech-userlevel?
(
Date: Mon, 24 Jun 2013 01:36:29 + (UTC)
From: chris...@astron.com (Christos Zoulas)
I've objected many times railroading those in and casting the into stone
by adding man pages and making them part of a formal release. I give up :-(
Sorry, I didn't mean to stonewall or railroad an
In article <20130623164406.d678...@cvs.netbsd.org>,
Taylor R Campbell wrote:
>-=-=-=-=-=-
I've objected many times railroading those in and casting the into stone
by adding man pages and making them part of a formal release. I give up :-(
christos
On Fri, Nov 25, 2011 at 05:40:51PM +0100, Joerg Sonnenberger wrote:
> > And why should the/any static analyzer have to figure that out when
> > coding it right makes it a nonissue?
>
> Because that's what is making warnings useful. To not complain about
> non-issues.
Like this?
const cha
On Fri, Nov 25, 2011 at 04:23:46PM +, David Holland wrote:
> On Fri, Nov 25, 2011 at 02:48:30PM +0100, Joerg Sonnenberger wrote:
> > > > > > > Sure it does. You should just have written the code using
> (size_t)1,
> > > > > > > or even just 1UL, instead of 1ULL. There is no port where size_t
On Fri, Nov 25, 2011 at 02:48:30PM +0100, Joerg Sonnenberger wrote:
> > > > > > Sure it does. You should just have written the code using
> > > > > > (size_t)1,
> > > > > > or even just 1UL, instead of 1ULL. There is no port where size_t is
> > > > > > unsigned long long.
> > > > > >
> > >
On Fri, Nov 25, 2011 at 01:44:24PM +, David Holland wrote:
> On Fri, Nov 25, 2011 at 02:29:12PM +0100, Joerg Sonnenberger wrote:
> > > > > Sure it does. You should just have written the code using (size_t)1,
> > > > > or even just 1UL, instead of 1ULL. There is no port where size_t is
> > >
On Fri, Nov 25, 2011 at 02:29:12PM +0100, Joerg Sonnenberger wrote:
> > > > Sure it does. You should just have written the code using (size_t)1,
> > > > or even just 1UL, instead of 1ULL. There is no port where size_t is
> > > > unsigned long long.
> > > >
> > > > ... Unless what you meant wa
On Fri, Nov 25, 2011 at 01:18:19PM +, David Holland wrote:
> On Fri, Nov 25, 2011 at 02:15:12PM +0100, Joerg Sonnenberger wrote:
> > > Sure it does. You should just have written the code using (size_t)1,
> > > or even just 1UL, instead of 1ULL. There is no port where size_t is
> > > unsigned
On Fri, Nov 25, 2011 at 02:15:12PM +0100, Joerg Sonnenberger wrote:
> > Sure it does. You should just have written the code using (size_t)1,
> > or even just 1UL, instead of 1ULL. There is no port where size_t is
> > unsigned long long.
> >
> > ... Unless what you meant was "get rid of all 32
On Fri, Nov 25, 2011 at 12:57:29PM +, David Holland wrote:
> On Fri, Nov 25, 2011 at 01:01:34PM +0100, Joerg Sonnenberger wrote:
> > > Log Message:
> > > Add explicit casts to make lint happy and fix the NetBSD/i386 build.
> >
> > Can we please just get rid of this PoS? This doesn't even q
On Fri, Nov 25, 2011 at 01:01:34PM +0100, Joerg Sonnenberger wrote:
> > Log Message:
> > Add explicit casts to make lint happy and fix the NetBSD/i386 build.
>
> Can we please just get rid of this PoS? This doesn't even qualify as bad
> signal to noise ratio.
Sure it does. You should just ha
On Fri, Nov 25, 2011 at 09:00:51AM +, Matthias Scheler wrote:
> Module Name: src
> Committed By: tron
> Date: Fri Nov 25 09:00:51 UTC 2011
>
> Modified Files:
> src/lib/libc/string: wcscspn_bloom.h
>
> Log Message:
> Add explicit casts to make lint happy and fix the NetBSD/i386
Am 24.11.11 19:44, schrieb Joerg Sonnenberger:
> Module Name: src
> Committed By: joerg
> Date: Thu Nov 24 18:44:25 UTC 2011
>
> Modified Files:
> src/lib/libc/string: wcscspn.c wcspbrk.c
> Added Files:
> src/lib/libc/string: wcscspn_bloom.h
This breaks the build on i386, at
On Mon, Apr 19, 2010 at 03:02:05AM +, Christos Zoulas wrote:
> In article <20100419021334.ga8...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
> >On Sun, Apr 18, 2010 at 10:51:35AM +, Alan Barrett wrote:
> >> Log Message:
> >> Bitwise operations on signed types are well-defined if the v
On Mon, 19 Apr 2010, Joerg Sonnenberger wrote:
> On Sun, Apr 18, 2010 at 10:51:35AM +, Alan Barrett wrote:
> > Log Message:
> > Bitwise operations on signed types are well-defined if the values
> > happen to be positive, and indeed the values here were guaranteed
> > to be positive, but some co
On Mon, Apr 19, 2010 at 03:02:05AM +, Christos Zoulas wrote:
>> In that case use an explicit cast to the unsigned type. What you did is
>> penalize the code for no good reason.
>
> Any compiler these days knows how to do these micro-optimizations.
Furthermore, as swab() is fairly useless,
In article <20100419021334.ga8...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Sun, Apr 18, 2010 at 10:51:35AM +, Alan Barrett wrote:
>> Log Message:
>> Bitwise operations on signed types are well-defined if the values
>> happen to be positive, and indeed the values here were guaranteed
On Sun, Apr 18, 2010 at 10:51:35AM +, Alan Barrett wrote:
> Log Message:
> Bitwise operations on signed types are well-defined if the values
> happen to be positive, and indeed the values here were guaranteed
> to be positive, but some compilers complained anyway, so convert
> the bitwise opera
On Apr 18, 11:01am, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/lib/libc/string
| On Sat, Apr 17, 2010 at 09:14:21PM -0400, Christos Zoulas wrote:
| > Yes, it does not make sense, but that is what POSIX specifies.
|
| Yeah, but wouldn't ignoring this part
On Sat, Apr 17, 2010 at 09:14:21PM -0400, Christos Zoulas wrote:
> Yes, it does not make sense, but that is what POSIX specifies.
Yeah, but wouldn't ignoring this part (keeping it size_t) still work
for all valid calls, i.e. differing from the obviously stupid standard
be a harmless thing?
Martin
On Apr 17, 11:25pm, mar...@netbsd.org (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/lib/libc/string
| On Sat, Apr 17, 2010 at 01:57:39PM -0400, Christos Zoulas wrote:
| > Module Name:src
| > Committed By: christos
| > Date: Sat Apr 17 17:57:39
On Sat, Apr 17, 2010 at 01:57:39PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Apr 17 17:57:39 UTC 2010
>
> Modified Files:
> src/lib/libc/string: swab.3 swab.c
>
> Log Message:
> Change and document for POSIX compliance.
The restrict part
On Wed, Aug 05, 2009 at 04:08:00PM +, Joerg Sonnenberger wrote:
> Module Name: src
> Committed By: joerg
> Date: Wed Aug 5 16:08:00 UTC 2009
>
> Modified Files:
> src/lib/libc/string: Lint_ffs.c
I'm not sure why we have these Lint_xxx.c stubs for functions where
we have a real
On Thu, Jul 30, 2009 at 09:46:44PM -0400, Perry E. Metzger wrote:
>
> David Laight writes:
> > Module Name:src
> > Committed By: dsl
> > Date: Thu Jul 30 21:42:06 UTC 2009
> >
> > Modified Files:
> > src/lib/libc/string: strcspn.c strspn.c
> >
> > Log Message:
> >
David Laight writes:
> Module Name: src
> Committed By: dsl
> Date: Thu Jul 30 21:42:06 UTC 2009
>
> Modified Files:
> src/lib/libc/string: strcspn.c strspn.c
>
> Log Message:
> Use a 'register only' str[c]spn() on 64 bit systems.
How much of a speedup is this?
Also, you have a s
In article
<20090410232748.gs25357__19460.5905832306$1239406176$gmane$...@danbala.tuwien.ac.at>,
Thomas Klausner wrote:
>On Fri, Apr 10, 2009 at 07:13:38PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Fri Apr 10 23:13:38 UTC 2009
>>
Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Apr 10 23:13:38 UTC 2009
>
> Modified Files:
> src/lib/libc/string: Makefile.inc memchr.3
> Added Files:
> src/lib/libc/string: memrchr.c
>
> Log Message:
> add memrchr
why not the 2-clause licens
On Fri, Apr 10, 2009 at 07:13:38PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Apr 10 23:13:38 UTC 2009
>
> Modified Files:
> src/lib/libc/string: Makefile.inc memchr.3
> Added Files:
> src/lib/libc/string: memrchr.c
>
> Log Message:
38 matches
Mail list logo
