Re: svn commit: r352451 - head/stand/libsa
On Wed, Sep 18, 2019, 9:44 AM Hans Petter Selasky wrote: > On 2019-09-18 10:37, Warner Losh wrote: > > On Wed, Sep 18, 2019, 12:18 AM Conrad Meyer wrote: > > > >> Well, hang on; it's also perfectly legal for a malloc implementation > >> to return NULL for requests of zero bytes. You can access exactly the > >> number of bytes requested in the allocation; and free(NULL) works as > >> expected. NULL (0) is also aligned to any size you could want. > >> > > > > Legal, yes. But it is different than all the other FreeBSD environments, > > so the loader becomes the odd man out. This restores the consistency. > > > > Hi, > > The problem is the code that use malloc() that take NULL as a failure, > even if the size is zero :-) > > array = malloc(n * sizeof(q)); > if (array == NULL) > goto failure; > Such code isn't portable... Warner --HPS > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352451 - head/stand/libsa
On 2019-09-18 10:37, Warner Losh wrote: On Wed, Sep 18, 2019, 12:18 AM Conrad Meyer wrote: Well, hang on; it's also perfectly legal for a malloc implementation to return NULL for requests of zero bytes. You can access exactly the number of bytes requested in the allocation; and free(NULL) works as expected. NULL (0) is also aligned to any size you could want. Legal, yes. But it is different than all the other FreeBSD environments, so the loader becomes the odd man out. This restores the consistency. Hi, The problem is the code that use malloc() that take NULL as a failure, even if the size is zero :-) array = malloc(n * sizeof(q)); if (array == NULL) goto failure; --HPS ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352451 - head/stand/libsa
On Wed, Sep 18, 2019, 12:18 AM Conrad Meyer wrote:
> Well, hang on; it's also perfectly legal for a malloc implementation
> to return NULL for requests of zero bytes. You can access exactly the
> number of bytes requested in the allocation; and free(NULL) works as
> expected. NULL (0) is also aligned to any size you could want.
>
Legal, yes. But it is different than all the other FreeBSD environments,
so the loader becomes the odd man out. This restores the consistency.
Warner
Best,
> Conrad
>
> On Tue, Sep 17, 2019 at 9:16 AM Toomas Soome wrote:
> >
> > Author: tsoome
> > Date: Tue Sep 17 16:16:46 2019
> > New Revision: 352451
> > URL: https://svnweb.freebsd.org/changeset/base/352451
> >
> > Log:
> > loader: revert r352421
> >
> > As insisted by kib, malloc(0) is quite legal.
> >
> > Modified:
> > head/stand/libsa/zalloc_malloc.c
> >
> > Modified: head/stand/libsa/zalloc_malloc.c
> >
> ==
> > --- head/stand/libsa/zalloc_malloc.cTue Sep 17 15:53:40 2019
> (r352450)
> > +++ head/stand/libsa/zalloc_malloc.cTue Sep 17 16:16:46 2019
> (r352451)
> > @@ -73,9 +73,6 @@ Malloc_align(size_t bytes, size_t alignment)
> > {
> > Guard *res;
> >
> > - if (bytes == 0)
> > - return (NULL);
> > -
> > #ifdef USEENDGUARD
> > bytes += MALLOCALIGN + 1;
> > #else
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352451 - head/stand/libsa
Well, hang on; it's also perfectly legal for a malloc implementation
to return NULL for requests of zero bytes. You can access exactly the
number of bytes requested in the allocation; and free(NULL) works as
expected. NULL (0) is also aligned to any size you could want.
Best,
Conrad
On Tue, Sep 17, 2019 at 9:16 AM Toomas Soome wrote:
>
> Author: tsoome
> Date: Tue Sep 17 16:16:46 2019
> New Revision: 352451
> URL: https://svnweb.freebsd.org/changeset/base/352451
>
> Log:
> loader: revert r352421
>
> As insisted by kib, malloc(0) is quite legal.
>
> Modified:
> head/stand/libsa/zalloc_malloc.c
>
> Modified: head/stand/libsa/zalloc_malloc.c
> ==
> --- head/stand/libsa/zalloc_malloc.cTue Sep 17 15:53:40 2019
> (r352450)
> +++ head/stand/libsa/zalloc_malloc.cTue Sep 17 16:16:46 2019
> (r352451)
> @@ -73,9 +73,6 @@ Malloc_align(size_t bytes, size_t alignment)
> {
> Guard *res;
>
> - if (bytes == 0)
> - return (NULL);
> -
> #ifdef USEENDGUARD
> bytes += MALLOCALIGN + 1;
> #else
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352451 - head/stand/libsa
On Tue, Sep 17, 2019 at 04:16:47PM +, Toomas Soome wrote:
> Author: tsoome
> Date: Tue Sep 17 16:16:46 2019
> New Revision: 352451
> URL: https://svnweb.freebsd.org/changeset/base/352451
>
> Log:
> loader: revert r352421
>
> As insisted by kib, malloc(0) is quite legal.
Thank you.
>
> Modified:
> head/stand/libsa/zalloc_malloc.c
>
> Modified: head/stand/libsa/zalloc_malloc.c
> ==
> --- head/stand/libsa/zalloc_malloc.c Tue Sep 17 15:53:40 2019
> (r352450)
> +++ head/stand/libsa/zalloc_malloc.c Tue Sep 17 16:16:46 2019
> (r352451)
> @@ -73,9 +73,6 @@ Malloc_align(size_t bytes, size_t alignment)
> {
> Guard *res;
>
> - if (bytes == 0)
> - return (NULL);
> -
> #ifdef USEENDGUARD
> bytes += MALLOCALIGN + 1;
> #else
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r352451 - head/stand/libsa
On Tue, 2019-09-17 at 16:16 +, Toomas Soome wrote:
> Author: tsoome
> Date: Tue Sep 17 16:16:46 2019
> New Revision: 352451
> URL: https://svnweb.freebsd.org/changeset/base/352451
>
> Log:
> loader: revert r352421
>
> As insisted by kib, malloc(0) is quite legal.
>
> Modified:
> head/stand/libsa/zalloc_malloc.c
>
> Modified: head/stand/libsa/zalloc_malloc.c
> ==
> --- head/stand/libsa/zalloc_malloc.c Tue Sep 17 15:53:40 2019
> (r352450)
> +++ head/stand/libsa/zalloc_malloc.c Tue Sep 17 16:16:46 2019
> (r352451)
> @@ -73,9 +73,6 @@ Malloc_align(size_t bytes, size_t alignment)
> {
> Guard *res;
>
> - if (bytes == 0)
> - return (NULL);
> -
> #ifdef USEENDGUARD
> bytes += MALLOCALIGN + 1;
> #else
For the record, you're both right. In both the C and posix standards
for malloc(), an implementation is allowed to return either NULL or a
unique pointer which cannot be used to access any memory but must be
passed to free().
-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r352451 - head/stand/libsa
Author: tsoome
Date: Tue Sep 17 16:16:46 2019
New Revision: 352451
URL: https://svnweb.freebsd.org/changeset/base/352451
Log:
loader: revert r352421
As insisted by kib, malloc(0) is quite legal.
Modified:
head/stand/libsa/zalloc_malloc.c
Modified: head/stand/libsa/zalloc_malloc.c
==
--- head/stand/libsa/zalloc_malloc.cTue Sep 17 15:53:40 2019
(r352450)
+++ head/stand/libsa/zalloc_malloc.cTue Sep 17 16:16:46 2019
(r352451)
@@ -73,9 +73,6 @@ Malloc_align(size_t bytes, size_t alignment)
{
Guard *res;
- if (bytes == 0)
- return (NULL);
-
#ifdef USEENDGUARD
bytes += MALLOCALIGN + 1;
#else
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
