re: CVS commit: src/lib/libc/stdlib

> Minor changes to jemalloc100 (the old one that only vax etc currently uses). thanks. i'm still using this version on a bunch of modern machines. new jemalloc was problematic for a few things for me a number of years ago and i keep meaning to test again, but for now i'm still mostly using this

Re: CVS commit: src/lib/libc/stdlib

Date:Thu, 29 Sep 2022 08:18:49 -0400 From:Christos Zoulas Message-ID: | Yes, I had forgotten about the need to do this explicitly... | > On Sep 28, 2022, at 10:23 PM, Robert Elz wrote: | > | > Apologies, I did not read the code closely enough, there must

Re: CVS commit: src/lib/libc/stdlib

Yes, I had forgotten about the need to do this explicitly... christos > On Sep 28, 2022, at 10:23 PM, Robert Elz wrote: > > Apologies, I did not read the code closely enough, there must be a bug > in the way the clone file descriptor is created. > > kre signature.asc Description: Message

Re: CVS commit: src/lib/libc/stdlib

Apologies, I did not read the code closely enough, there must be a bug in the way the clone file descriptor is created. kre

Re: CVS commit: src/lib/libc/stdlib

Date:Wed, 28 Sep 2022 20:48:53 -0400 From:"David H. Gutteridge" Message-ID: <9c9c8e9d9384338320b47dabfdc94...@gutteridge.ca> | (O_CLOEXEC, on the other hand, is ignored, at the moment.) No it isn't, your test is faulty, O_CLOEXEC is a different kind of flag,

Re: CVS commit: src/lib/libc/stdlib

On Wed, 28 Sep 2022, at 15:07:41 - (UTC), Christos Zoulas wrote: In article <20220928003547.D2375FA92%cvs.NetBSD.org@localhost>, David H. Gutteridge wrote: -=-=-=-=-=- Module Name:src Committed By: gutteridge Date: Wed Sep 28 00:35:47 UTC 2022 Modified Files:

Re: CVS commit: src/lib/libc/stdlib

In article <20220928003547.d2375f...@cvs.netbsd.org>, David H. Gutteridge wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: gutteridge >Date: Wed Sep 28 00:35:47 UTC 2022 > >Modified Files: > src/lib/libc/stdlib: posix_openpt.3 > >Log Message: >posix_openpt.3: reflect flag

Re: CVS commit: src/lib/libc/stdlib

On Sat, 12 Mar 2022 08:26:01 + Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Sat Mar 12 08:26:01 UTC 2022 > > Modified Files: > src/lib/libc/stdlib: hcreate.c > > Log Message: > hcreate(3): use reallocarr instead of malloc(x * y) Caution: malloc(0) and

Re: CVS commit: src/lib/libc/stdlib

On Sat, Feb 12, 2022, 11:52 AM Taylor R Campbell < campbell+netbsd-source-change...@mumble.net> wrote: > > Date: Sun, 13 Feb 2022 05:44:38 +1100 > > from: matthew green > > > > "Roland Illig" writes: > > > Module Name:src > > > Committed By: rillig > > > Date: Fri Feb

Re: CVS commit: src/lib/libc/stdlib

Am 12.02.2022 um 20:10 schrieb Warner Losh: I thought the rule was don't make purely whitespace changes UNLESS you plan on making other changes to (or are fixing an oops you just made). If that's the case, separate the two commits. That sounds like a useful rule, I'll stick to it. Roland

Re: CVS commit: src/lib/libc/stdlib

> Date: Sun, 13 Feb 2022 05:44:38 +1100 > from: matthew green > > "Roland Illig" writes: > > Module Name:src > > Committed By: rillig > > Date: Fri Feb 11 21:36:46 UTC 2022 > > > > Modified Files: > > src/lib/libc/stdlib: getenv.c > > > > Log Message: > >

re: CVS commit: src/lib/libc/stdlib

"Roland Illig" writes: > Module Name: src > Committed By: rillig > Date: Fri Feb 11 21:36:46 UTC 2022 > > Modified Files: > src/lib/libc/stdlib: getenv.c > > Log Message: > libc/getenv: remove trailing whitespace > > No binary change. please avoid purely whitespace changes unless

Re: CVS commit: src/lib/libc/stdlib

On Sun, Feb 23, 2020 at 10:57:28 +0100, Kamil Rytarowski wrote: > On 23.02.2020 08:46, Martin Husemann wrote: > > > Source code consistency is a very important stylistic plus, every break of > > that should be accompanied by a comment. > > Done. Thank you. -uwe

Re: CVS commit: src/lib/libc/stdlib

On 23.02.2020 08:46, Martin Husemann wrote: > On Sun, Feb 23, 2020 at 03:35:19AM +0100, Kamil Rytarowski wrote: >> Algorithm would be changed from calculating on 32bit numbers with signed >> integer overflows to an algorithm calculating on 64bit numbers. The >> __dorand48() function truncates the

Re: CVS commit: src/lib/libc/stdlib

On Sun, Feb 23, 2020 at 03:35:19AM +0100, Kamil Rytarowski wrote: > Algorithm would be changed from calculating on 32bit numbers with signed > integer overflows to an algorithm calculating on 64bit numbers. The > __dorand48() function truncates the result to least significant 16bits > only so it

Re: CVS commit: src/lib/libc/stdlib

On Sun, Feb 23, 2020 at 03:35:19 +0100, Kamil Rytarowski wrote: > On 23.02.2020 03:20, Valery Ushakov wrote: > > On Sun, Feb 23, 2020 at 02:51:49 +0100, Kamil Rytarowski wrote: > > > >> On 23.02.2020 02:29, Valery Ushakov wrote: > >>> On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski

Re: CVS commit: src/lib/libc/stdlib

On 23.02.2020 03:20, Valery Ushakov wrote: > On Sun, Feb 23, 2020 at 02:51:49 +0100, Kamil Rytarowski wrote: > >> On 23.02.2020 02:29, Valery Ushakov wrote: >>> On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote: >>> Module Name: src Committed By: kamil Date:

Re: CVS commit: src/lib/libc/stdlib

On Sun, Feb 23, 2020 at 02:51:49 +0100, Kamil Rytarowski wrote: > On 23.02.2020 02:29, Valery Ushakov wrote: > > On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote: > > > >> Module Name: src > >> Committed By: kamil > >> Date: Sat Feb 22 14:07:57 UTC 2020 > >>

Re: CVS commit: src/lib/libc/stdlib

On 23.02.2020 02:29, Valery Ushakov wrote: > On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote: > >> Module Name: src >> Committed By:kamil >> Date:Sat Feb 22 14:07:57 UTC 2020 >> >> Modified Files: >> src/lib/libc/stdlib: _rand48.c >> >> Log Message: >>

Re: CVS commit: src/lib/libc/stdlib

On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Sat Feb 22 14:07:57 UTC 2020 > > Modified Files: > src/lib/libc/stdlib: _rand48.c > > Log Message: > Avoid undefined behavior in the rand48(3) implementation > >

Re: CVS commit: src/lib/libc/stdlib

On Thu, Nov 02, 2017 at 08:26:58PM +0100, Kamil Rytarowski wrote: > On 02.11.2017 20:15, Joerg Sonnenberger wrote: > > On Thu, Nov 02, 2017 at 08:15:01PM +0100, Joerg Sonnenberger wrote: > >> On Thu, Nov 02, 2017 at 06:37:15PM +, Kamil Rytarowski wrote: > >>> Module Name: src > >>>

Re: CVS commit: src/lib/libc/stdlib

On 02.11.2017 20:15, Joerg Sonnenberger wrote: > On Thu, Nov 02, 2017 at 08:15:01PM +0100, Joerg Sonnenberger wrote: >> On Thu, Nov 02, 2017 at 06:37:15PM +, Kamil Rytarowski wrote: >>> Module Name:src >>> Committed By: kamil >>> Date: Thu Nov 2 18:37:15 UTC 2017

Re: CVS commit: src/lib/libc/stdlib

On Thu, Nov 02, 2017 at 08:15:01PM +0100, Joerg Sonnenberger wrote: > On Thu, Nov 02, 2017 at 06:37:15PM +, Kamil Rytarowski wrote: > > Module Name:src > > Committed By: kamil > > Date: Thu Nov 2 18:37:15 UTC 2017 > > > > Modified Files: > >

Re: CVS commit: src/lib/libc/stdlib

On Thu, Nov 02, 2017 at 06:37:15PM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Thu Nov 2 18:37:15 UTC 2017 > > Modified Files: > src/lib/libc/stdlib: atexit.c > > Log Message: > Correct handling of __cxa_atexit(a,b,NULL) in libc I don't get

Re: CVS commit: src/lib/libc/stdlib

In article <20170112213155.ga11...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Wed, Jan 11, 2017 at 09:00:42PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Thu Jan 12 02:00:42 UTC 2017 >> >> Modified Files: >>

Re: CVS commit: src/lib/libc/stdlib

On Wed, Jan 11, 2017 at 09:00:42PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Thu Jan 12 02:00:42 UTC 2017 > > Modified Files: > src/lib/libc/stdlib: malloc.c > > Log Message: > Avoid sysconf: __sysconf -> sysctlgetmibinfo -> strtoimax ->

Re: CVS commit: src/lib/libc/stdlib

On Sun, Aug 16, 2015 at 11:07:24PM +0200, Kamil Rytarowski wrote: What do you think about the following patch: No. In 90. division was an expensive operation, today not any more. I would prefer to let it to be optimized by a compiler, not by a human for a special or an old hardware with

Re: CVS commit: src/lib/libc/stdlib

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09.08.2015 15:29, Joerg Sonnenberger wrote: On Tue, Jul 28, 2015 at 05:13:34PM +, Kamil Rytarowski wrote: Module Name: src Committed By: kamil Date: Tue Jul 28 17:13:34 UTC 2015 Modified Files: src/lib/libc/stdlib:

Re: CVS commit: src/lib/libc/stdlib

On Tue, Jul 28, 2015 at 05:13:34PM +, Kamil Rytarowski wrote: Module Name: src Committed By: kamil Date: Tue Jul 28 17:13:34 UTC 2015 Modified Files: src/lib/libc/stdlib: reallocarr.3 reallocarr.c Log Message: Compatibility fixes in reallocarr(3) Except it is worse

Re: CVS commit: src/lib/libc/stdlib

On Sun, Jul 19, 2015 at 11:13:48PM +0200, Kamil Rytarowski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19.07.2015 20:56, Joerg Sonnenberger wrote: On Thu, Jul 16, 2015 at 12:12:27PM +0200, Kamil Rytarowski wrote: The C standard permits memcpy(3) to affect errno(2). More

Re: CVS commit: src/lib/libc/stdlib

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19.07.2015 20:56, Joerg Sonnenberger wrote: On Thu, Jul 16, 2015 at 12:12:27PM +0200, Kamil Rytarowski wrote: The C standard permits memcpy(3) to affect errno(2). More like it hasn't explicitly ruled it out. That might or might not be seen

Re: CVS commit: src/lib/libc/stdlib

On Thu, Jul 16, 2015 at 12:12:27PM +0200, Kamil Rytarowski wrote: The C standard permits memcpy(3) to affect errno(2). More like it hasn't explicitly ruled it out. That might or might not be seen as an oversight, but pretty much any compiler uses memcpy(3) under the assumption that it does not.

Re: CVS commit: src/lib/libc/stdlib

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16.07.2015 10:25, Pierre Pronchery wrote: Hi, On 07/16/15 02:04, Kamil Rytarowski wrote: Module Name: src Committed By: kamil Date: Thu Jul 16 00:04:00 UTC 2015 Modified Files: src/lib/libc/stdlib: reallocarr.c Log

Re: CVS commit: src/lib/libc/stdlib

Hi, On 07/16/15 02:04, Kamil Rytarowski wrote: Module Name: src Committed By: kamil Date: Thu Jul 16 00:04:00 UTC 2015 Modified Files: src/lib/libc/stdlib: reallocarr.c Log Message: Reorder memcpy(3) and save errno This chang is for safety as

Re: CVS commit: src/lib/libc/stdlib

Module Name: src Committed By: christos Date: Wed Jan 8 02:15:42 UTC 2014 Modified Files: src/lib/libc/stdlib: Makefile.inc ptsname.3 pty.c Log Message: add ptsname_r Needs libc minor bump? --- Izumi Tsutsui

Re: CVS commit: src/lib/libc/stdlib

On Jan 8, 7:25pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/lib/libc/stdlib | Module Name:src | Committed By: christos | Date: Wed Jan 8 02:15:42 UTC 2014 | | Modified Files: | src/lib/libc/stdlib: Makefile.inc ptsname

Re: CVS commit: src/lib/libc/stdlib

| Module Name: src | Committed By: christos | Date: Wed Jan 8 02:15:42 UTC 2014 | | Modified Files: |src/lib/libc/stdlib: Makefile.inc ptsname.3 pty.c | | Log Message: | add ptsname_r | | Needs libc minor bump? I thought about it, but really

re: CVS commit: src/lib/libc/stdlib

| Module Name: src | Committed By: christos | Date: Wed Jan 8 02:15:42 UTC 2014 | | Modified Files: |src/lib/libc/stdlib: Makefile.inc ptsname.3 pty.c | | Log Message: | add ptsname_r | | Needs libc minor bump? I thought about it, but really

Re: CVS commit: src/lib/libc/stdlib

On Jan 8, 8:52pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/lib/libc/stdlib | Then why do you add it if it will be never used? It will be never used != is not currently being used. I was reading the linux man page and it seemed easy to implement. christos

Re: CVS commit: src/lib/libc/stdlib

On Jan 8, 8:52pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/lib/libc/stdlib | Then why do you add it if it will be never used? It will be never used != is not currently being used. Then you must bump minor otherwise future binaries will fail silently

Re: CVS commit: src/lib/libc/stdlib

On Tue, 20 Mar 2012, Christos Zoulas wrote: Modified Files: src/lib/libc/stdlib: jemalloc.c -static char*umax2s(uintmax_t x, char *s); +static char*umax2s(size_t x, char *s); If you change the argument type, then please also change the function name. Right now, the name

Re: CVS commit: src/lib/libc/stdlib

On May 17, 11:57am, tsugutomo.en...@jp.sony.com (tsugutomo.en...@jp.sony.com) wrote: -- Subject: Re: CVS commit: src/lib/libc/stdlib | Christos Zoulas chris...@netbsd.org writes: | | Module Name:src | Committed By: christos | Date: Fri May 13 23:11:00 UTC 2011

Re: CVS commit: src/lib/libc/stdlib

In article tkrr57yc9uf@gco-w12f-177-176.sm.sony.co.jp, tsugutomo.en...@jp.sony.com wrote: Christos Zoulas chris...@netbsd.org writes: Module Name: src Committed By:christos Date:Fri May 13 23:11:00 UTC 2011 Modified Files: src/lib/libc/stdlib: jemalloc.c

Re: CVS commit: src/lib/libc/stdlib

Christos Zoulas chris...@netbsd.org writes: Module Name: src Committed By: christos Date: Fri May 13 23:11:00 UTC 2011 Modified Files: src/lib/libc/stdlib: jemalloc.c malloc.c Log Message: don't let readlink trash errno.; To generate a diff of this commit: cvs rdiff -u

Re: CVS commit: src/lib/libc/stdlib

On Mon, 01 Nov 2010, enami tsugutomo wrote: Modified Files: src/lib/libc/stdlib: getenv.c Log Message: Double the array only when really necessary. Otherwise memory will be exhausted if user modifies the variable envrion itself repeatedly.. Now the code disagrees with the comment

Re: CVS commit: src/lib/libc/stdlib

Now the code disagrees with the comment above it. Please fix the comment. I've changed the comment but feel free to improve it if you have better one. enami.

Re: CVS commit: src/lib/libc/stdlib

On Thu, Sep 30, 2010 at 03:05:26PM +0200, Nicolas Joly wrote: One possibility could be to not free memory at all in setenv, but only with unsetenv. I'm not convinced about that. IMHO, it's a programmer error to call setenv more than once on the same variable without a corresponding unsetenv

Re: CVS commit: src/lib/libc/stdlib

On Thu, Sep 30, 2010 at 02:11:19PM +0100, Matthias Scheler wrote: On Thu, Sep 30, 2010 at 03:05:26PM +0200, Nicolas Joly wrote: One possibility could be to not free memory at all in setenv, but only with unsetenv. I'm not convinced about that. IMHO, it's a programmer error to call

Re: CVS commit: src/lib/libc/stdlib

On Thu, Sep 30, 2010 at 03:35:41PM +0200, Nicolas Joly wrote: That may be part of the problem (at least for zsh 4.2). http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html From the OpenGroup function description; this function does not copy the provided string, but use it

Re: CVS commit: src/lib/libc/stdlib

On Thu, Sep 30, 2010 at 12:41:34PM +, Matthias Scheler wrote: Module Name: src Committed By: tron Date: Thu Sep 30 12:41:33 UTC 2010 Modified Files: src/lib/libc/stdlib: setenv.c unsetenv.c Log Message: Be slightly more careful about freeing memory allocated for

Re: CVS commit: src/lib/libc/stdlib

In article 20100930134213.ga18...@colwyn.zhadum.org.uk, Matthias Scheler t...@netbsd.org wrote: On Thu, Sep 30, 2010 at 03:35:41PM +0200, Nicolas Joly wrote: That may be part of the problem (at least for zsh 4.2). http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html From the

Re: CVS commit: src/lib/libc/stdlib

On Thu, Sep 23, 2010 at 12:02:42PM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Thu Sep 23 16:02:41 UTC 2010 Modified Files: src/lib/libc/stdlib: setenv.c Log Message: PR/43899: Nicolas Joly: setenv(3)/unsetenv(3) memory leak. Partial fix:

Re: CVS commit: src/lib/libc/stdlib

In addition to previous, __allocenv() call in unsetenv() isn't necessary if we check if there exists the bitmap before touching it. If still want to call it, it must be protected by the lock. enami.

Re: CVS commit: src/lib/libc/stdlib

Module Name: src Committed By: christos Date: Thu Sep 23 16:02:41 UTC 2010 Modified Files: src/lib/libc/stdlib: setenv.c Log Message: PR/43899: Nicolas Joly: setenv(3)/unsetenv(3) memory leak. Partial fix: Don't allocate a new string if the length is equal to the old