www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.allocator.allocate(0) -> return null or std.allocator.allocate(1)?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
This is a matter with some history behind it. In C, malloc(0) always 
returns a new, legit pointer that can be subsequently reallocated, freed 
etc. What most malloc() implementations practically do in their first 
line is:

if (size == 0) size = 1;

and take it from there.

The reasoning was to make failure of malloc easy to test for. This would 
suffice:

size_t s;
...
void* p = malloc(s);
if (!p) {
    ... failed! ...
}

as opposed to:

if (!p && s) {
    ... failed! ...
}

That kinda makes sense, but it's not super consistent. For example, 
realloc() does not obey the same protocol. Calling realloc() with a new 
size of 0 actually free()s the pointer and then returns null.

Anyhow, on to D. In D it's easy to test whether an allocation succeeded:

auto buf = alloc.allocate(s);
if (buf.length != s) {
     ... failed! ...
}

It is a bit subtle, but I think overall it makes everyone's life easier. 
Thoughts?


Andrei
May 15 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 9:36 AM, Andrei Alexandrescu wrote:

 Anyhow, on to D.


To clarify: I want to request all allocators to return null if asked for 
zero bytes. -- Andrei
May 15 2015
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc. What most malloc() implementations 
 practically do in their first line is:

 if (size == 0) size = 1;

 and take it from there.

 The reasoning was to make failure of malloc easy to test for. 
 This would suffice:

 size_t s;
 ...
 void* p = malloc(s);
 if (!p) {
    ... failed! ...
 }

 as opposed to:

 if (!p && s) {
    ... failed! ...
 }

 That kinda makes sense, but it's not super consistent. For 
 example, realloc() does not obey the same protocol. Calling 
 realloc() with a new size of 0 actually free()s the pointer and 
 then returns null.

 Anyhow, on to D. In D it's easy to test whether an allocation 
 succeeded:

 auto buf = alloc.allocate(s);
 if (buf.length != s) {
     ... failed! ...
 }

 It is a bit subtle, but I think overall it makes everyone's 
 life easier. Thoughts?


 Andrei


There is a third option: return a non-null yet invalid pointer 
(e.g. 0x1) that is used exclusively for empty allocations.

This allows the if(p) pattern and elides the cost of allocating 
one byte, however it complicates allocator code a bit (resizing, 
freeing needs to know about this magic pointer), and breaks the 
contract malloc(size)!=malloc(size).
May 15 2015
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc. What most malloc() implementations 
 practically do in their first line is:

 if (size == 0) size = 1;

 and take it from there.

 The reasoning was to make failure of malloc easy to test for. 
 This would suffice:

 size_t s;
 ...
 void* p = malloc(s);
 if (!p) {
    ... failed! ...
 }

 as opposed to:

 if (!p && s) {
    ... failed! ...
 }

 That kinda makes sense, but it's not super consistent. For 
 example, realloc() does not obey the same protocol. Calling 
 realloc() with a new size of 0 actually free()s the pointer and 
 then returns null.

 Anyhow, on to D. In D it's easy to test whether an allocation 
 succeeded:

 auto buf = alloc.allocate(s);
 if (buf.length != s) {
     ... failed! ...
 }

 It is a bit subtle, but I think overall it makes everyone's 
 life easier. Thoughts?


Not necessarily a good idea, but there's a third option:

     return cast(void*) -1;

Or some other arbitrary non-zero value.
May 15 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 15 May 2015 at 16:43:35 UTC, Marc Schütz wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu 
 wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc. What most malloc() implementations 
 practically do in their first line is:

 if (size == 0) size = 1;

 and take it from there.

 The reasoning was to make failure of malloc easy to test for. 
 This would suffice:

 size_t s;
 ...
 void* p = malloc(s);
 if (!p) {
   ... failed! ...
 }

 as opposed to:

 if (!p && s) {
   ... failed! ...
 }

 That kinda makes sense, but it's not super consistent. For 
 example, realloc() does not obey the same protocol. Calling 
 realloc() with a new size of 0 actually free()s the pointer 
 and then returns null.

 Anyhow, on to D. In D it's easy to test whether an allocation 
 succeeded:

 auto buf = alloc.allocate(s);
 if (buf.length != s) {
    ... failed! ...
 }

 It is a bit subtle, but I think overall it makes everyone's 
 life easier. Thoughts?


 Not necessarily a good idea, but there's a third option:

     return cast(void*) -1;

 Or some other arbitrary non-zero value.


Ha! Two fools, one thought :-)
May 15 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 9:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 Ha! Two fools, one thought :-)


It's a nice idea but as Vladimir mentioned expand(), reallocate(), 
free() - all need now to worry about checking two singular values 
instead of one.

Since there's a long-established tradition that reallocate() and free() 
accept a null pointer, we can't (and probably shouldn't) change that. So 
I'm thinking in a way null as a singular value comes for "free".


Andrei
May 15 2015
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 15 May 2015 at 17:01:26 UTC, Andrei Alexandrescu wrote:

 On 5/15/15 9:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
 <schuetzm gmx.net>" wrote:

 Ha! Two fools, one thought :-)


 It's a nice idea but as Vladimir mentioned expand(), 
 reallocate(), free() - all need now to worry about checking two 
 singular values instead of one.

 Since there's a long-established tradition that reallocate() 
 and free() accept a null pointer, we can't (and probably 
 shouldn't) change that. So I'm thinking in a way null as a 
 singular value comes for "free".


Yes, and std.allocator is a new piece of software, which means we 
can choose what makes sense and don't need to worry about 
compatibility. It just needs to be clearly defined.
May 15 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 15 May 2015 at 17:01:26 UTC, Andrei Alexandrescu wrote:

 Since there's a long-established tradition that reallocate() 
 and free() accept a null pointer,


Question, is there a strong rationale for this? The usefulness is 
obvious if malloc(0) returns null, but otherwise, attempting to 
free a resource that has never been created usually indicates a 
bug.
May 15 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 6:56 PM, Vladimir Panteleev wrote:

 On Friday, 15 May 2015 at 17:01:26 UTC, Andrei Alexandrescu wrote:

 Since there's a long-established tradition that reallocate() and
 free() accept a null pointer,


 Question, is there a strong rationale for this? The usefulness is
 obvious if malloc(0) returns null, but otherwise, attempting to free a
 resource that has never been created usually indicates a bug.


Yah, you don't want to special case null everywhere: cleanup functions, 
destructors, etc. etc. If deallocation wouldn't accept the null pointer, 
"if (p) free(p);" would cause carpal tunnel syndrome. -- Andrei
May 15 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 16 May 2015 at 02:05:22 UTC, Andrei Alexandrescu 
wrote:

 Question, is there a strong rationale for this? The usefulness 
 is
 obvious if malloc(0) returns null, but otherwise, attempting 
 to free a
 resource that has never been created usually indicates a bug.


 Yah, you don't want to special case null everywhere: cleanup 
 functions, destructors, etc. etc. If deallocation wouldn't 
 accept the null pointer, "if (p) free(p);" would cause carpal 
 tunnel syndrome. -- Andrei


You should, C is just not a language designed for type safety and 
correctness.
May 15 2015
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc. What most malloc() implementations 
 practically do in their first line is:

 if (size == 0) size = 1;

 and take it from there.


There are actually 2 way to do this in malloc. Either you return 
null, but then you need to be able to accept null in the free 
implementation (as malloc must return a freeable pointer) or you 
just bump to 1.

Both are valid per spec and there are implementations of malloc 
for both.
May 15 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 11:37 AM, deadalnix wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) always
 returns a new, legit pointer that can be subsequently reallocated,
 freed etc. What most malloc() implementations practically do in their
 first line is:

 if (size == 0) size = 1;

 and take it from there.


 There are actually 2 way to do this in malloc. Either you return null,
 but then you need to be able to accept null in the free implementation
 (as malloc must return a freeable pointer) or you just bump to 1.

 Both are valid per spec and there are implementations of malloc for both.


Ah, nice. I was under the misconception that malloc(0) cannot return 
null in C. Apparently it's implementation defined at least since C99, 
see http://stackoverflow.com/a/2132318/348571. Thanks!

Andrei
May 15 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 11:51 AM, Andrei Alexandrescu wrote:

 On 5/15/15 11:37 AM, deadalnix wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) always
 returns a new, legit pointer that can be subsequently reallocated,
 freed etc. What most malloc() implementations practically do in their
 first line is:

 if (size == 0) size = 1;

 and take it from there.


 There are actually 2 way to do this in malloc. Either you return null,
 but then you need to be able to accept null in the free implementation
 (as malloc must return a freeable pointer) or you just bump to 1.

 Both are valid per spec and there are implementations of malloc for both.


 Ah, nice. I was under the misconception that malloc(0) cannot return
 null in C. Apparently it's implementation defined at least since C99,
 see http://stackoverflow.com/a/2132318/348571. Thanks!


Well I added the rule that allocate(0) should return null, there are a 
few more tests but probably nothing worrisome: 
https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220

Andrei
May 15 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 15 May 2015 at 19:49:27 UTC, Andrei Alexandrescu wrote:

 Well I added the rule that allocate(0) should return null, 
 there are a few more tests but probably nothing worrisome: 
 https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220

 Andrei


I do think think this is what makes sense for us:
  - We should throw in case of error, not return null.
  - There is no point in allocating something if 0 byte are going 
to be used.

The thing we got to make sure is very clear in the spec is that 
free, realloc and so on functions are able to accept null as 
input.
May 15 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/15/2015 10:13 PM, deadalnix wrote:

 On Friday, 15 May 2015 at 19:49:27 UTC, Andrei Alexandrescu wrote:

 Well I added the rule that allocate(0) should return null, there are a
 few more tests but probably nothing worrisome:
 https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220


 Andrei


 I do think think this is what makes sense for us:
   - We should throw in case of error, not return null.


- Too much overhead, there might be a fall-back installed.
- Where do you allocate the exception object?
May 15 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 1:34 PM, Timon Gehr wrote:

 On 05/15/2015 10:13 PM, deadalnix wrote:

 On Friday, 15 May 2015 at 19:49:27 UTC, Andrei Alexandrescu wrote:

 Well I added the rule that allocate(0) should return null, there are a
 few more tests but probably nothing worrisome:
 https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220



 Andrei


 I do think think this is what makes sense for us:
   - We should throw in case of error, not return null.


 - Too much overhead, there might be a fall-back installed.
 - Where do you allocate the exception object?


Yeh, failed allocations are relatively frequent within the framework 
components. -- Andrei
May 15 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2015 6:38 PM, Andrei Alexandrescu wrote:

 Yeh, failed allocations are relatively frequent within the framework
components.


I find this surprising.
May 16 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/16/15 2:07 AM, Walter Bright wrote:

 On 5/15/2015 6:38 PM, Andrei Alexandrescu wrote:

 Yeh, failed allocations are relatively frequent within the framework
 components.


 I find this surprising.


Consider a fixed-length buffer fronting a general allocator, one of the 
simplest and most useful compositions of allocators, which I call 
FallbackAllocator:

https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/fallback_allocator.d

Once the memory in the front buffer is exhausted, the fallback allocator 
starts getting used. The correct way to handle the choice in the 
composer is to first try the front, and if it returns null, defer to the 
fallback.

Many other allocators follow similar patterns.


Andrei
May 16 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2015 9:34 AM, Andrei Alexandrescu wrote:

 On 5/16/15 2:07 AM, Walter Bright wrote:

 On 5/15/2015 6:38 PM, Andrei Alexandrescu wrote:

 Yeh, failed allocations are relatively frequent within the framework
 components.


 I find this surprising.


 Consider a fixed-length buffer fronting a general allocator, one of the
simplest
 and most useful compositions of allocators, which I call FallbackAllocator:

 https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/fallback_allocator.d


 Once the memory in the front buffer is exhausted, the fallback allocator starts
 getting used. The correct way to handle the choice in the composer is to first
 try the front, and if it returns null, defer to the fallback.

 Many other allocators follow similar patterns.


Ah, ok, that makes sense. I was thinking more in terms of the whole program 
running out of memory, not fallback.
May 16 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/16/15 1:22 PM, Walter Bright wrote:

 On 5/16/2015 9:34 AM, Andrei Alexandrescu wrote:

 Once the memory in the front buffer is exhausted, the fallback
 allocator starts
 getting used. The correct way to handle the choice in the composer is
 to first
 try the front, and if it returns null, defer to the fallback.

 Many other allocators follow similar patterns.


 Ah, ok, that makes sense. I was thinking more in terms of the whole
 program running out of memory, not fallback.


One more illustration of the same idea: just completed a larger doc.

http://erdani.com/d/phobos-prerelease/std_experimental_allocator_kernighan_ritchie.html

The Kernighan-Ritchie allocator is composed of a list of blocks, each 
organized as a free list; when one block gets exhausted, the list 
detects that and allocates more.


Andrei
May 16 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-15 22:34, Timon Gehr wrote:


 - Where do you allocate the exception object?


Per-allocated? The same way as out of memory is handled in the runtime.

-- 
/Jacob Carlborg
May 16 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/16/15 2:20 AM, Jacob Carlborg wrote:

 On 2015-05-15 22:34, Timon Gehr wrote:


 - Where do you allocate the exception object?


 Per-allocated? The same way as out of memory is handled in the runtime.


Regardless, std.allocator does not use exceptions anywhere (it is, 
however, neutral to exceptions thrown from withing e.g. constructors of 
generic types). -- Andrei
May 16 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-05-16 11:20, Jacob Carlborg wrote:


 Per-allocated? The same way as out of memory is handled in the runtime.


To avoid confusion, that should have been "pre-allocated".

-- 
/Jacob Carlborg
May 16 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 15 May 2015 at 20:34:13 UTC, Timon Gehr wrote:

 I do think think this is what makes sense for us:
  - We should throw in case of error, not return null.


 - Too much overhead, there might be a fall-back installed.
 - Where do you allocate the exception object?


if (fallbackInstalled) return fallbackAllocate();
else throw OhMyGodException();
May 16 2015
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/15/2015 09:49 PM, Andrei Alexandrescu wrote:

 On 5/15/15 11:51 AM, Andrei Alexandrescu wrote:

 On 5/15/15 11:37 AM, deadalnix wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) always
 returns a new, legit pointer that can be subsequently reallocated,
 freed etc. What most malloc() implementations practically do in their
 first line is:

 if (size == 0) size = 1;

 and take it from there.


 There are actually 2 way to do this in malloc. Either you return null,
 but then you need to be able to accept null in the free implementation
 (as malloc must return a freeable pointer) or you just bump to 1.

 Both are valid per spec and there are implementations of malloc for
 both.


 Ah, nice. I was under the misconception that malloc(0) cannot return
 null in C. Apparently it's implementation defined at least since C99,
 see http://stackoverflow.com/a/2132318/348571. Thanks!


 Well I added the rule that allocate(0) should return null, there are a
 few more tests but probably nothing worrisome:
 https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220


 Andrei


- Quantizer currently does not necessarily follow this rule.

- Might it not be surprising behaviour for AffixAllocator?
May 15 2015
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc. What most malloc() implementations 
 practically do in their first line is:

 if (size == 0) size = 1;

 and take it from there.

 The reasoning was to make failure of malloc easy to test for. 
 This would suffice:

 size_t s;
 ...
 void* p = malloc(s);
 if (!p) {
    ... failed! ...
 }

 as opposed to:

 if (!p && s) {
    ... failed! ...
 }

 That kinda makes sense, but it's not super consistent. For 
 example, realloc() does not obey the same protocol. Calling 
 realloc() with a new size of 0 actually free()s the pointer and 
 then returns null.

 Anyhow, on to D. In D it's easy to test whether an allocation 
 succeeded:

 auto buf = alloc.allocate(s);
 if (buf.length != s) {
     ... failed! ...
 }

 It is a bit subtle, but I think overall it makes everyone's 
 life easier. Thoughts?


 Andrei


How about defining `alloc.allocate(0)` to *be* an error?
May 17 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/17/2015 10:35 AM, Idan Arye wrote:

 ...

 How about defining `alloc.allocate(0)` to *be* an error?


What is bad about allocate(0)?
May 17 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 17 May 2015 at 12:09:37 UTC, Timon Gehr wrote:

 On 05/17/2015 10:35 AM, Idan Arye wrote:

 ...

 How about defining `alloc.allocate(0)` to *be* an error?


 What is bad about allocate(0)?


It's not that allocating 0 bytes is wrong by itself(at first 
glance it seemed very wrong to me, but then I remembered that you 
are never allowed to read-from or writ-to it more than 0 bytes), 
but it's how limited it's usefulness is compared to all the 
special-casing it requires, it might be better to simply disallow 
it.
May 17 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/17/15 5:27 AM, Idan Arye wrote:

 On Sunday, 17 May 2015 at 12:09:37 UTC, Timon Gehr wrote:

 On 05/17/2015 10:35 AM, Idan Arye wrote:

 ...

 How about defining `alloc.allocate(0)` to *be* an error?


 What is bad about allocate(0)?


 It's not that allocating 0 bytes is wrong by itself(at first glance it
 seemed very wrong to me, but then I remembered that you are never
 allowed to read-from or writ-to it more than 0 bytes), but it's how
 limited it's usefulness is compared to all the special-casing it
 requires, it might be better to simply disallow it.


Prolly not a good idea, 0 works well for the most part as a natural 
lower bound, e.g.:

void fun(size_t n)
{
    int[] a = theAllocator.makeArray!int(n);
    scope(exit) theAllocator.dispose(a);
    foreach (ref e; a)
    {
        ...
    }
    ....
}

Special casing code like this for n==0 (lest functions start throwing 
etc) is not a good strategy to condone.


Andrei
May 17 2015
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc.


Is the invariant malloc(0) != malloc(0) the only thing that makes 
0 a special case here?
May 17 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/17/15 7:13 AM, Peter Alexander wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) always
 returns a new, legit pointer that can be subsequently reallocated,
 freed etc.


 Is the invariant malloc(0) != malloc(0) the only thing that makes 0 a
 special case here?


I thought so, but apparently C99 _does_ allow malloc(0) to return null, 
so that's not an invariant :o).

Well for now std.allocator will go with null.


Andrei
May 17 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 17 May 2015 at 14:13:03 UTC, Peter Alexander wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu 
 wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc.


 Is the invariant malloc(0) != malloc(0) the only thing that 
 makes 0 a special case here?


Doesn't need to be, the spec only say it must be passable to free.
May 17 2015
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 17 May 2015 at 20:31:50 UTC, deadalnix wrote:

 On Sunday, 17 May 2015 at 14:13:03 UTC, Peter Alexander wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu 
 wrote:

 This is a matter with some history behind it. In C, malloc(0) 
 always returns a new, legit pointer that can be subsequently 
 reallocated, freed etc.


 Is the invariant malloc(0) != malloc(0) the only thing that 
 makes 0 a special case here?


 Doesn't need to be, the spec only say it must be passable to 
 free.


So here's my question: can we just make allocate(0) do nothing 
special? i.e. allocate a non-null, but still 0 length buffer?
May 18 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/18/15 5:16 AM, Peter Alexander wrote:

 On Sunday, 17 May 2015 at 20:31:50 UTC, deadalnix wrote:

 On Sunday, 17 May 2015 at 14:13:03 UTC, Peter Alexander wrote:

 On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:

 This is a matter with some history behind it. In C, malloc(0) always
 returns a new, legit pointer that can be subsequently reallocated,
 freed etc.


 Is the invariant malloc(0) != malloc(0) the only thing that makes 0 a
 special case here?


 Doesn't need to be, the spec only say it must be passable to free.


 So here's my question: can we just make allocate(0) do nothing special?
 i.e. allocate a non-null, but still 0 length buffer?


Yes, allocation could be rounded to whatever minimum the allocator 
supports, then a zero-length slice be taken of the result. -- Andrei
May 18 2015