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

2020-02-23 Thread Valery Ushakov
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

2020-02-23 Thread Kamil Rytarowski
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 result to least significant 16bits
>> only so it does not matter. I retained operations on 32bits avoiding
>> changes of types for stylistic reasons.
> 
> I am with uwe here - either it would not make any difference at all (on
> 32bit architectures) or it would end up with the same results and would
> make no performance difference (on 64 bit architectures), so going with
> the consistent (unsigned long) would have been fine.
> 
> Even better would be a cleanup to make it (uint32_t) everwhere, but of
> course only after carefull examination.
> 
> Source code consistency is a very important stylistic plus, every break of
> that should be accompanied by a comment.
> 
> Martin
> 

Done.



signature.asc
Description: OpenPGP digital signature


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

2020-02-22 Thread Martin Husemann
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 does not matter. I retained operations on 32bits avoiding
> changes of types for stylistic reasons.

I am with uwe here - either it would not make any difference at all (on
32bit architectures) or it would end up with the same results and would
make no performance difference (on 64 bit architectures), so going with
the consistent (unsigned long) would have been fine.

Even better would be a cleanup to make it (uint32_t) everwhere, but of
course only after carefull examination.

Source code consistency is a very important stylistic plus, every break of
that should be accompanied by a comment.

Martin


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

2020-02-22 Thread Valery Ushakov
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:
> >>>
>  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
> 
>  Instead of implicid promotion to signed int,
>  explicitly cast the arguments to unsigned int.
> >>>
> >>> Please, please, please, pay at least some attention to what is going
> >>> on around the code you are changing.
> >>>
> >>> If there's already code in this function that does:
> >>>
> >>>accu = (unsigned long) __rand48_mult[0] * (unsigned long) xseed[0];
> >>>
> >>> then keep it consistent and don't do casts to a different type
> >>>
> >>>accu += (unsigned int) __rand48_mult[0] * (unsigned int) xseed[2];
> >>
> >> cast to unsigned long still works, but changes algorithm. My change was
> >> performed deliberately. On the other hand and according to local tests
> >> the end-result for unsigned long produces the same reults as cast to
> >> unsigned int and unsigned char so it does not matter.
> > 
> > I cannot make sense of your answer.  Does the cast to unsigned long
> > there change the algorithm or does it produce the same result?  If it
> > produces the same result, then it should be used to be consistent with
> > the rest of the code (or the rest of the code changed to use unsigned
> > int).  If it does change the result, there should be a comment
> > explaining it.
> 
> 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 does not matter. I retained operations on 32bits avoiding
> changes of types for stylistic reasons.

That still doesn't make sense to me.  You took your time to figure out
whats going on in this bit of code.  Then you make a change that looks
extremely unobvious b/c it is inconsistent with the rest of the code,
and you say you did this for stylistic reasons.

The next person looking at that code (in $bignum years) will have to
waste their time puzzling out the reason.  Why not use the knowledge
you've gained of this code for good and change the code properly?  The
90s unsigned long was probably meant to be 32-bit anyway (cf. X11 mess
up with using long for 32 bit quantities in the protocol and then
running into issues when 64-bit happened).  So if doing things in
32-bit here is the right and intended thing to do, then change that
unsigned long to uint32_t.  If you don't want to dive that deep (which
is entirely understandable), then, exactly for stylistic reasons, cast
to unsigned long to be consistent with the old code - as you already
established that it didn't change the result.

-uwe


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

2020-02-22 Thread Kamil Rytarowski
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:  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

 Instead of implicid promotion to signed int,
 explicitly cast the arguments to unsigned int.
>>>
>>> Please, please, please, pay at least some attention to what is going
>>> on around the code you are changing.
>>>
>>> If there's already code in this function that does:
>>>
>>>accu = (unsigned long) __rand48_mult[0] * (unsigned long) xseed[0];
>>>
>>> then keep it consistent and don't do casts to a different type
>>>
>>>accu += (unsigned int) __rand48_mult[0] * (unsigned int) xseed[2];
>>
>> cast to unsigned long still works, but changes algorithm. My change was
>> performed deliberately. On the other hand and according to local tests
>> the end-result for unsigned long produces the same reults as cast to
>> unsigned int and unsigned char so it does not matter.
> 
> I cannot make sense of your answer.  Does the cast to unsigned long
> there change the algorithm or does it produce the same result?  If it
> produces the same result, then it should be used to be consistent with
> the rest of the code (or the rest of the code changed to use unsigned
> int).  If it does change the result, there should be a comment
> explaining it.
> 
> -uwe
> 

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 does not matter. I retained operations on 32bits avoiding
changes of types for stylistic reasons.



signature.asc
Description: OpenPGP digital signature


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

2020-02-22 Thread Valery Ushakov
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
> >>
> >> Modified Files:
> >>src/lib/libc/stdlib: _rand48.c
> >>
> >> Log Message:
> >> Avoid undefined behavior in the rand48(3) implementation
> >>
> >> Instead of implicid promotion to signed int,
> >> explicitly cast the arguments to unsigned int.
> > 
> > Please, please, please, pay at least some attention to what is going
> > on around the code you are changing.
> > 
> > If there's already code in this function that does:
> > 
> >accu = (unsigned long) __rand48_mult[0] * (unsigned long) xseed[0];
> > 
> > then keep it consistent and don't do casts to a different type
> > 
> >accu += (unsigned int) __rand48_mult[0] * (unsigned int) xseed[2];
> 
> cast to unsigned long still works, but changes algorithm. My change was
> performed deliberately. On the other hand and according to local tests
> the end-result for unsigned long produces the same reults as cast to
> unsigned int and unsigned char so it does not matter.

I cannot make sense of your answer.  Does the cast to unsigned long
there change the algorithm or does it produce the same result?  If it
produces the same result, then it should be used to be consistent with
the rest of the code (or the rest of the code changed to use unsigned
int).  If it does change the result, there should be a comment
explaining it.

-uwe


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

2020-02-22 Thread Kamil Rytarowski
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:
>> Avoid undefined behavior in the rand48(3) implementation
>>
>> Instead of implicid promotion to signed int,
>> explicitly cast the arguments to unsigned int.
> 
> Please, please, please, pay at least some attention to what is going
> on around the code you are changing.
> 
> If there's already code in this function that does:
> 
>accu = (unsigned long) __rand48_mult[0] * (unsigned long) xseed[0];
> 
> then keep it consistent and don't do casts to a different type
> 
>accu += (unsigned int) __rand48_mult[0] * (unsigned int) xseed[2];
> 
> 
> -uwe
> 

cast to unsigned long still works, but changes algorithm. My change was
performed deliberately. On the other hand and according to local tests
the end-result for unsigned long produces the same reults as cast to
unsigned int and unsigned char so it does not matter.



signature.asc
Description: OpenPGP digital signature


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

2020-02-22 Thread Valery Ushakov
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
> 
> Instead of implicid promotion to signed int,
> explicitly cast the arguments to unsigned int.

Please, please, please, pay at least some attention to what is going
on around the code you are changing.

If there's already code in this function that does:

   accu = (unsigned long) __rand48_mult[0] * (unsigned long) xseed[0];

then keep it consistent and don't do casts to a different type

   accu += (unsigned int) __rand48_mult[0] * (unsigned int) xseed[2];


-uwe


CVS commit: src/lib/libc/stdlib

2019-09-01 Thread Sevan Janiyan
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/stdlib/exit.3

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/lib/libc/stdlib/exit.3
diff -u src/lib/libc/stdlib/exit.3:1.16 src/lib/libc/stdlib/exit.3:1.17
--- src/lib/libc/stdlib/exit.3:1.16	Fri Apr 26 18:29:55 2013
+++ src/lib/libc/stdlib/exit.3	Sun Sep  1 19:37:21 2019
@@ -1,4 +1,4 @@
-.\" $NetBSD: exit.3,v 1.16 2013/04/26 18:29:55 christos Exp $
+.\" $NetBSD: exit.3,v 1.17 2019/09/01 19:37:21 sevan Exp $
 .\"
 .\" Copyright (c) 1990, 1991, 1993
 .\"	The Regents of the University of California.  All rights reserved.
@@ -33,7 +33,7 @@
 .\"
 .\" from: @(#)exit.3	8.1 (Berkeley) 6/4/93
 .\"
-.Dd January 2, 2012
+.Dd September 1, 2019
 .Dt EXIT 3
 .Os
 .Sh NAME
@@ -109,3 +109,8 @@ The
 function
 conforms to
 .St -ansiC .
+.Sh HISTORY
+The
+.Fn exit
+function appeared in
+.At v1 .



CVS commit: src/lib/libc/stdlib

2019-09-01 Thread Sevan Janiyan
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/stdlib/exit.3

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



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

2017-11-02 Thread Joerg Sonnenberger
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
> >>> 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. This seems to be quite wrong.
> >>
> >>> Correct a bug that __cxa_atexit(x,y,NULL) is handled in the same way as
> >>> atexit(x) (which is simplified to __cxa_atexit(x,NULL,NULL).
> >>
> >> __cxa_atexit(x,y,NULL) is not invalid. Please revert this.
> > 
> > ...is invalid, of course.
> > 
> > Joerg
> > 
> 
> What's the rationale for being wrong?

The DSO handle is a required part of the (external) __cxa_atexit interface.
The atexit mapping is an implementation detail and not part of the public
interface. Doing it directly creates UB as it involves casting function
pointers between incompatible types.

Joerg


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

2017-11-02 Thread Kamil Rytarowski
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
>>>
>>> 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. This seems to be quite wrong.
>>
>>> Correct a bug that __cxa_atexit(x,y,NULL) is handled in the same way as
>>> atexit(x) (which is simplified to __cxa_atexit(x,NULL,NULL).
>>
>> __cxa_atexit(x,y,NULL) is not invalid. Please revert this.
> 
> ...is invalid, of course.
> 
> Joerg
> 

What's the rationale for being wrong?



signature.asc
Description: OpenPGP digital signature


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

2017-11-02 Thread Joerg Sonnenberger
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: atexit.c
> > 
> > Log Message:
> > Correct handling of __cxa_atexit(a,b,NULL) in libc
> 
> I don't get it. This seems to be quite wrong.
> 
> > Correct a bug that __cxa_atexit(x,y,NULL) is handled in the same way as
> > atexit(x) (which is simplified to __cxa_atexit(x,NULL,NULL).
> 
> __cxa_atexit(x,y,NULL) is not invalid. Please revert this.

...is invalid, of course.

Joerg


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

2017-11-02 Thread Joerg Sonnenberger
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. This seems to be quite wrong.

> Correct a bug that __cxa_atexit(x,y,NULL) is handled in the same way as
> atexit(x) (which is simplified to __cxa_atexit(x,NULL,NULL).

__cxa_atexit(x,y,NULL) is not invalid. Please revert this.

Joerg


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

2017-01-12 Thread Christos Zoulas
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/stdlib: malloc.c
>> 
>> Log Message:
>> Avoid sysconf: __sysconf -> sysctlgetmibinfo -> strtoimax -> locale, etc.
>
>Can you at least use sysctl(2) directly?

I could... Ok.

christos



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

2017-01-12 Thread Joerg Sonnenberger
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 -> locale, etc.

Can you at least use sysctl(2) directly?

Joerg


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

2015-08-17 Thread Joerg Sonnenberger
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 expensive arithmetic operations.

That's plainly wrong. A division is still slow and horribly slow on
quite a few CPUs we care about.

Joerg


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

2015-08-16 Thread Kamil Rytarowski
-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: reallocarr.3 reallocarr.c
 
 Log Message: Compatibility fixes in reallocarr(3)
 
 Except it is worse now. There is now an obscure assumption that 
 CHAR_BITS is 8, spelled via 2 == log_2 CHAR_BITS - 1.
 


What do you think about the following patch:

Index: reallocarr.c
===
RCS file: /cvsroot/src/lib/libc/stdlib/reallocarr.c,v
retrieving revision 1.3
diff -u -r1.3 reallocarr.c
- --- reallocarr.c  28 Jul 2015 17:13:34 -  1.3
+++ reallocarr.c16 Aug 2015 20:57:06 -
@@ -50,8 +50,6 @@
 #endif
 #endif

- -#define SQRT_SIZE_MAX (1UL  (sizeof(size_t)  2))
- -
 #if !HAVE_REALLOCARR
 int
 reallocarr(void *ptr, size_t number, size_t size)
@@ -70,8 +68,7 @@
return 0;
}

- - if ((number = SQRT_SIZE_MAX || size = SQRT_SIZE_MAX) 
- - number  SIZE_MAX / size) {
+   if (number  SIZE_MAX / size) {
errno = saved_errno;
return EOVERFLOW;
}



I was benchmarking it on a modern amd64 processor and there is almost
no difference between (number = SQRT_SIZE_MAX || size =
SQRT_SIZE_MAX) vs (number  SIZE_MAX / size) for small 'number' and
small 'size'.

The reason to go for it is already prevented the 0 division with the
check in the free(3) case (number == 0 || size == 0).

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 expensive arithmetic operations.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV0PuKAAoJEEuzCOmwLnZsLmoP/3xbcc2XNXhyGmP/aZvZ9FTo
9ScYE50pV96J+UPmf5hM2kG7jUV7nIfPc3vSdP1UUi7Lg5B5gc6KKx9gCqPOn3PC
4HOcCLRRcO9R2VwNuTYSp5h1xRGgrKXt8fE5FEUA5WrMQ5+LgZ9nWQc1ZnLZFd38
Hir3o1AcjjLcLC2Xttq0CD9Uw7i1F5nUPMKfVgYo4CzYbLrTB+oXhymLOzqEcc2Q
N9aqUsFhCVphz24hH7KQX/sSbAykl6mBvv3JIGrurk6mby4UC2H26lEx+6LZw2eu
6TylkXrAmgC64Y5MhJkYnWDtKuwN09fr+zc0GsGpy4ZIEWD7rz1VCaovhLw2g7iV
u0ccHqe6ldLUzneqEKOIQJFTQU4ROM6KVhzCOrg4tTZw5MPd12ARYJz9hkdT9Nz1
clkH9+YMFZpRW9OnAze3U1APevmhP0qt7mpiWiMn8I49t+2fpMg5gt63dAyGLODw
tHK8IsCwuDp9TcvOI2iza+XhYpbBcjRoevTTciOa6xKougp62h+mCpIWrXGECKIz
Gomx3nzmIVAAVPIOoZAvwzD00n2vlVjjYEtw8fZ4q7QJueSYghhW/WSe4N6ZQDxD
OaTY0eeEOYHm9yGfy/L8sd5+jU7ehRbBHJ5MtAkFzO07HTeNmlMWtV1PV7VfAByB
e4MfvasHmIj5l7QQVyAo
=4eOR
-END PGP SIGNATURE-


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

2015-08-09 Thread Joerg Sonnenberger
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 now. There is now an obscure assumption that
CHAR_BITS is 8, spelled via 2 == log_2 CHAR_BITS - 1.

 While there: rename parameter name 'num' to 'number' to be in sync with
 the calloc(3) parameter naming.

This change doesn't even make sense.

Joerg


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

2015-07-19 Thread Joerg Sonnenberger
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 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. If you really care
  about this case, please raise a DR against ISO C and get a 
  clarification of the intention, before further changes to src.
  
 
 Thanks.
 It is also for the consistency with lines 63-64 of the same file.

...which is quite different. free(3) is quite likely to set errno for a
number of reasons and historic versions at least have been known to
actually have failure modes.

Joerg


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

2015-07-19 Thread Kamil Rytarowski
-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 as an oversight, but pretty much any compiler uses 
 memcpy(3) under the assumption that it does not. If you really care
 about this case, please raise a DR against ISO C and get a 
 clarification of the intention, before further changes to src.
 

Thanks.
It is also for the consistency with lines 63-64 of the same file.

Regards,
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVrBMIAAoJEEuzCOmwLnZsvUsQAIMgD3/aL6pld6VZ521n0+kY
zsv3axqXVO4JwoEYj0g/B4W6vuuWBzkKrSVLJm6Hf/Xjv0ZfpvWwFbT9cq3p5zuH
3uYPhjxNuPM7HTSJvLaQUCK9X0kyB1DEVlF31UOqYE5Tg6zyH9I8SWWYH9uZx/kJ
2Tc3Fl1Vx/p9veyZTsQ0tddEokC97ABTo8tLkBrr7NTimi9G0WfgEMN9fcuMjzSt
BdsnEoYI/w3JZZOcE8HhmgAIJ3osX3Ys9RVmmKJzoIyQr5Sp61hrTsPBM4bx8n55
twbFygd7Fuo/Uc8muVhBDRRBkTLogwsDUz5htP0ydYy0PpLdGeZe1q+4yVUJwxMC
vQqwFDDk4lUvfhq/Rn3RPr8otE8/W9iltihkMF7BngDyWW+mQM4MjGmgfaesR/Kc
9CoIy1zylwD+Q9FcPQFNh0zMcxxtUQ0I4TFsMTaMZ6C2FzNWkuWp5rn2kvL/Io4c
xhiGZA+czOeEZBj9CNA3fWLAzA3R3UFWk66n8de8iWeWmWgBxv4d7LnHL5J4il/u
B/Pm5thHDHTBeSwsf2nAuCady6MXivxZJLSyAodXHDpWLNgBsOXCg7cTasXnCQOL
Oqeavut0qB6HeeaaOM2YhiO/eprE7kfA1UgxyXgysaBw23LiYAbaetKJ39K4A8L6
9mL4NLMc3uEvanz5goIZ
=Mayj
-END PGP SIGNATURE-


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

2015-07-19 Thread Joerg Sonnenberger
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. If you really care about this case,
please raise a DR against ISO C and get a clarification of the
intention, before further changes to src.

Joerg


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

2015-07-16 Thread Kamil Rytarowski
-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 Message: Reorder memcpy(3) and save errno
 
 This chang is for safety as memcpy(3) might change it.
 
 I am not against the change, but are you sure memcpy(3) has any
 chance to change errno? I think it would actually be a bug if it
 does, since it is not meant to fail, and it is a pretty essential
 component for error recovery (writing messages...).
 
 This is not a definite answer but: $ find
 NetBSD/src/common/lib/libc -name memcpy.S -exec grep errno {} \+ 
 does not report anything.
 
 Anyway, HTH,
 

I will use this function outside the NetBSD world. My intention is to
push it to libnbcompat. Before that I removed the possible
thin-skinned point.

The C standard permits memcpy(3) to affect errno(2).

I'm not much interested in debate what platforms do it and whether
they are sane or not, this change just cuts this discussion down. Last
year the GCC(1) team debated the support of platforms clobbering
errno(2) in the memcpy(9) function.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

Just better to do it now then wait for timer bomb to explode.

For most of the users this change is non-functional.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVp4OIAAoJEEuzCOmwLnZstk8QALw6r4V+JDdJvi7ru4dqGWwm
5HjnM+YbmEjcbcunctZtPYXNLLl5c2KedBDaSmrZ6AJ192Xk7SCFR2jzZmQ/nO+G
xXp8yAp1bIqh/wM+FXtaeQYq7pc8z7ckvi9E7nreoife+kHC6fDuvhp9i6As5DoK
Vhqp9XaZfdCX7aWdkwlvf1gO7CpuBuvFNBD+9m80ganJ6Bwk/0Lv+hp+r2q6kQCC
9quq5GfAYwMpB0VVb2mtEVOo2wxBeFFk866lyiiZH6jf9PI8C2Igg7S2ljr463kv
p/DDgKWlY26FLkmagOaLyIGyQpni0Gw+XZg8qwAJ/H8UETls6XLLk5XPS5FbaoFc
xEgNVHYU3RxO/1eDyvtQGuKuoDfTFqIXVnsvBqhoGNBNSENwcgwc0AXcnWgbw/IY
CgIh80FUfrWvbnoxajgBGzVzOs4yjKpWcjbVrJl2tfjLCuQ/99EFptBuBBZWaquO
loqlqCO5MTWPeG3GUecUXBDZK6CJVf/Uz9II6YBSOXjTzIkGbVIev0beKMmXePEJ
KcxkStaFvVYIJ9Qbyzhd0/o03KZp2BM1tu1bIseHd1L9JNtleNLMSxb6WFDx69D2
ggmGgA9w4ySM7N/c2BEuKUurRRd4uElj2eJAnifSkaLhLg8184XK/0OFvLMVyFAJ
PUpnHTlLhZ9N7y3hn2/Z
=cZYP
-END PGP SIGNATURE-


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

2015-07-16 Thread Pierre Pronchery
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 memcpy(3) might change it.

I am not against the change, but are you sure memcpy(3) has any chance
to change errno? I think it would actually be a bug if it does, since it
is not meant to fail, and it is a pretty essential component for error
recovery (writing messages...).

This is not a definite answer but:
$ find NetBSD/src/common/lib/libc -name memcpy.S -exec grep errno {} \+
does not report anything.

Anyway, HTH,
-- 
khorben



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

2014-01-08 Thread Izumi Tsutsui
 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

2014-01-08 Thread Christos Zoulas
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.3 pty.c
|  
|  Log Message:
|  add ptsname_r
| 
| Needs libc minor bump?

I thought about it, but really ~nothing uses it.

christos


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

2014-01-08 Thread Izumi Tsutsui
 |  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 ~nothing uses it.

Then why do you add it if it will be never used?

---
Izumi Tsutsui


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

2014-01-08 Thread matthew green

 |  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 ~nothing uses it.

i don't see why this matters.  libc grew a symbol?  it needs a
minor bump.


.rg.


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

2014-01-08 Thread Christos Zoulas
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

2014-01-08 Thread Izumi Tsutsui
 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.

---
Izumi Tsutusi


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

2012-03-21 Thread Alan Barrett

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 contains the string umax 
which imnplies that the function deals with uintmax_t upjects, but 
the function actually deals with size_t opjects.


--apb (Alan Barrett)


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

2011-05-17 Thread Christos Zoulas
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
| 
|  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 -r1.23 src/lib/libc/stdlib/jemalloc.c
|  cvs rdiff -u -r1.52 -r1.53 src/lib/libc/stdlib/malloc.c
| 
| - Is the existing guard in malloc_init() of malloc.c insufficient?
| 
| - In the malloc_init_hard() of jemalloc.c, there are another calls may
| set errno.  Especially, the code explicitly handles an error from
| sysctl(3).

I will take a look, thanks. Which malloc are we using now? The problem
manifested itself by just calling strtod(1.0, NULL) in main and looking
at errno.

christos


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

2011-05-17 Thread Christos Zoulas
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 malloc.c

 Log Message:
 don't let readlink trash errno.;


 To generate a diff of this commit:
 cvs rdiff -u -r1.22 -r1.23 src/lib/libc/stdlib/jemalloc.c
 cvs rdiff -u -r1.52 -r1.53 src/lib/libc/stdlib/malloc.c

- Is the existing guard in malloc_init() of malloc.c insufficient?

No that works; I undid it.

- In the malloc_init_hard() of jemalloc.c, there are another calls may
set errno.  Especially, the code explicitly handles an error from
sysctl(3).

I widened the scope, thanks.

christos



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

2011-05-16 Thread tsugutomo . enami
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 -r1.22 -r1.23 src/lib/libc/stdlib/jemalloc.c
 cvs rdiff -u -r1.52 -r1.53 src/lib/libc/stdlib/malloc.c

- Is the existing guard in malloc_init() of malloc.c insufficient?

- In the malloc_init_hard() of jemalloc.c, there are another calls may
set errno.  Especially, the code explicitly handles an error from
sysctl(3).

enami.


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

2010-11-01 Thread Alan Barrett
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 above it.  Please fix the comment.

   /* Make sure we at least double the size of the arrays. */
 - new_len = (environ_malloced_len = 16) ?
 - (environ_malloced_len  1) : 16;
 + new_len = environ_malloced_len = 16 ? environ_malloced_len : 16;

--apb (Alan Barrett)


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

2010-11-01 Thread enami tsugutomo
 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

2010-09-30 Thread Matthias Scheler
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 in between (just like
 malloc()/free() behaviour).

Is there any standard which backs this statement?

 Otherwise, if i understand things
 correctly, it's more putenv that shoud work that way.

Our putenv(3) is implemented via setenv(3).

Kind regards

-- 
Matthias Scheler  http://zhadum.org.uk/


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

2010-09-30 Thread Nicolas Joly
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 setenv more than once on the
  same variable without a corresponding unsetenv in between (just like
  malloc()/free() behaviour).
 
 Is there any standard which backs this statement?

Not that i know.

  Otherwise, if i understand things
  correctly, it's more putenv that shoud work that way.
 
 Our putenv(3) is implemented via setenv(3).

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 directly instead. It's the caller
responsability to clean it when not in use anymore.

zsh 4.2 seems to follow this and try to deallocate the previous
variable string when it has been replaced by a new one. But our
putenv, which calls setenv, has already done the same ...

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.


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

2010-09-30 Thread Matthias Scheler
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 directly instead. It's the caller
 responsability to clean it when not in use anymore.

I see.

 zsh 4.2 seems to follow this and try to deallocate the previous
 variable string when it has been replaced by a new one. But our
 putenv, which calls setenv, has already done the same ...

So it assumes that it gets back from getenv(3) exactly what it passed
into putenv(3). Well, it seesm our putenv(3) needs a rewrite.
I think that setenv(3) and unsetenv(3) are correct as they are.

Kind regards

-- 
Matthias Scheler  http://zhadum.org.uk/


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

2010-09-30 Thread Nicolas Joly
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 environment
 variables: only free memory if the current value points to the same
 memory area as the allocated block. This will prevent crashes if an
 application changes the order of the environment array.
 
 Unfortunately this is still not enough to stop zsh 4.2.* from crashing.
 zsh 4.3.* works fine before and after this change.

Thanks Matthias,

One possibility could be to not free memory at all in setenv, but only
with unsetenv.

IMHO, it's a programmer error to call setenv more than once on the
same variable without a corresponding unsetenv in between (just like
malloc()/free() behaviour). Otherwise, if i understand things
correctly, it's more putenv that shoud work that way.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.


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

2010-09-30 Thread Christos Zoulas
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 OpenGroup function description; this function does not copy
 the provided string, but use it directly instead. It's the caller
 responsability to clean it when not in use anymore.

I see.

 zsh 4.2 seems to follow this and try to deallocate the previous
 variable string when it has been replaced by a new one. But our
 putenv, which calls setenv, has already done the same ...

So it assumes that it gets back from getenv(3) exactly what it passed
into putenv(3). Well, it seesm our putenv(3) needs a rewrite.
I think that setenv(3) and unsetenv(3) are correct as they are.

Well, if you fix putenv, please move the saveenv realloc environ code
in __allocenv() so it is not in two places...

christos



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

2010-09-25 Thread David Laight
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: Don't allocate a new string if the length is equal to the
 old length, because presumably the old string was also nul terminated
 so it has the extra byte needed.
 The real fix is to keep an adjunct array of bits, one for each environment
 variable and keep track if the entry was allocated or not so that we can
 free it in unsetenv.

Hmmm I've just read the TOG page for putenv().
A conformant system isn't required to do anything other than save the
user-supplied pointer.
It even states that you can modify the value by changing the memory buffer
after calling putenv().

If the strings are copied in libc...
When libc starts, all the env strings will be adjacent, and at one end
of the stack area (placed by the kernel during exec).
So presumably the addess of the string can be compared against that
range to determine whether the string was malloc'ed or not.

David

-- 
David Laight: da...@l8s.co.uk


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

2010-09-24 Thread enami tsugutomo
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

2010-09-23 Thread enami tsugutomo
 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 length, because presumably the old string was also nul terminated
 so it has the extra byte needed.
 The real fix is to keep an adjunct array of bits, one for each environmen=
 t
 variable and keep track if the entry was allocated or not so that we can
 free it in unsetenv.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.32 -r1.33 src/lib/libc/stdlib/setenv.c

Actual change done in setenv.c rev. 1.33 causes following program
memory leak (while rev. 1.32 does not).

#include stdlib.h

main()
{

while (1)
setenv(dummyvar, dummyval, 1);
}

And rev. 1.34 introduces lock leak on error path while it leaves
another fixable memory leak.

I guess following patch is worth to be applied.

enami.

Index: lib/libc/stdlib/setenv.c
===
RCS file: /cvsroot/src/lib/libc/stdlib/setenv.c,v
retrieving revision 1.34
diff -u -r1.34 setenv.c
--- lib/libc/stdlib/setenv.c23 Sep 2010 17:30:49 -  1.34
+++ lib/libc/stdlib/setenv.c24 Sep 2010 03:43:19 -
@@ -81,7 +81,7 @@
c = __findenv(name, offset);
 
if (__allocenv(offset) == -1)
-   return -1;
+   goto bad;
 
if (*value == '=')  /* no `=' in value */
++value;
@@ -90,7 +90,7 @@
if (c != NULL) {
if (!rewrite)
goto good;
-   if (strlen(c)  l_value)/* old larger; copy over */
+   if (strlen(c) = l_value)   /* old is enough; copy over */
goto copy;
} else {/* create new slot */
size = (size_t)(sizeof(char *) * (offset + 2));
@@ -113,6 +113,8 @@
/* name + `=' + value */
if ((c = malloc(size + l_value + 2)) == NULL)
goto bad;
+   if (bit_test(__environ_malloced, offset))
+   free(environ[offset]);
environ[offset] = c;
(void)memcpy(c, name, size);
c += size;



CVS commit: src/lib/libc/stdlib

2010-03-04 Thread enami tsugutomo
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, other thread may map it for the same huge category allocation
and insert it to the tree before we acquire a lock after mremap().

Fixes PR/42876.


To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 src/lib/libc/stdlib/jemalloc.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/lib/libc/stdlib

2010-02-04 Thread Roy Marples
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 src/lib/libc/stdlib/mi_vector_hash.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.