Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
CVS commit: src/lib/libc/stdlib
0 views
Skip to first unread message
Kamil Rytarowski
Jul 15, 2015, 8:08:02 PM7/15/15
to
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.
Approved by <riastradh>
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/lib/libc/stdlib/reallocarr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
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.
Approved by <riastradh>
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/lib/libc/stdlib/reallocarr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Pierre Pronchery
Jul 16, 2015, 4:25:55 AM7/16/15
to
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
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.
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
Kamil Rytarowski
Jul 16, 2015, 6:17:25 AM7/16/15
to
-----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:
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-----
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.
>
>> 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
> 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,
>
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-----
Joerg Sonnenberger
Jul 19, 2015, 2:57:19 PM7/19/15
to
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
> The C standard permits memcpy(3) to affect errno(2).
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
Kamil Rytarowski
Jul 19, 2015, 5:18:46 PM7/19/15
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
> 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.
>
It is also for the consistency with lines 63-64 of the same file.
Regards,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVrBMIAAoJEEuzCOmwLnZsvUsQAIMgD3/aL6pld6VZ521n0+kY
Version: GnuPG v2
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-----
Joerg Sonnenberger
Jul 19, 2015, 5:44:07 PM7/19/15
to
On Sun, Jul 19, 2015 at 11:13:48PM +0200, Kamil Rytarowski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> -----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.
> >
>
> >> 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
> It is also for the consistency with lines 63-64 of the same file.
number of reasons and historic versions at least have been known to
actually have failure modes.
Kamil Rytarowski
Jul 25, 2015, 10:22:39 PM7/25/15
to
Module Name: src
Committed By: kamil
Date: Sun Jul 26 02:22:33 UTC 2015
Committed By: kamil
Modified Files:
src/lib/libc/stdlib: reallocarray.c
Log Message:
reallocarray(3) cleanup
Add missing NetBSD CVS Id
Don't define twice _OPENBSD_SOURCE
To generate a diff of this commit:
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Kamil Rytarowski
Jul 25, 2015, 10:29:50 PM7/25/15
to
Module Name: src
Committed By: kamil
Date: Sun Jul 26 02:29:44 UTC 2015
Committed By: kamil
Modified Files:
src/lib/libc/stdlib: reallocarray.3
Log Message:
Add license header (the NetBSD 2-clause version) with (C) TNF
To generate a diff of this commit:
Kamil Rytarowski
Jul 26, 2015, 1:00:43 PM7/26/15
to
Module Name: src
Committed By: kamil
Date: Sun Jul 26 17:00:37 UTC 2015
Committed By: kamil
Modified Files:
src/lib/libc/stdlib: malloc.3
Log Message:
mandoc lint
To generate a diff of this commit:
Christos Zoulas
Jul 26, 2015, 1:03:12 PM7/26/15
to
Module Name: src
Committed By: christos
Date: Sun Jul 26 17:03:06 UTC 2015
Modified Files:
src/lib/libc/stdlib: quick_exit.3
Log Message:
From Timo Buhrmester: Fix wrong parameter description
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/lib/libc/stdlib/quick_exit.3
Committed By: christos
Date: Sun Jul 26 17:03:06 UTC 2015
Modified Files:
src/lib/libc/stdlib: quick_exit.3
Log Message:
From Timo Buhrmester: Fix wrong parameter description
To generate a diff of this commit:
Kamil Rytarowski
Jul 26, 2015, 1:09:35 PM7/26/15
to
Module Name: src
Committed By: kamil
Date: Sun Jul 26 17:09:29 UTC 2015
Modified Files:
src/lib/libc/stdlib: malloc.3
Log Message:
Add history of allocators
Idea accepted by <christos>
No objctions from <riastradh>
To generate a diff of this commit:
cvs rdiff -u -r1.42 -r1.43 src/lib/libc/stdlib/malloc.3
Committed By: kamil
Date: Sun Jul 26 17:09:29 UTC 2015
Modified Files:
src/lib/libc/stdlib: malloc.3
Log Message:
Add history of allocators
Idea accepted by <christos>
No objctions from <riastradh>
To generate a diff of this commit:
Martin Husemann
Jul 26, 2015, 1:22:02 PM7/26/15
to
Module Name: src
Committed By: martin
Date: Sun Jul 26 17:21:55 UTC 2015
Modified Files:
src/lib/libc/stdlib: jemalloc.c
Log Message:
Defer using pthread keys until we are threaded.
From Christos, fixes PR port-arm/50087 by allowing malloc calls prior
to libpthread initialization.
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/lib/libc/stdlib/jemalloc.c
Committed By: martin
Date: Sun Jul 26 17:21:55 UTC 2015
Modified Files:
src/lib/libc/stdlib: jemalloc.c
Log Message:
Defer using pthread keys until we are threaded.
From Christos, fixes PR port-arm/50087 by allowing malloc calls prior
to libpthread initialization.
To generate a diff of this commit:
Thomas Klausner
Jul 26, 2015, 6:32:10 PM7/26/15
to
Module Name: src
Committed By: wiz
Date: Sun Jul 26 22:32:03 UTC 2015
Modified Files:
src/lib/libc/stdlib: malloc.3
Log Message:
Spacing; Fn -> Xr for jemalloc.
To generate a diff of this commit:
cvs rdiff -u -r1.43 -r1.44 src/lib/libc/stdlib/malloc.3
Committed By: wiz
Date: Sun Jul 26 22:32:03 UTC 2015
Modified Files:
src/lib/libc/stdlib: malloc.3
Log Message:
Spacing; Fn -> Xr for jemalloc.
To generate a diff of this commit:
Kamil Rytarowski
Jul 28, 2015, 1:13:42 PM7/28/15
to
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)
Make this work on !NetBSD platforms:
- replace __CTASSERT() with platform agnostic solution SQRT_SIZE_MAX
- include nbtool_config.h for cross builds to get definition of __RCSID()
- restore errno in the last rare code path for platforms affecting errno(2)
in memcpy(2)
While there: rename parameter name 'num' to 'number' to be in sync with
the calloc(3) parameter naming.
Reported by scole_mail at the current-users ml.
To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/lib/libc/stdlib/reallocarr.3
cvs rdiff -u -r1.2 -r1.3 src/lib/libc/stdlib/reallocarr.c
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)
Make this work on !NetBSD platforms:
- replace __CTASSERT() with platform agnostic solution SQRT_SIZE_MAX
- include nbtool_config.h for cross builds to get definition of __RCSID()
- restore errno in the last rare code path for platforms affecting errno(2)
in memcpy(2)
While there: rename parameter name 'num' to 'number' to be in sync with
the calloc(3) parameter naming.
Reported by scole_mail at the current-users ml.
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/lib/libc/stdlib/reallocarr.c
0 new messages