Prevent malloc with size 0

In case malloc is invoked with requested size 0, this patch will prevent the execution of the allocation algorithm (because it corrupts the data structures)
and will return 0 to the caller.

Signed-off-by Nikolaos Kostaras <[email protected]>

---
 common/dlmalloc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

common/dlmalloc.c +0 -0

index fce7a76..d9e3ea9 100644

common/dlmalloc.c Void_t* mALLOc(bytes) size_t bytes; · line 2185

Quoted 3 lines

common/dlmalloc.c +1 -1

-  if ((long)bytes < 0) return 0;
+  if ((long)bytes <= 0) return 0;

I think you should return some impossible ptr value =! NULL Size 0 not really an error.

Dear Joakim Tjernlund,

In message <OF9263CF56.48468959-ONC12577C3.003E4D93-C12577C3.

Quoted 1 line · 003ECAD7 at transmode.se> you wrote:

Quoted 5 lines

common/dlmalloc.c Void_t* mALLOc(bytes) size_t bytes; · line 2185

Quoted 2 lines

common/dlmalloc.c +1 -1

-  if ((long)bytes < 0) return 0;
+  if ((long)bytes <= 0) return 0;

I think you should return some impossible ptr value =! NULL Size 0 not really an error.

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Quoted 3 lines

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Yes, but not very useful. Glibc does not return NULL

Dear Joakim Tjernlund,

In message <OFD5ABFC5E.96E88C93-ONC12577C3.00406E0E-C12577C3.

Quoted 4 lines · 00408F11 at transmode.se> you wrote:

Quoted 3 lines

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Quoted 1 line

Yes, but not very useful. Glibc does not return NULL

Maybe not in the current implementation, and not on the architecture you checked. Current doc reads: "If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free()."

Of course we could return some valid pointer like glibc does, i. e. implement something like

   if (size == 0)
      size = 8;

or so. Do you think that would be better?

Quoted 4 lines

Of course we could return some valid pointer like glibc does, i. e. implement something like

Quoted 4 lines

   if (size == 0)
      size = 8;

or so. Do you think that would be better?

Better than NULL, but best would be a ptr that will SEGV if you try to defer it. Not the easiest to impl., perhaps ~0 will do?

Dear Joakim Tjernlund,

In message <OF9AD66E3F.36E9C654-ONC12577C3.004134FD-C12577C3.

Quoted 9 lines · 0041A007 at transmode.se> you wrote:

Quoted 8 lines

Of course we could return some valid pointer like glibc does, i. e. implement something like

   if (size == 0)
      size = 8;

or so. Do you think that would be better?

Quoted 3 lines

Better than NULL, but best would be a ptr that will SEGV if you try to defer it. Not the easiest to impl., perhaps ~0 will do?

The pointers you get from glibc can be read and written - they don't segfault either (and usually we cannot do this in U-Boot, as most systems have the MMU off).

Wolfgang Denk wrote on 2010/10/21 13:32:54:

Quoted 4 lines

Quoted 3 lines · Joakim Tjernlund you

Quoted 2 lines

common/dlmalloc.c +1 -1

-  if ((long)bytes < 0) return 0;
+  if ((long)bytes <= 0) return 0;

Quoted 5 lines

Quoted 2 lines

I think you should return some impossible ptr value =! NULL Size 0 not really an error.

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Yes, but not very useful. Glibc does not return NULL

Quoted 11 lines · On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote:

Wolfgang Denk wrote on 2010/10/21 13:32:54:

Quoted 9 lines

Quoted 5 lines · Joakim Tjernlund you

common/dlmalloc.c Void_t* mALLOc(bytes) size_t bytes; · line 2185

Quoted 2 lines

common/dlmalloc.c +1 -1

-  if ((long)bytes < 0) return 0;
+  if ((long)bytes <= 0) return 0;

I think you should return some impossible ptr value =! NULL Size 0 not really an error.

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Quoted 1 line

Yes, but not very useful. Glibc does not return NULL

it is useful for malloc(0) == NULL. the glibc behavior is downright obnoxious. we disable this for uClibc and dont see problems. if anything, we catch accidental programming mistakes which then get fixed.

why exactly do you want malloc(0) to return valid memory ? i would rather

have u-boot return an error.

Quoted 1 line · Mike Frysinger

have u-boot return an error.

Is NULL what you consider to be an error

Besides, is not free(NULL) valid (does nothing) as well?

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Dear Mike Frysinger,

Quoted 8 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 4 lines

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

Quoted 15 lines

Dear Mike Frysinger,

Quoted 12 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Quoted 2 lines

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

There was a long debate on the list regarding this where I argued that malloc(0) should not be an error and malloc should return a ptr != NULL I guess that is why it hasn't been applied.

Jocke

Dear Joakim Tjernlund,

Quoted 18 lines

Quoted 17 lines

Dear Mike Frysinger,

Quoted 12 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

Quoted 5 lines

There was a long debate on the list regarding this where I argued that malloc(0) should not be an error and malloc should return a ptr != NULL I guess that is why it hasn't been applied.

Jocke

Ok, let's restart. Is there any objection why malloc(0) should not return NULL in uboot?

Is it coliding with any spec?

Marek Vasut <[email protected]> wrote on 2012/04/01 16:01:56:

Quoted 24 lines

Dear Joakim Tjernlund,

Quoted 22 lines

Quoted 10 lines

Dear Mike Frysinger,

Quoted 8 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

There was a long debate on the list regarding this where I argued that malloc(0) should not be an error and malloc should return a ptr != NULL I guess that is why it hasn't been applied.

Quoted 4 lines

Quoted 1 line

Jocke

Ok, let's restart. Is there any objection why malloc(0) should not return NULL in uboot?

Yes, read the thread to see why.

Quoted 1 line

Is it coliding with any spec?

No, both are valid.

Jocke

Dear Joakim Tjernlund,

Quoted 25 lines

Marek Vasut <[email protected]> wrote on 2012/04/01 16:01:56:

Quoted 24 lines

Dear Joakim Tjernlund,

Quoted 22 lines

Quoted 10 lines

Dear Mike Frysinger,

Quoted 8 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

There was a long debate on the list regarding this where I argued that malloc(0) should not be an error and malloc should return a ptr != NULL I guess that is why it hasn't been applied.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

?Jocke

Ok, let's restart. Is there any objection why malloc(0) should not return NULL in uboot?

Yes, read the thread to see why.

Well I did, that's why I have no objections to applying this patch

Quoted 4 lines

Quoted 1 line

Is it coliding with any spec?

No, both are valid.

Hi All

Here we go again ;)

Quoted 27 lines

Dear Joakim Tjernlund,

Quoted 25 lines

Marek Vasut <[email protected]> wrote on 2012/04/01 16:01:56:

Quoted 24 lines

Dear Joakim Tjernlund,

Quoted 22 lines

Quoted 10 lines

Dear Mike Frysinger,

Quoted 8 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

There was a long debate on the list regarding this where I argued that malloc(0) should not be an error and malloc should return a ptr != NULL I guess that is why it hasn't been applied.

Quoted 12 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Jocke

Ok, let's restart. Is there any objection why malloc(0) should not return NULL in uboot?

Yes, read the thread to see why.

Well I did, that's why I have no objections to applying this patch

Quoted 3 lines

Quoted 1 line

Is it coliding with any spec?

No, both are valid.

<quote author="Reinhard Meyer">
Out of principle I would say that malloc(0) should return a non-NULL pointer of an area where exactly 0 bytes may be used. And, of course, free() of that area shall not fail or crash the system. </quote>

I'm wondering how exactly this would work - In theory, if you tried to access this pointer you should get a segv. But I suppose if you malloc(1) and try to access beyond the first byte there probably won't be a segv either....

So to review the facts:

- The original complaint was that malloc(0) corrupts the malloc data structures, not that U-Boot's malloc(0) behaviour is non-standard
- Both the malloc(0) returns NULL and malloc(0) returns a uniquely free'able block of memory solutions are standard compliant
- malloc(0) returning NULL may break code which, for the sake of code simplicity, does not bother to check for zero-size before calling malloc()

- malloc(0) returning NULL may help to identify brain-dead use-cases

My vote:

        if ((long)bytes == 0) {
                DEBUG("Warning: malloc of zero block size\n");
                bytes = 1;

        } else if ((long)bytes < 0) {
                DEBUG("Error: malloc of negative block size\n");
                return 0;
        }

Regards,

Graeme

Dear Graeme Russ,

Quoted 3 lines

Hi All

Here we go again ;)

Yay (polishing my flamethrower)!

Quoted 54 lines · Marek Vasut

Quoted 27 lines

Dear Joakim Tjernlund,

Quoted 25 lines

Marek Vasut <[email protected]> wrote on 2012/04/01 16:01:56:

Quoted 24 lines

Dear Joakim Tjernlund,

Quoted 22 lines

Quoted 10 lines

Dear Mike Frysinger,

Quoted 8 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

There was a long debate on the list regarding this where I argued that malloc(0) should not be an error and malloc should return a ptr != NULL I guess that is why it hasn't been applied.

Quoted 12 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

?Jocke

Ok, let's restart. Is there any objection why malloc(0) should not return NULL in uboot?

Yes, read the thread to see why.

Well I did, that's why I have no objections to applying this patch

Quoted 3 lines

Quoted 1 line

Is it coliding with any spec?

No, both are valid.

<quote author="Reinhard Meyer">
Out of principle I would say that malloc(0) should return a non-NULL pointer of an area where exactly 0 bytes may be used. And, of course, free() of that area shall not fail or crash the system. </quote>

I'm wondering how exactly this would work - In theory, if you tried to access this pointer you should get a segv. But I suppose if you malloc(1) and try to access beyond the first byte there probably won't be a segv either....

So to review the facts:

Quoted 7 lines

- The original complaint was that malloc(0) corrupts the malloc data ? structures, not that U-Boot's malloc(0) behaviour is non-standard
- Both the malloc(0) returns NULL and malloc(0) returns a uniquely ? free'able block of memory solutions are standard compliant
- malloc(0) returning NULL may break code which, for the sake of code ? simplicity, does not bother to check for zero-size before calling ? malloc()

Well but you said malloc(0) corrupts the mallocator's data structures. Therefore malloc(0) used in code right now is broken anyway.

Quoted 1 line

- malloc(0) returning NULL may help to identify brain-dead use-cases

Agreed.

Quoted 6 lines

My vote:

? ? ? ? if ((long)bytes == 0) {
? ? ? ? ? ? ? ? DEBUG("Warning: malloc of zero block size\n"); ? ? ? ? ? ? ? ? bytes = 1;

Well ... no, how can malloc(0) returning NULL break code that's already broken any more? It's silently roughing the mallocator structures up and it means the code is sitting on a ticking a-bomb anyway.

So we should add this like:

if (bytes == 0) {
? ? ? ?debug("You're sitting on a ticking A-Bomb doing this");

? ? ? ?return NULL;
} else if (bytes < 0) {
? ? ? ?return NULL;
}

Quoted 4 lines

? ? ? ? } else if ((long)bytes < 0) {
? ? ? ? ? ? ? ? DEBUG("Error: malloc of negative block size\n"); ? ? ? ? ? ? ? ? return 0;
? ? ? ? }

Hi Marek,

Quoted 70 lines · Marek Vasut

Dear Graeme Russ,

Quoted 3 lines

Hi All

Here we go again ;)

Yay (polishing my flamethrower)!

Quoted 61 lines · Marek Vasut

Quoted 27 lines

Dear Joakim Tjernlund,

Quoted 25 lines

Marek Vasut <[email protected]> wrote on 2012/04/01 16:01:56:

Quoted 24 lines

Dear Joakim Tjernlund,

Quoted 22 lines

Quoted 10 lines

Dear Mike Frysinger,

Quoted 8 lines · On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote:

Quoted 4 lines · Mike Frysinger

Quoted 1 line

have u-boot return an error.

Is NULL what you consider to be an error

yes

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Besides, is not free(NULL) valid (does nothing) as well?

yes, free(NULL) should work fine per POSIX
-mike

Well then, this patch wasn't accepted yet and I consider it OK to apply. Any objections?

There was a long debate on the list regarding this where I argued that malloc(0) should not be an error and malloc should return a ptr != NULL I guess that is why it hasn't been applied.

Quoted 12 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Jocke

Ok, let's restart. Is there any objection why malloc(0) should not return NULL in uboot?

Yes, read the thread to see why.

Well I did, that's why I have no objections to applying this patch

Quoted 3 lines

Quoted 1 line

Is it coliding with any spec?

No, both are valid.

<quote author="Reinhard Meyer">
Out of principle I would say that malloc(0) should return a non-NULL pointer of an area where exactly 0 bytes may be used. And, of course, free() of that area shall not fail or crash the system. </quote>

I'm wondering how exactly this would work - In theory, if you tried to access this pointer you should get a segv. But I suppose if you malloc(1) and try to access beyond the first byte there probably won't be a segv either....

So to review the facts:

- The original complaint was that malloc(0) corrupts the malloc data structures, not that U-Boot's malloc(0) behaviour is non-standard
- Both the malloc(0) returns NULL and malloc(0) returns a uniquely free'able block of memory solutions are standard compliant
- malloc(0) returning NULL may break code which, for the sake of code simplicity, does not bother to check for zero-size before calling malloc()

Quoted 2 lines

Well but you said malloc(0) corrupts the mallocator's data structures. Therefore malloc(0) used in code right now is broken anyway.

Correct, but the breakage is in malloc() not the caller

Quoted 14 lines

Quoted 1 line

- malloc(0) returning NULL may help to identify brain-dead use-cases

Agreed.

Quoted 5 lines

My vote:

        if ((long)bytes == 0) {
                DEBUG("Warning: malloc of zero block size\n");
                bytes = 1;

Well ... no, how can malloc(0) returning NULL break code that's already broken any more? It's silently roughing the mallocator structures up and it means the code is sitting on a ticking a-bomb anyway.

Quoted 4 lines

So we should add this like:

if (bytes == 0) {
       debug("You're sitting on a ticking A-Bomb doing this");

Because you just set it off - Right now, that code is assuming malloc(0) will return a valid pointer and thus not throw an E_NOMEM error - Now all that code will fail with E_NOMEM

Quoted 9 lines

       return NULL;
} else if (bytes < 0) {
       return NULL;
}

Quoted 4 lines

        } else if ((long)bytes < 0) {
                DEBUG("Error: malloc of negative block size\n");
                return 0;
        }

Regards,

Graeme

Dear Graeme Russ,

Quoted 5 lines

Hi Marek,

Quoted 2 lines · Marek Vasut

Dear Graeme Russ,

Quoted 3 lines

Because you just set it off - Right now, that code is assuming malloc(0) will return a valid pointer and thus not throw an E_NOMEM error - Now all that code will fail with E_NOMEM

Well ... that code worked with invalid memory (most probably not even R/W because it was some completely random hunk) and worked only by sheer coincidence. Let's break it, it was broken anyway.

Do you know about any such code? That's why I suggest adding such a debug() only in case there's malloc(0) called. Maybe even add a printf() instead.

Hi Marek,

Quoted 11 lines · Marek Vasut

Dear Graeme Russ,

Quoted 8 lines

Hi Marek,

Quoted 1 line · Marek Vasut

Dear Graeme Russ,

Because you just set it off - Right now, that code is assuming malloc(0) will return a valid pointer and thus not throw an E_NOMEM error - Now all that code will fail with E_NOMEM

Quoted 3 lines

Well ... that code worked with invalid memory (most probably not even R/W because it was some completely random hunk) and worked only by sheer coincidence. Let's break it, it was broken anyway.

a) The code calling malloc(0) is not broken, U-Boot's implementation of malloc(0) is.

b) The code calling malloc(0) is making a perfectly legitimate assumption based on how glibc handles malloc(0)

c) Just because glibc does something does not mean we have to

d) malloc(0) returning NULL and malloc(0) returning a valid pointer is not going to trouble me as I will never call malloc(0)

Quoted 3 lines

Do you know about any such code? That's why I suggest adding such a debug() only in case there's malloc(0) called. Maybe even add a printf() instead.

Did you see the FDT example - Admitedly not in U-Boot but it's a really good example IMHO - For the sake of code simplisity and clarity, some processing loops are best implemented assuming malloc(0) will return a valid pointer. Now if that pointer is de-referenced, then that is the callers problem...

Regards,

Graeme

Dear Graeme Russ,

Quoted 18 lines

Hi Marek,

Quoted 14 lines · Marek Vasut

Dear Graeme Russ,

Quoted 8 lines

Hi Marek,

Quoted 1 line · Marek Vasut

Dear Graeme Russ,

Because you just set it off - Right now, that code is assuming malloc(0) will return a valid pointer and thus not throw an E_NOMEM error - Now all that code will fail with E_NOMEM

Well ... that code worked with invalid memory (most probably not even R/W because it was some completely random hunk) and worked only by sheer coincidence. Let's break it, it was broken anyway.

Quoted 2 lines

a) The code calling malloc(0) is not broken, U-Boot's implementation of ? ?malloc(0) is.

Well if it corrupts the internal structures of the mallocator, it's broken because it works by sheer coincidence. But I know what you wanna point out.

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption ? ?based on how glibc handles malloc(0)

Yes, agreed

Quoted 1 line

c) Just because glibc does something does not mean we have to

ACK

Quoted 2 lines

d) malloc(0) returning NULL and malloc(0) returning a valid pointer is not ? ?going to trouble me as I will never call malloc(0)

You sure? :)

Anyway, if we return something else than 0, how are we gonna trap such a null pointer?

Quoted 9 lines

Quoted 3 lines

Do you know about any such code? That's why I suggest adding such a debug() only in case there's malloc(0) called. Maybe even add a printf() instead.

Did you see the FDT example - Admitedly not in U-Boot but it's a really good example IMHO - For the sake of code simplisity and clarity, some processing loops are best implemented assuming malloc(0) will return a valid pointer. Now if that pointer is de-referenced, then that is the callers problem...

I did not see it, where?

Hi Marek,

Quoted 10 lines · Marek Vasut

Dear Graeme Russ,

Quoted 8 lines

Hi Marek,

Quoted 5 lines · Marek Vasut

Dear Graeme Russ,

Quoted 3 lines

Hi Marek,

On Mon, Apr 2, 2012 at 9:45 AM, Marek Vasut <[email protected]>

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

Quoted 1 line

Dear Graeme Russ,

Because you just set it off - Right now, that code is assuming malloc(0) will return a valid pointer and thus not throw an E_NOMEM error - Now all that code will fail with E_NOMEM

Well ... that code worked with invalid memory (most probably not even R/W because it was some completely random hunk) and worked only by sheer coincidence. Let's break it, it was broken anyway.

Quoted 6 lines

Quoted 2 lines

a) The code calling malloc(0) is not broken, U-Boot's implementation of malloc(0) is.

Well if it corrupts the internal structures of the mallocator, it's broken because it works by sheer coincidence. But I know what you wanna point out.

If I call printf() with incorrect format specifiers and arguments (and the compile does not pick it up) then my code is broken. If I call printf() and the systems implementation does not support a standard format specifier that I'm using then printf() is broken, not my code.

malloc(0) is a permissible call - It's unfortunate that the behaviour is unspecified:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
ISO/IEC 9899:TC2 - May 6, 2005

7.20.3.3 The malloc function (p.314)
The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

Returns
The malloc function returns either a null pointer or a pointer to the allocated space.

J.1 Unspecified behavior (p. 490)
- The amount of storage allocated by a successful call to the calloc, malloc, or realloc function when 0 bytes was requested (7.20.3)

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
ISO/IEC 9899:201x - April 12, 2011

7.22.3.4 The malloc function (p. 349)
Synopsis
#include <stdlib.h>
void *malloc(size_t size);
Description
The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.
Returns
The malloc function returns either a null pointer or a pointer to the allocated space.

J.1 Unspecified behavior (p. 556)
The amount of storage allocated by a successful call to the calloc, malloc, or realloc function when 0 bytes was requested (7.22.3).

I have also seen forum postings of the form:
Section 7.20.3
If the size of the space requested is zero, the behavior is implementation defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

but have not seen an official document stating this

Quoted 5 lines

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption based on how glibc handles malloc(0)

Yes, agreed

Quoted 8 lines

Quoted 1 line

c) Just because glibc does something does not mean we have to

ACK

Quoted 2 lines

d) malloc(0) returning NULL and malloc(0) returning a valid pointer is not going to trouble me as I will never call malloc(0)

You sure? :)

No ;)

Quoted 2 lines

Anyway, if we return something else than 0, how are we gonna trap such a null pointer?

You don't - You ask for a pointer to a block of memory of zero size and malloc will return the smallest block it can. Remember, malloc(x) does not have to return a block of exactly x bytes - it must return a block of at least x bytes. It is up to you not to deference the pointer passed back from malloc(0)

Quoted 11 lines

Quoted 9 lines

Quoted 3 lines

Do you know about any such code? That's why I suggest adding such a debug() only in case there's malloc(0) called. Maybe even add a printf() instead.

Did you see the FDT example - Admitedly not in U-Boot but it's a really good example IMHO - For the sake of code simplisity and clarity, some processing loops are best implemented assuming malloc(0) will return a valid pointer. Now if that pointer is de-referenced, then that is the callers problem...

I did not see it, where?

patchwork (http://patchwork.ozlabs.org/patch/71914/)

Bottom line is, we could do either and we would be 100% compliant with the C standard

The question is, what would be more onerous. Since the majority of U-Boot developers will be more familiar with the glibc implementation, we may one day end up with code that blindly assumes malloc(0) returns a valid pointer and not NULL so to me, returning a valid pointer would be a logical choice.

On the converse, returning NULL from malloc(0) means that any attempt to (illegally) deference it will be immediately obvious...

Regards,

Graeme

Dear Graeme Russ,

Quoted 11 lines

Hi Marek,

Bottom line is, we could do either and we would be 100% compliant with the C standard

The question is, what would be more onerous. Since the majority of U-Boot developers will be more familiar with the glibc implementation, we may one day end up with code that blindly assumes malloc(0) returns a valid pointer and not NULL so to me, returning a valid pointer would be a logical choice.

Quoted 2 lines

On the converse, returning NULL from malloc(0) means that any attempt to (illegally) deference it will be immediately obvious...

So it's a question of being fool-proof vs. being compatible with glibc. This is a tough one, so what about voting ? ;-)

Hi Marek,

Quoted 13 lines · Marek Vasut

Dear Graeme Russ,

Quoted 11 lines

Hi Marek,

Bottom line is, we could do either and we would be 100% compliant with the C standard

The question is, what would be more onerous. Since the majority of U-Boot developers will be more familiar with the glibc implementation, we may one day end up with code that blindly assumes malloc(0) returns a valid pointer and not NULL so to me, returning a valid pointer would be a logical choice.

Quoted 6 lines

Quoted 2 lines

On the converse, returning NULL from malloc(0) means that any attempt to (illegally) deference it will be immediately obvious...

So it's a question of being fool-proof vs. being compatible with glibc. This is a tough one, so what about voting ? ;-)

#define CONFIG_SYS_GLIBC_MALLOC_COMPAT

Kidding

Consider:

void some_function_a(void)

{
        uchar *blah;
        blah = malloc(1);

        if(blah)
                blah[1] = 'x';
        else
                printf("E_NOMEM\n");
}

void some_function_b(void)

{
        uchar *blah;
        blah = malloc(0);

        if(blah)
                blah[0] = 'x';
        else
                printf("E_NOMEM\n");
}

Both will corrupt data if malloc(0) returns a valid pointer. But:

void some_function_b(int i)

{
        uchar *blah;
        blah = malloc(i);

        if(blah)
                blah[i] = 'x';
        else
                printf("E_NOMEM\n");
}

Will return E_NOMEM if i == 0 and corrupt data is i > 0

It's inconsistent.

I originally thought returning NULL was the most appropriate option, but seeing the FDT example and thinking how malloc(0) returning a valid pointer has the potential to simplify (and hence make smaller and faster) code in some circumstances.

b) The code calling malloc(0) is making a perfectly legitimate assumption based on how glibc handles malloc(0)

Quoted 2 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

b) The code calling malloc(0) is making a perfectly legitimate assumption ? ?based on how glibc handles malloc(0)

not really. ?POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). ?no userspace code assuming malloc(0) will return non-NULL is correct.
-mike

Quoted 3 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

-mike

Dear Mike Frysinger,

Quoted 3 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 5 lines

Quoted 1 line

? ?based on how glibc handles malloc(0)

not really. ?POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). ?no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Hi Marek,

Quoted 6 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 4 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 3 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Regards,

Graeme

Dear Graeme Russ,

Quoted 27 lines

Hi Marek,

Quoted 6 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 4 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 3 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

? ?based on how glibc handles malloc(0)

not really. ?POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). ?no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

Quoted 2 lines

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Well, this still might break some code which assumes otherwise ... like you said. And like I said, let's break it because it worked only be a sheer coincidence ;-)

Hi Marek,

Quoted 5 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 3 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

? ?based on how glibc handles malloc(0)

not really. ?POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). ?no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 5 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut <[email protected]>

Quoted 4 lines

Quoted 4 lines

Dear Mike Frysinger,

Quoted 2 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 1 line

b) The code calling malloc(0) is making a perfectly legitimate

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is implementation defined (so it

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with

Quoted 8 lines

Quoted 1 line

my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

Quoted 5 lines

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Then u-boot will be incompatible with both glibc and the linux kernel, it

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does

if (!size)

    return ZERO_SIZE_PTR;

Hi Joakim,

Quoted 28 lines · Joakim Tjernlund

Quoted 28 lines

Hi Marek,

Quoted 5 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 3 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

? ?based on how glibc handles malloc(0)

not really. ?POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). ?no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

Quoted 4 lines

Quoted 2 lines

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Quoted 5 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar:
?if (!size)
? ? return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 3 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <[email protected]>

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut <[email protected]>

Quoted 29 lines

Quoted 29 lines

Quoted 28 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 4 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 6 lines

Quoted 5 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

Quoted 2 lines

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

Jocke

Dear Joakim Tjernlund,

Quoted 6 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 3 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <[email protected]>

Quoted 3 lines · wrote:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut <[email protected]>

Quoted 46 lines · wrote:

Quoted 29 lines

Quoted 29 lines

Quoted 28 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 4 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 6 lines

Quoted 5 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

Quoted 5 lines

Quoted 2 lines

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 68 lines

Dear Joakim Tjernlund,

Quoted 7 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
<[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 51 lines · wrote:

Quoted 29 lines

Quoted 29 lines

Quoted 28 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 4 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 10 lines

Quoted 7 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

Quoted 4 lines

Quoted 2 lines

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Jocke

Dear Joakim Tjernlund,

Quoted 72 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 71 lines

Dear Joakim Tjernlund,

Quoted 7 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
<[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 53 lines · wrote:

Quoted 29 lines

Quoted 29 lines

Quoted 28 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 4 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 10 lines

Quoted 7 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

Quoted 5 lines

Quoted 1 line

But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Can't GCC track it?

Marek Vasut <[email protected]> wrote on 2012/04/02 16:42:30:

Quoted 83 lines

Dear Joakim Tjernlund,

Quoted 80 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 66 lines

Dear Joakim Tjernlund,

Quoted 7 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
<[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 49 lines · wrote:

Quoted 29 lines

Quoted 29 lines

Quoted 28 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 4 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 8 lines

Quoted 7 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Quoted 1 line

Can't GCC track it?

Track what? NULL ptrs? I don't think so. Possibly when you have a static NULL ptr but not in the general case.

I am getting tired of this discussion now. I am just trying to tell you that no sane impl. of malloc() these days return NULL for malloc(0).

Even
though standards allow it they don't consider malloc(0) an error, glibc will not update errno in this case.

Jocke

Dear Joakim Tjernlund,

Quoted 84 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:42:30:

Quoted 83 lines

Dear Joakim Tjernlund,

Quoted 80 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 66 lines

Dear Joakim Tjernlund,

Quoted 7 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
<[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 49 lines · wrote:

Quoted 29 lines

Quoted 29 lines

Quoted 28 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 4 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 8 lines

Quoted 7 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Quoted 4 lines

Quoted 1 line

Can't GCC track it?

Track what? NULL ptrs? I don't think so. Possibly when you have a static NULL ptr but not in the general case.

Well of course.

Quoted 3 lines

I am getting tired of this discussion now. I am just trying to tell you that no sane impl. of malloc() these days return NULL for malloc(0).

And I got your point. Though for u-boot, this would be the best solution actually. Anyone who uses memory allocated by malloc(0) is insane.

Quoted 4 lines

Even
though standards allow it they don't consider malloc(0) an error, glibc will not update errno in this case.

There's no errno in uboot I'm aware of ;-)

Marek Vasut <[email protected]> wrote on 2012/04/02 17:23:03:

Quoted 87 lines

Dear Joakim Tjernlund,

Quoted 85 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:42:30:

Quoted 84 lines

Dear Joakim Tjernlund,

Quoted 81 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 67 lines

Dear Joakim Tjernlund,

Quoted 7 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
<[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 50 lines · wrote:

Quoted 30 lines

Quoted 30 lines

Quoted 29 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 4 lines

b) The code calling malloc(0) is making a perfectly
legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 8 lines

Quoted 7 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Can't GCC track it?

Track what? NULL ptrs? I don't think so. Possibly when you have a static NULL ptr but not in the general case.

Well of course.

What did you mean then with "Can't GCC track it?" then? Just a bad joke?

Quoted 5 lines

Quoted 2 lines

I am getting tired of this discussion now. I am just trying to tell you that no sane impl. of malloc() these days return NULL for malloc(0).

And I got your point. Though for u-boot, this would be the best solution actually. Anyone who uses memory allocated by malloc(0) is insane.

No, you don't get the point. If you did you would not have have made the "insane" remark.

Quoted 5 lines

Quoted 3 lines

Even
though standards allow it they don't consider malloc(0) an error, glibc will not update errno in this case.

There's no errno in uboot I'm aware of ;-)

Just pointing out that malloc(0) is not an error even if malloc returns NULL in glibc/standards. malloc(0) represents the empty set, just like 0 does in math and it is sometimes useful.

Jocke

From: Marek Vasut <[email protected]>

Dear Joakim Tjernlund,

Quoted 90 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 17:23:03:

Quoted 89 lines

Dear Joakim Tjernlund,

Quoted 87 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:42:30:

Quoted 85 lines

Dear Joakim Tjernlund,

Quoted 74 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 73 lines

Dear Joakim Tjernlund,

Quoted 7 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
<[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 55 lines · wrote:

Quoted 30 lines

Quoted 30 lines

Quoted 29 lines

Quoted 8 lines

Dear Mike Frysinger,

Quoted 6 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

b) The code calling malloc(0) is making a perfectly
legitimate assumption

based on how glibc handles malloc(0)

Quoted 7 lines

Quoted 4 lines

not really. POSIX says malloc(0) is implementation
defined (so it may return a unique address, or it may
return NULL). no userspace code assuming malloc(0)
will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 6 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 10 lines

Quoted 7 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

Quoted 7 lines

Quoted 2 lines

But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Can't GCC track it?

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Track what? NULL ptrs? I don't think so. Possibly when you have a static NULL ptr but not in the general case.

Well of course.

What did you mean then with "Can't GCC track it?" then? Just a bad joke?

Never mind, didn't finish my train of thought.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

I am getting tired of this discussion now. I am just trying to tell you that no sane impl. of malloc() these days return NULL for malloc(0).

And I got your point. Though for u-boot, this would be the best solution actually. Anyone who uses memory allocated by malloc(0) is insane.

No, you don't get the point. If you did you would not have have made the "insane" remark.

No, relying on malloc(0) returning something sane is messed up.

Marek Vasut <[email protected]> wrote on 2012/04/02 18:39:33:

Quoted 16 lines

From: Marek Vasut <[email protected]>

Dear Joakim Tjernlund,

Quoted 12 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 17:23:03:

Quoted 11 lines

Dear Joakim Tjernlund,

Quoted 9 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:42:30:

Quoted 8 lines

Dear Joakim Tjernlund,

Quoted 6 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 5 lines

Dear Joakim Tjernlund,

Quoted 3 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02

Quoted 85 lines

Quoted 85 lines

Quoted 85 lines

Quoted 84 lines

Quoted 75 lines

Quoted 75 lines

Quoted 74 lines

Quoted 4 lines

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut <[email protected]>

Quoted 52 lines · wrote:

Quoted 33 lines

Quoted 33 lines

Quoted 32 lines

Quoted 17 lines

Dear Mike Frysinger,

On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
b) The code calling malloc(0) is making a
perfectly legitimate assumption

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is
implementation defined (so it may return a unique
address, or it may return NULL). no userspace
code assuming malloc(0) will return non-NULL is
correct.

Which is your implementation-defined ;-) But I have
to agree with this one. So my vote is for
returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Quoted 7 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 6 lines

Quoted 6 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

Quoted 6 lines

Quoted 4 lines

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Can't GCC track it?

Track what? NULL ptrs? I don't think so. Possibly when you have a static NULL ptr but not in the general case.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Well of course.

What did you mean then with "Can't GCC track it?" then? Just a bad joke?

Never mind, didn't finish my train of thought.

I almost figured that ...

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

I am getting tired of this discussion now. I am just trying to tell you that no sane impl. of malloc() these days return NULL for malloc(0).

And I got your point. Though for u-boot, this would be the best solution actually. Anyone who uses memory allocated by malloc(0) is insane.

Quoted 4 lines

Quoted 2 lines

No, you don't get the point. If you did you would not have have made the "insane" remark.

No, relying on malloc(0) returning something sane is messed up.

Depends, if writing generic code for lots of OS:es you cannot rely malloc(0). Writing kernel code you can.

Not to mention those devs that
don't
know better and just assumes that what works in glibc/kernel works every where.

From Scotts example we already know there is kernel code that relies on malloc(0) not returning NULL.

Your argument seems to boil down to "relying on malloc(0) returning something sane is messed up" so therefore u-boot malloc should take the easy route and just return NULL for malloc(0).

Jocke

Dear Joakim Tjernlund,

Quoted 17 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 18:39:33:

Quoted 16 lines

From: Marek Vasut <[email protected]>

Dear Joakim Tjernlund,

Quoted 12 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 17:23:03:

Quoted 11 lines

Dear Joakim Tjernlund,

Quoted 9 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:42:30:

Quoted 8 lines

Dear Joakim Tjernlund,

Quoted 6 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:05:13:

Quoted 5 lines

Dear Joakim Tjernlund,

Quoted 3 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02

09:17:44:

Quoted 105 lines

Quoted 85 lines

Quoted 85 lines

Quoted 85 lines

Quoted 84 lines

Quoted 75 lines

Quoted 75 lines

Quoted 74 lines

Quoted 4 lines

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 52 lines · wrote:

Quoted 33 lines

Quoted 33 lines

Quoted 32 lines

Dear Mike Frysinger,

On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
b) The code calling malloc(0) is making a
perfectly legitimate assumption

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is
implementation defined (so it may return a unique
address, or it may return NULL). no userspace
code assuming malloc(0) will return non-NULL is
correct.

Which is your implementation-defined ;-) But I have
to agree with this one. So my vote is for
returning NULL.

Also, no userspace code assuming malloc(0) will
return NULL is correct

Point being, no matter which implementation is
chosen, it is up to the caller to not assume that
the choice that was made was, in fact, the choice
that was made.

I.e. the behaviour of malloc(0) should be able to be
changed on a whim with no side-effects

So I think I should change my vote to returning NULL
for one reason and one reason only - It is faster
during run-time

Quoted 7 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 6 lines

Quoted 6 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar: if (!size)

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

Quoted 6 lines

Quoted 4 lines

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Can't GCC track it?

Track what? NULL ptrs? I don't think so. Possibly when you have a static NULL ptr but not in the general case.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Well of course.

What did you mean then with "Can't GCC track it?" then? Just a bad joke?

Never mind, didn't finish my train of thought.

I almost figured that ...

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

I am getting tired of this discussion now. I am just trying to tell you that no sane impl. of malloc() these days return NULL for malloc(0).

And I got your point. Though for u-boot, this would be the best solution actually. Anyone who uses memory allocated by malloc(0) is insane.

No, you don't get the point. If you did you would not have have made the "insane" remark.

Quoted 4 lines

Quoted 1 line

No, relying on malloc(0) returning something sane is messed up.

Depends, if writing generic code for lots of OS:es you cannot rely malloc(0). Writing kernel code you can.

No you cannot. It's in the spec you cannot and you have to behave according to the spec, not according to kernel.

Quoted 5 lines

Not to mention those devs that
don't
know better and just assumes that what works in glibc/kernel works every where.

Well, they will be taught it's not like that. Are we gonna support programmers who write crap code or what?

Quoted 3 lines

From Scotts example we already know there is kernel code that relies on malloc(0) not returning NULL.

Sure, but that means the code is messed up.

Quoted 4 lines

Your argument seems to boil down to "relying on malloc(0) returning something sane is messed up" so therefore u-boot malloc should take the easy route and just return NULL for malloc(0).

Basically, yes. It's correct according to the spec and we're not writing on operating system here, it's still a bootloader, so KISS.

Marek Vasut <[email protected]> wrote on 2012/04/02 20:00:03:

Quoted 6 lines

Dear Joakim Tjernlund,

Quoted 2 lines

Depends, if writing generic code for lots of OS:es you cannot rely malloc(0). Writing kernel code you can.

No you cannot. It's in the spec you cannot and you have to behave according to the spec, not according to kernel.

How so? The kernel is its own system and has it own rules and it is wise to follow them.

Quoted 4 lines

Quoted 2 lines

From Scotts example we already know there is kernel code that relies on malloc(0) not returning NULL.

Sure, but that means the code is messed up.

ohh, I don't think the kernel people will agree: http://lwn.net/Articles/236920/
But feel free to bring it up.

Quoted 10 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 20:00:03:

Quoted 6 lines

Dear Joakim Tjernlund,

Quoted 2 lines

Depends, if writing generic code for lots of OS:es you cannot rely malloc(0). Writing kernel code you can.

No you cannot. It's in the spec you cannot and you have to behave according to the spec, not according to kernel.

How so? The kernel is its own system and has it own rules and it is wise to follow them.

correct

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

From Scotts example we already know there is kernel code that relies on malloc(0) not returning NULL.

Sure, but that means the code is messed up.

ohh, I don't think the kernel people will agree: http://lwn.net/Articles/236920/
But feel free to bring it up.

i dislike the malloc(0) returning valid memory, but i'm fine with the ZERO_SIZE_PTR idea. i think we'd have to delegate this to arches though to pick a pointer that'd work for them ... certainly the kernel definition won't work for us:
#define ZERO_SIZE_PTR ((void *)16)

address 0 and higher is valid memory on many platforms. for Blackfin systems, (-16) should work.

Marek Vasut <[email protected]> wrote on 2012/04/02 20:00:03:

Quoted 14 lines

Dear Joakim Tjernlund,

Quoted 12 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 18:39:33:

Quoted 11 lines

From: Marek Vasut <[email protected]>

Dear Joakim Tjernlund,

Quoted 7 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 17:23:03:

Quoted 6 lines

Dear Joakim Tjernlund,

Quoted 4 lines

Marek Vasut <[email protected]> wrote on 2012/04/02 16:42:30:

Quoted 3 lines

Dear Joakim Tjernlund,

Quoted 1 line

Marek Vasut <[email protected]> wrote on 2012/04/02

Quoted 22 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Dear Joakim Tjernlund,

Quoted 3 lines

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02

09:17:44:

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 4 lines

Quoted 4 lines

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <[email protected]>

Quoted 4 lines · wrote:

Quoted 4 lines

Quoted 4 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
<[email protected]>

Quoted 3 lines · wrote:

Quoted 3 lines

Quoted 3 lines

Dear Mike Frysinger,

On Sunday 01 April 2012 20:25:44 Graeme Russ

Quoted 93 lines

Quoted 93 lines

Quoted 71 lines

Quoted 71 lines

Quoted 71 lines

Quoted 70 lines

Quoted 61 lines

Quoted 61 lines

Quoted 60 lines

Quoted 49 lines

Quoted 30 lines

Quoted 30 lines

b) The code calling malloc(0) is making a
perfectly legitimate assumption

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is
implementation defined (so it may return a
unique address, or it may return NULL). no
userspace code assuming malloc(0) will return
non-NULL is correct.

Which is your implementation-defined ;-) But I
have to agree with this one. So my vote is for
returning NULL.

Also, no userspace code assuming malloc(0) will
return NULL is correct

Point being, no matter which implementation is
chosen, it is up to the caller to not assume that
the choice that was made was, in fact, the choice
that was made.

I.e. the behaviour of malloc(0) should be able to
be changed on a whim with no side-effects

So I think I should change my vote to returning
NULL for one reason and one reason only - It is
faster during run-time

Quoted 7 lines

Quoted 2 lines

Then u-boot will be incompatible with both glibc
and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 6 lines

Quoted 6 lines

to me that any modern impl. of malloc(0) will
return a non NULL ptr.

It does need to be slower, just return ~0 instead,
the kernel does something similar: if (!size)

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

But kernel has something mapped there to trap these pointers I believe.

Quoted 6 lines

Quoted 4 lines

So? That only means that the kernel has extra protection if someone tries to deference such a ptr. You are not required to do that(nice to have though) You don have any protection for deferencing NULL either I think?

Can't GCC track it?

Track what? NULL ptrs? I don't think so. Possibly when you have a static NULL ptr but not in the general case.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Well of course.

What did you mean then with "Can't GCC track it?" then? Just a bad joke?

Never mind, didn't finish my train of thought.

I almost figured that ...

Quoted 12 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

I am getting tired of this discussion now. I am just trying to tell you that no sane impl. of malloc() these days return NULL for malloc(0).

And I got your point. Though for u-boot, this would be the best solution actually. Anyone who uses memory allocated by malloc(0) is insane.

No, you don't get the point. If you did you would not have have made the "insane" remark.

No, relying on malloc(0) returning something sane is messed up.

Quoted 5 lines

Quoted 2 lines

Depends, if writing generic code for lots of OS:es you cannot rely malloc(0). Writing kernel code you can.

No you cannot. It's in the spec you cannot and you have to behave according to the spec, not according to kernel.

How so? The kernel is its own system and has it own rules and it is wise to follow them.

Quoted 7 lines

Quoted 4 lines

Not to mention those devs that
don't
know better and just assumes that what works in glibc/kernel works every where.

Well, they will be taught it's not like that. Are we gonna support programmers who write crap code or what?

You do either way, now you support those who assume malloc(0) returns NULL

Quoted 4 lines

Quoted 2 lines

From Scotts example we already know there is kernel code that relies on malloc(0) not returning NULL.

Sure, but that means the code is messed up.

ohh, I don't think the kernel people will agree:
http://lwn.net/Articles/236920/ But feel free to bring it up.

Quoted 6 lines

Quoted 3 lines

Your argument seems to boil down to "relying on malloc(0) returning something sane is messed up" so therefore u-boot malloc should take the easy route and just return NULL for malloc(0).

Basically, yes. It's correct according to the spec and we're not writing on operating system here, it's still a bootloader, so KISS.

Right, it is a boot loader and it reuses code from both kernel and the open source community in general. So KISS here would be to follow suit.

Jocke

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 31 lines

Hi Joakim,

Quoted 28 lines · Joakim Tjernlund

Quoted 28 lines

Hi Marek,

Quoted 5 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 3 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 6 lines

Quoted 5 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar:
if (!size)

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

From: Graeme Russ <[email protected]>

Quoted 45 lines · Joakim Tjernlund

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 31 lines

Hi Joakim,

Quoted 28 lines · Joakim Tjernlund

Quoted 28 lines

Hi Marek,

Quoted 5 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 3 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 8 lines

Quoted 6 lines

Quoted 5 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar:
if (!size)

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

As per the spec:

The malloc function returns either a null pointer or a pointer to the allocated space.

The amount of storage allocated by a successful call to the calloc, malloc, or realloc function when 0 bytes was requested (7.22.3).

The way I read that, if NULL is not returned, then what is returned is a pointer to allocated space. If malloc(0) is called, the amount of space allocated is not determined by the spec

Graeme Russ <[email protected]> wrote on 2012/04/02 22:28:46:

Quoted 9 lines

From: Graeme Russ <[email protected]>

Quoted 6 lines · Joakim Tjernlund

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 3 lines

Hi Joakim,
On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" <

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Hi Marek,

On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut <[email protected]>

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Dear Mike Frysinger,

Quoted 2 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 1 line

b) The code calling malloc(0) is making a perfectly legitimate

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

based on how glibc handles malloc(0)

not really. POSIX says malloc(0) is implementation defined (so

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

return a unique address, or it may return NULL). no userspace

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Point being, no matter which implementation is chosen, it is up to

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

caller to not assume that the choice that was made was, in fact,

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

with no side-effects

So I think I should change my vote to returning NULL for one

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

one reason only - It is faster during run-time

Then u-boot will be incompatible with both glibc and the linux

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it

Quoted 2 lines

Quoted 2 lines

Well, u-boot borrows code from both kernel and user space so it would

Quoted 1 line

Quoted 1 line

malloc(0) behaved the same. Especially for kernel code which tend to

Quoted 5 lines

Quoted 5 lines

kernels impl.(just look at Scotts example)

Quoted 3 lines

Quoted 3 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

if (!size)

    return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is

Quoted 2 lines

Quoted 2 lines

It doesn't not have to be allocated memory, just a ptr != NULL which

Quoted 7 lines

As per the spec:

The malloc function returns either a null pointer or a pointer to the allocated space.

The amount of storage allocated by a successful call to the calloc,

Quoted 5 lines

or realloc function when 0 bytes was requested (7.22.3).

The way I read that, if NULL is not returned, then what is returned is a pointer to allocated space. If malloc(0) is called, the amount of space allocated is not determined by the spec

Please read http://lwn.net/Articles/236920/
They have a different view.

Quoted 67 lines

Graeme Russ <[email protected]> wrote on 2012/04/02 22:28:46:

Quoted 65 lines

From: Graeme Russ <[email protected]>

Quoted 45 lines · Joakim Tjernlund

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 31 lines

Hi Joakim,

Quoted 28 lines · Joakim Tjernlund

Quoted 28 lines

Hi Marek,

Quoted 5 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 3 lines · On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:

Quoted 2 lines

b) The code calling malloc(0) is making a perfectly legitimate assumption

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

? ?based on how glibc handles malloc(0)

not really. ?POSIX says malloc(0) is implementation defined (so it may return a unique address, or it may return NULL). ?no userspace code assuming malloc(0) will return non-NULL is correct.

Which is your implementation-defined ;-) But I have to agree with this one. So my vote is for returning NULL.

Also, no userspace code assuming malloc(0) will return NULL is correct

Point being, no matter which implementation is chosen, it is up to the caller to not assume that the choice that was made was, in fact, the choice that was made.

I.e. the behaviour of malloc(0) should be able to be changed on a whim with no side-effects

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

So I think I should change my vote to returning NULL for one reason and one reason only - It is faster during run-time

Then u-boot will be incompatible with both glibc and the linux kernel, it seems

Forget aboug other implementations...
What matters is that the fact that the behaviour is undefined and it is up to the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make sense if malloc(0) behaved the same. Especially for kernel code which tend to depend on the kernels impl.(just look at Scotts example)

Quoted 8 lines

Quoted 6 lines

Quoted 5 lines

to me that any modern impl. of malloc(0) will return a non NULL ptr.

It does need to be slower, just return ~0 instead, the kernel does something similar:
?if (!size)
? ? return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

As per the spec:

The malloc function returns either a null pointer or a pointer to the allocated space.

The amount of storage allocated by a successful call to the calloc, malloc, or realloc function when 0 bytes was requested (7.22.3).

Quoted 6 lines

Quoted 3 lines

The way I read that, if NULL is not returned, then what is returned is a pointer to allocated space. If malloc(0) is called, the amount of space allocated is not determined by the spec

Please read http://lwn.net/Articles/236920/
They have a different view.

Yes, I read that. They also have a compelling argument.
Bottom line is, all three solutions are valid because, at the end of the day, it's up to the caller to handle the unspecified behaviour.

Graeme Russ <[email protected]> wrote on 2012/04/02 22:59:57:

Quoted 11 lines · Joakim Tjernlund

Quoted 8 lines

Graeme Russ <[email protected]> wrote on 2012/04/02 22:28:46:

Quoted 6 lines

From: Graeme Russ <[email protected]>

Quoted 3 lines · Joakim Tjernlund

Hi Grame

Graeme Russ <[email protected]> wrote on 2012/04/02 09:17:44:

Quoted 18 lines

Quoted 18 lines

Quoted 9 lines

Quoted 3 lines

Quoted 1 line

That could work, but technically I don't think it complies as it is not a pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do free() on.

As per the spec:

The malloc function returns either a null pointer or a pointer to the allocated space.

Quoted 6 lines

The amount of storage allocated by a successful call to the calloc, malloc, or realloc function when 0 bytes was requested (7.22.3).

The way I read that, if NULL is not returned, then what is returned is a pointer to allocated space. If malloc(0) is called, the amount of space allocated is not determined by the spec

Please read http://lwn.net/Articles/236920/
They have a different view.

Quoted 2 lines

Yes, I read that. They also have a compelling argument.
Bottom line is, all three solutions are valid because, at the end of the day, it's up to the caller to handle the unspecified behaviour.

If you write code in general yes, for kernel no. We also know that many devs. doesn't know there is a difference.
This is not really the question here though. It is: what method should u-boot malloc impl.? I say that selecting NULL is the worst(in this long thread I have motivated why too)

Hi Jocke

And I really need to check, but I have a sneaking suspicion that as the code currently stands in U-Boot/x86 dereferencing a NULL pointer won't cause an exception. In x86, U-Boot configures all protected mode segments to be 4GB starting at physical address 0x00000000 with no virtual address translation. Accessing physical address 0x00000000 is just as valid as accessing 0x00000001 (or any other address).

Now if I set segments to start at 0x00000002 then I can trap a segmentation fault for accesses to 0x00000000 (NULL) and 0x00000001 (malloc(0) pointer)

That will mean that U-Boot cannot ever access those two bytes of memory, but I doubt that I would ever want to. And I will need to set the segments to base address 0x00000000 before jumping into Linux...

Quoted 9 lines

Hi Jocke

And I really need to check, but I have a sneaking suspicion that as the code currently stands in U-Boot/x86 dereferencing a NULL pointer won't cause an exception. In x86, U-Boot configures all protected mode segments to be 4GB starting at physical address 0x00000000 with no virtual address translation. Accessing physical address 0x00000000 is just as valid as accessing 0x00000001 (or any other address).

Quoted 7 lines

Now if I set segments to start at 0x00000002 then I can trap a segmentation fault for accesses to 0x00000000 (NULL) and 0x00000001 (malloc(0) pointer)

That will mean that U-Boot cannot ever access those two bytes of memory, but I doubt that I would ever want to. And I will need to set the segments to base address 0x00000000 before jumping into Linux...

OK, this is not as easy as it sounds. Detecting NULL pointer dereferences will involve enabling paging[1] which is something I really do not want to do in U-Boot. Flat Protected Mode with a 4GB linear map is perfectly fit for purpose, and that is how the Linux kernel expects things to be configured so it will be a major PITA to change.

In short, returning non-NULL from malloc(0) and expecting a CPU exception when it is de-referenced is not going to fly.

If we choose this path, at least put a debug() statement in to warn when malloc(0) is called.

Regards,

Graeme

[1] Apparently the way do do it is to reserve the entire first 4kB page and mark it as 'not-present' so any access causes a page-fault.

Dear Graeme Russ,

Quoted 4 lines · Graeme Russ

Quoted 3 lines

Hi Jocke

And I really need to check, but I have a sneaking suspicion that as

Quoted 1 line

Quoted 1 line

code currently stands in U-Boot/x86 dereferencing a NULL pointer

Quoted 1 line

Quoted 1 line

cause an exception. In x86, U-Boot configures all protected mode

Quoted 1 line

Quoted 1 line

to be 4GB starting at physical address 0x00000000 with no virtual

Quoted 1 line

Quoted 1 line

translation. Accessing physical address 0x00000000 is just as valid

Quoted 7 lines

Quoted 7 lines

accessing 0x00000001 (or any other address).

Now if I set segments to start at 0x00000002 then I can trap a segmentation fault for accesses to 0x00000000 (NULL) and 0x00000001 (malloc(0) pointer)

That will mean that U-Boot cannot ever access those two bytes of

Quoted 4 lines

Quoted 2 lines

but I doubt that I would ever want to. And I will need to set the segments to base address 0x00000000 before jumping into Linux...

OK, this is not as easy as it sounds. Detecting NULL pointer

Quoted 1 line

will involve enabling paging[1] which is something I really do not

Quoted 1 line

do in U-Boot. Flat Protected Mode with a 4GB linear map is perfectly

Quoted 4 lines

for purpose, and that is how the Linux kernel expects things to be configured so it will be a major PITA to change.

In short, returning non-NULL from malloc(0) and expecting a CPU

Quoted 3 lines

when it is de-referenced is not going to fly.

If we choose this path, at least put a debug() statement in to warn

Quoted 7 lines

malloc(0) is called.

Regards,

Graeme

[1] Apparently the way do do it is to reserve the entire first 4kB

Quoted 1 line

mark it as 'not-present' so any access causes a page-fault.

Ok, I don't mean to reopen this can of worms again ... but what're we

do about this patch?

Quoted 1 line

do about this patch?

Skip the idea to protect a page, this is too complicated for a boot loader. Just
treat malloc(0) as malloc(1) internally.

Dear Joakim Tjernlund,

[...]

Quoted 5 lines

Quoted 1 line

do about this patch?

Skip the idea to protect a page, this is too complicated for a boot loader. Just
treat malloc(0) as malloc(1) internally.

I was more interested in knowing if we should drop the patch or what ...

Quoted 3 lines

In short, returning non-NULL from malloc(0) and expecting a CPU exception when it is de-referenced is not going to fly.

Quoted 2 lines

[1] Apparently the way do do it is to reserve the entire first 4kB page and mark it as 'not-present' so any access causes a page-fault.

Ok, I don't mean to reopen this can of worms again ... but what're we going to do about this patch?

Dear Marek Vasut,

Quoted 3 lines · In message <[email protected]> you wrote:

Quoted 3 lines

In short, returning non-NULL from malloc(0) and expecting a CPU exception when it is de-referenced is not going to fly.

We should not expect to have support for any exceptions for any kind of illegal accesses. In general, behaviours is undetermined.

Quoted 5 lines

Quoted 2 lines

[1] Apparently the way do do it is to reserve the entire first 4kB page and mark it as 'not-present' so any access causes a page-fault.

Ok, I don't mean to reopen this can of worms again ... but what're we going to do about this patch?

NAK it.

It is perfectly valid on most systems to dereference a pointer to address 0 (which in almost all cases looks the same as a NULL pointer).

I object against patches that will make access to this data impossible (or even more complicated than it is now).

        if ((long)bytes == 0) {
                DEBUG("Warning: malloc of zero block size\n");
                bytes = 1;
        } else if ((long)bytes < 0) {
                DEBUG("Error: malloc of negative block size\n");
                return 0;
        }

Quoted 5 lines

        if ((long)bytes == 0) {
        
                DEBUG("Warning: malloc of zero block size\n");
                bytes = 1;

Quoted 6 lines

        } else if ((long)bytes < 0) {
        
                DEBUG("Error: malloc of negative block size\n");
                return 0;
        
        }

this should be (ssize_t) casts, not (long)

-mike

Quoted 8 lines

Wolfgang Denk wrote on 2010/10/21 13:32:54:

Quoted 7 lines

Quoted 5 lines · Joakim Tjernlund you

common/dlmalloc.c Void_t* mALLOc(bytes) size_t bytes; · line 2185

Quoted 2 lines

common/dlmalloc.c +1 -1

-  if ((long)bytes < 0) return 0;
+  if ((long)bytes <= 0) return 0;

I think you should return some impossible ptr value =! NULL Size 0 not really an error.

Quoted 4 lines

Quoted 2 lines

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Yes, but not very useful. Glibc does not return NULL

it is useful for malloc(0) == NULL. the glibc behavior is downright obnoxious. we disable this for uClibc and dont see problems. if

catch accidental programming mistakes which then get fixed.

why exactly do you want malloc(0) to return valid memory ? i would

have u-boot return an error.

Mike Frysinger <[email protected]> wrote on 2010/10/21 21:51:53:

Quoted 5 lines · On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote:

Quoted 4 lines

Wolfgang Denk wrote on 2010/10/21 13:32:54:

Quoted 3 lines

Quoted 2 lines · Joakim Tjernlund you

Quoted 2 lines

common/dlmalloc.c +1 -1

-  if ((long)bytes < 0) return 0;
+  if ((long)bytes <= 0) return 0;

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

I think you should return some impossible ptr value =! NULL Size 0 not really an error.

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Yes, but not very useful. Glibc does not return NULL

it is useful for malloc(0) == NULL. the glibc behavior is downright obnoxious. we disable this for uClibc and dont see problems. if

anything, we

Quoted 1 line

catch accidental programming mistakes which then get fixed.

There is a value in having the possibility to express a
0 bytes data set. Consider this simple example:
An app read lines from a file and mallocs each line read and builds an array with malloced pointers. The last entry is a NULL ptr to signal EOF. This breaks down for empty lines if malloc(0) returns NULL.

Not to mention error handling, as I recall, a malloc(0) that returns NULL does not set errno which screws error handling. One have to bend over just to cope with this.

Quoted 1 line

why exactly do you want malloc(0) to return valid memory ? i would

rather

Quoted 1 line

have u-boot return an error.

Ideally it should return a ptr to invalid memory so you get a SEGV if you try to defer the ptr but I take anything over a NULL ptr.

Dear Joakim Tjernlund,

Quoted 6 lines

Mike Frysinger <[email protected]> wrote on 2010/10/21 21:51:53:

Quoted 5 lines · On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote:

Quoted 4 lines

Wolfgang Denk wrote on 2010/10/21 13:32:54:

Quoted 3 lines

Quoted 2 lines · Joakim Tjernlund you

Quoted 2 lines

(quoted diff) +1 -1

-  if ((long)bytes < 0) return 0;
+  if ((long)bytes <= 0) return 0;

Quoted 9 lines

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

I think you should return some impossible ptr value =! NULL Size 0 not really an error.

It is legal for malloc() to return NULL in case of size==0, and for the sake of simplicity I recommend we do just that.

Yes, but not very useful. Glibc does not return NULL

it is useful for malloc(0) == NULL. the glibc behavior is downright obnoxious. we disable this for uClibc and dont see problems. if

anything, we

Quoted 1 line

catch accidental programming mistakes which then get fixed.

My five cents:

Quoted 6 lines

There is a value in having the possibility to express a
0 bytes data set. Consider this simple example:
An app read lines from a file and mallocs each line read and builds an array with malloced pointers. The last entry is a NULL ptr to signal EOF. This breaks down for empty lines if malloc(0) returns NULL.

Your example is in the right way, but a bit flawed in its simplicity. Even empty lines need some form of information that they are of length

be it a 0x00 in the memory line itself (requiring malloc(length+1)) or

information in a variable somewhere else:

struct line {
   byte *buf;
   int length;
} lines[...];

As an (undercover) Mathematician:
Out of principle I would say that malloc(0) should return a non-NULL pointer of an area where exactly 0 bytes may be used. And, of course, free() of that area shall not fail or crash the system.

Quoted 1 line

Not to mention error handling, as I recall, a malloc(0) that returns

Quoted 6 lines

does not set errno which screws error handling. One have to bend over just to cope with this.

Quoted 1 line

why exactly do you want malloc(0) to return valid memory ? i would

rather

Quoted 1 line

have u-boot return an error.

In the case of u-boot, where a driver or whatever should never really

to allocate zero memory, such a programming error should be made obvious

at least a warning message.

Quoted 2 lines

Ideally it should return a ptr to invalid memory so you get a SEGV if

Quoted 1 line

try to defer the ptr but I take anything over a NULL ptr.

Makes sense only if any access outside of any allocated memory would

the same, otherwise this is a special case again.

Mike Frysinger wrote on 2010/10/21 21:51:53:

Quoted 3 lines

it is useful for malloc(0) == NULL. the glibc behavior is downright obnoxious. we disable this for uClibc and dont see problems. if anything, we catch accidental programming mistakes which then get fixed.

There is a value in having the possibility to express a
0 bytes data set. Consider this simple example:
An app read lines from a file and mallocs each line read and builds an array with malloced pointers. The last entry is a NULL ptr to signal EOF. This breaks down for empty lines if malloc(0) returns NULL.

Not to mention error handling, as I recall, a malloc(0) that returns NULL does not set errno which screws error handling. One have to bend over just to cope with this.

Quoted 2 lines

why exactly do you want malloc(0) to return valid memory ? i would rather have u-boot return an error.

Ideally it should return a ptr to invalid memory so you get a SEGV if you try to defer the ptr but I take anything over a NULL ptr.

Quoted 4 lines

Mike Frysinger wrote on 2010/10/21 21:51:53:

Quoted 3 lines

it is useful for malloc(0) == NULL. the glibc behavior is downright obnoxious. we disable this for uClibc and dont see problems. if anything, we catch accidental programming mistakes which then get

Quoted 7 lines

There is a value in having the possibility to express a
0 bytes data set. Consider this simple example:
An app read lines from a file and mallocs each line read and builds an array with malloced pointers. The last entry is a NULL ptr to signal EOF. This breaks down for empty lines if malloc(0) returns NULL.

i dont think so ... C strings are always at least one byte, so an empty

would be malloc(1)

Quoted 2 lines

Not to mention error handling, as I recall, a malloc(0) that returns

Quoted 2 lines

does not set errno which screws error handling. One have to bend over just to cope with this.

that depends on your implementation. in u-boot, there really is no

concept. but i dont see how this matters as i dont see any example in

context where malloc(0) is a problem.

Quoted 5 lines

Quoted 3 lines

why exactly do you want malloc(0) to return valid memory ? i would rather have u-boot return an error.

Ideally it should return a ptr to invalid memory so you get a SEGV if

Quoted 1 line

try to defer the ptr but I take anything over a NULL ptr.

the concept of an invalid pointer is pretty arch-specific. and it

semantics of what the vast majority of coders (and their code) out there

expect -- NULL means error while non-NULL means success.

a better question might be "why isnt a NULL pointer on your platform an invalid pointer" ? ive added a simple CONFIG define for Blackfin users

just that -- make access to the low 1KiB of memory generate an

does so with pretty much 0 runtime overhead.

Mike Frysinger wrote on 2010/10/22 09:20:22:

Quoted 6 lines · On Friday, October 22, 2010 02:10:16 Joakim Tjernlund wrote:

Quoted 2 lines

does not set errno which screws error handling. One have to bend over just to cope with this.

that depends on your implementation. in u-boot, there really is no "errno"

Yes, and that and that is even worse. How do you tell if you are out of memory or not? Checking size == 0 after the fact? Then you could do that before calling malloc in the first place.

Quoted 3 lines

the concept of an invalid pointer is pretty arch-specific. and it changes the semantics of what the vast majority of coders (and their code) out there expect -- NULL means error while non-NULL means success.

hardly as glibc returns a non NULL ptr. Changing this would probably break apps, making them think they are out of memory.

non null still what it is supposed to mean, you successfully allocated 0 bytes.

Quoted 4 lines

a better question might be "why isnt a NULL pointer on your platform an invalid pointer" ? ive added a simple CONFIG define for Blackfin users to do just that -- make access to the low 1KiB of memory generate an exception. it does so with pretty much 0 runtime overhead.

You lost me here. How does this relate to the issue before us?

Quoted 3 lines

Mike Frysinger wrote on 2010/10/22 09:20:22:

Quoted 2 lines · On Friday, October 22, 2010 02:10:16 Joakim Tjernlund wrote:

Quoted 1 line

does not set errno which screws error handling. One have to bend

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

just to cope with this.

that depends on your implementation. in u-boot, there really is no "errno"

Yes, and that and that is even worse. How do you tell if you are out

Quoted 1 line

memory or not? Checking size == 0 after the fact? Then you could do

Quoted 1 line

before calling malloc in the first place.

i still dont see any real world (or even theoretical) need for

the issue of error checking is irrelevant until you can come up with

Quoted 2 lines

Quoted 2 lines

the concept of an invalid pointer is pretty arch-specific. and it

Quoted 1 line

Quoted 1 line

the semantics of what the vast majority of coders (and their code)

Quoted 4 lines

Quoted 1 line

there expect -- NULL means error while non-NULL means success.

hardly as glibc returns a non NULL ptr. Changing this would probably break apps, making them think they are out of memory.

funny because i have no problem running software on top of uClibc. and

does do malloc(0) == NULL.

just visit http://wh0rd.org/ and marvel at all the software running

fine on uClibc. apache/openssh/openvpn/php/gd/git/svn/...

Quoted 2 lines

non null still what it is supposed to mean, you successfully allocated 0 bytes.

POSIX clearly labels it "implementation defined" which means "no sane

programmer may rely on its behavior"

Quoted 2 lines

Quoted 2 lines

a better question might be "why isnt a NULL pointer on your platform

Quoted 1 line

Quoted 1 line

invalid pointer" ? ive added a simple CONFIG define for Blackfin

Quoted 4 lines

Quoted 2 lines

to do just that -- make access to the low 1KiB of memory generate an exception. it does so with pretty much 0 runtime overhead.

You lost me here. How does this relate to the issue before us?

you're asking for an invalid pointer. the presumption is that you want

that attempts to access it will fail. if that isnt the case, i have no

why you want malloc(0) to return an "invalid pointer" that isnt NULL.

btw, could you please fix your mailer. it constantly destroys quoted

Don't you want to know if the app screwed up or if the system is out of memory?

The only upside to malloc(0) == NULL I can see is an extra check for apps for which size == 0 is an error to the app too(something the app should have checked itself long before calling malloc).

hmm, "destroys quoted context", I think that is a new one. What exactly is destroyed?

Quoted 6 lines

Don't you want to know if the app screwed up or if the system is out of memory?

The only upside to malloc(0) == NULL I can see is an extra check for apps for which size == 0 is an error to the app too(something the app should have checked itself long before calling malloc).

if an app is doing malloc(0), it is broken. i'm really not worried at all

about detecting OOM state. my real world experience thus far has shown no actual problems with this behavior. so unless you have some actual examples where this behavior "harms" u-boot, i say we merge the OP's patch.

Quoted 3 lines

hmm, "destroys quoted context", I think that is a new one. What exactly is destroyed?

it seems it fails to rewrap quoted lines and then when other people reply, their clients arent able to recover thus screwing it up even more. pick any msg from you in this thread. like this one:

   http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/87174/focus=87290

Mike Frysinger wrote on 2010/10/22 17:18:05:

Quoted 8 lines · On Friday, October 22, 2010 04:34:52 Joakim Tjernlund wrote:

Quoted 6 lines

Don't you want to know if the app screwed up or if the system is out of memory?

The only upside to malloc(0) == NULL I can see is an extra check for apps for which size == 0 is an error to the app too(something the app should have checked itself long before calling malloc).

Quoted 2 lines

if an app is doing malloc(0), it is broken. i'm really not worried at all

In your opinion, not mine and not POSIX either. I outlined uses for malloc(0) earlier.

Quoted 4 lines

about detecting OOM state. my real world experience thus far has shown no actual problems with this behavior. so unless you have some actual examples where this behavior "harms" u-boot, i say we merge the OP's patch.

Since you think an app is broken if it does malloc(0), it should not matter what malloc(0) returns to you. You only gain an extra error check for the broken app at the expense of ease of use and sane error checking in general.

I prefer not to make it easier for broken apps when it hurts elsewhere.

Ah, IT changed some settings globally. I changed it back. I hope this reply is better.

Quoted 12 lines

Mike Frysinger wrote on 2010/10/22 17:18:05:

Quoted 10 lines · On Friday, October 22, 2010 04:34:52 Joakim Tjernlund wrote:

Quoted 6 lines

Don't you want to know if the app screwed up or if the system is out of memory?

The only upside to malloc(0) == NULL I can see is an extra check for apps for which size == 0 is an error to the app too(something the app should have checked itself long before calling malloc).

if an app is doing malloc(0), it is broken. i'm really not worried at all

Quoted 2 lines

In your opinion, not mine and not POSIX either. I outlined uses for malloc(0) earlier.

i havent seen any realistic usage examples. the only ones you quoted could easily be solved in a different way assuming they were even affected by malloc(0).

Quoted 10 lines

Quoted 5 lines

about detecting OOM state. my real world experience thus far has shown no actual problems with this behavior. so unless you have some actual examples where this behavior "harms" u-boot, i say we merge the OP's patch.

Since you think an app is broken if it does malloc(0), it should not matter what malloc(0) returns to you. You only gain an extra error check for the broken app at the expense of ease of use and sane error checking in general.

more like you notice that the code is broken right away. the few times i have seen a malloc(0), it was do to errors elsewhere in the code and once those were fixed, malloc() wasnt called with a size 0.

Quoted 1 line

I prefer not to make it easier for broken apps when it hurts elsewhere.

funny, i can use the same logic to ban malloc(0). it makes you notice & fix errors without penalties.

Quoted 3 lines

Ah, IT changed some settings globally. I changed it back. I hope this reply is better.

yes, this is much better. thanks !

Quoted 8 lines · On Friday, October 22, 2010 03:37:43 Joakim Tjernlund wrote:

Mike Frysinger wrote on 2010/10/22 09:20:22:

Quoted 6 lines · On Friday, October 22, 2010 02:10:16 Joakim Tjernlund wrote:

Quoted 2 lines

does not set errno which screws error handling. One have to bend over just to cope with this.

that depends on your implementation. in u-boot, there really is no "errno"

Quoted 3 lines

Yes, and that and that is even worse. How do you tell if you are out of memory or not? Checking size == 0 after the fact? Then you could do that before calling malloc in the first place.

i still dont see any real world (or even theoretical) need for malloc(0). so the issue of error checking is irrelevant until you can come up with one.

Quoted 3 lines · On Fri, 22 Oct 2010 03:55:49 -0400 Mike Frysinger <[email protected]> wrote:

Quoted 2 lines · On Friday, October 22, 2010 03:37:43 Joakim Tjernlund wrote:

Mike Frysinger wrote on 2010/10/22 09:20:22:

Quoted 1 line · On Friday, October 22, 2010 02:10:16 Joakim Tjernlund wrote:

You couldn't do this in portable code, since malloc(0) is allowed to return NULL, and it wouldn't be hard to work around it by checking prop->len for zero. But it is a use case where malloc(0) returning non-NULL is convenient.

I don't think Joakim's suggestion of a single "impossible_ptr" is compliant, though -- it's supposed to be either NULL or a *unique* pointer.