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 do
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 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 wrote:
>>>
Module Name: src
Committed By: kamil
Date:
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
> >>
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:
>> A
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
>
> Inste
Module Name:src
Committed By: sevan
Date: Sun Sep 1 19:37:21 UTC 2019
Modified Files:
src/lib/libc/stdlib: exit.3
Log Message:
Document history
https://www.bell-labs.com/usr/dmr/www/man21.pdf
To generate a diff of this commit:
cvs rdiff -u -r1.16 -r1.17 src/lib/libc/std
Module Name:src
Committed By: sevan
Date: Sun Sep 1 19:37:21 UTC 2019
Modified Files:
src/lib/libc/stdlib: exit.3
Log Message:
Document history
https://www.bell-labs.com/usr/dmr/www/man21.pdf
To generate a diff of this commit:
cvs rdiff -u -r1.16 -r1.17 src/lib/libc/std
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
> >>> Committ
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
>>
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:
> > 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 it.
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:
>> src/lib/libc/
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 -> loca
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 e
-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
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
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).
>
-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
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.
-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: realloc
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 s
> 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
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
> | > 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 abou
> | > 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
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/st
> 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
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 conta
In article ,
wrote:
>Christos Zoulas 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 gener
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 writes:
|
| > Module Name:src
| > Committed By: christos
| > Date: Fri May 13 23:11:00 UTC 2011
| >
Christos Zoulas 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 -r1.22
> 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.
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 comme
In article <20100930134213.ga18...@colwyn.zhadum.org.uk>,
Matthias Scheler 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 O
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 f
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
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
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 unsete
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.
> Part
On Sep 24, 12:57pm, tsugutomo.en...@jp.sony.com (enami tsugutomo) wrote:
-- Subject: Re: CVS commit: src/lib/libc/stdlib
| Actual change done in setenv.c rev. 1.33 causes following program
| memory leak (while rev. 1.32 does not).
|
| #include
|
| main
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.
> 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 th
Module Name:src
Committed By: enami
Date: Thu Mar 4 22:48:31 UTC 2010
Modified Files:
src/lib/libc/stdlib: jemalloc.c
Log Message:
Fix race condition on reallocation of huge category.
We need to remove the old region before mremap() since if it relesae the
old region, ot
Module Name:src
Committed By: enami
Date: Thu Mar 4 22:48:31 UTC 2010
Modified Files:
src/lib/libc/stdlib: jemalloc.c
Log Message:
Fix race condition on reallocation of huge category.
We need to remove the old region before mremap() since if it relesae the
old region, ot
Module Name:src
Committed By: roy
Date: Thu Feb 4 10:27:08 UTC 2010
Modified Files:
src/lib/libc/stdlib: mi_vector_hash.c
Log Message:
Include nbtool_config.h as we need to be part of the terminfo toolchain.
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 sr
101 - 146 of 146 matches
Mail list logo
