Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Fully agreed. That permission has been grit in the gears for a very long
>> time, for much of which I had the misfortune of having to deal with it
>> in real life thanks to IBM’s bad decisions.
>
> Can you expand on "IBM's bad decisions"?

AIX is one of the platforms that returns NULL for malloc(0) even when
there’s some memory available (in fact the only one I know).

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>> Fully agreed. That permission has been grit in the gears for a very long
>>> time, for much of which I had the misfortune of having to deal with it
>>> in real life thanks to IBM’s bad decisions.
>>
>> Can you expand on "IBM's bad decisions"?
>
>AIX is one of the platforms that returns NULL for malloc(0) even when
>there’s some memory available (in fact the only one I know).

AIX had this odd 'overcommit' feature, which allowed the system to
overcommit memory resources. It would allocate virtual address space
(via malloc) even if there wasn't enough memory + backing store to
support it, and would take a SIGSEGV when referenced if, at the time
of reference, there was still insufficient memory and/or backing store
to support allocating a physical page to that portion of the VA space.

Linux can be configured to operate in the same way.

I don't believe AIX ever returned NULL from malloc() while still
allocating VA space for the allocation.

On 2024-01-22, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Standard C is trying to have its own cake and eat it here: 0-sized
> allocations can be represented by null pointers when it’s malloc, but
> not when it’s memcpy.

Having your cake and eating that same cake it is undefined behavior,

even with an intervening sequence point.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

scott@slp53.sl.home (Scott Lurndal) writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:

>>AIX is one of the platforms that returns NULL for malloc(0) even when
>>there’s some memory available (in fact the only one I know).
>
> AIX had this odd 'overcommit' feature, which allowed the system to
> overcommit memory resources. It would allocate virtual address space
> (via malloc) even if there wasn't enough memory + backing store to
> support it, and would take a SIGSEGV when referenced if, at the time
> of reference, there was still insufficient memory and/or backing store
> to support allocating a physical page to that portion of the VA space.
>
> Linux can be configured to operate in the same way.

Indeed, Linux defaults to overcommit for most allocations.

> I don't believe AIX ever returned NULL from malloc() while still
> allocating VA space for the allocation.

I don’t really see the relevance. malloc(0) is NULL on AIX[1] because
that’s what they’ve chosen to do in the C library’s malloc
implementation, nothing to do with the kernel’s overcommit policies.

[1] I see from the man page that they’ve added a macro to enable more
sensible behaviour. Too late for us, we stopped supporting it years
ago.

--
https://www.greenend.org.uk/rjk/

On Mon, 22 Jan 2024 12:36:34 +0000
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> No, because it's natural to write
>
> employees = malloc(Nemployees * sizeof(EMPLOYEE));
> if (!employees)
> goto out_of_memory;
>
> You don't want to have to special case Nemployees == 0.

I cannot think of a realistic application where you would not have to treat
as a special case Nemployees == 0 anyway for reasons completely unrelated
to the behaviour of malloc() .Code (of a realistic application) referring to
employees would need to do something involved and your code above would be
part of that greater involved code so that code should not be called at all
if Nemployees == 0 .

On 2024-01-22, bart <bc@freeuk.com> wrote:
> On 22/01/2024 10:22, Richard Kettlewell wrote:
>> I think the design of malloc got this one right.
>
> I think it got it wrong. Now everyone is lumbered with an allocation
> scheme that will ALWAYS have to store the size of that struct, perhaps
> taking as much space as the struct itself.

Implementations of malloc have special strategies for small objects,
to allocate them compactly, with minimal overhead and fragmentation.
It is not necessary to store the size in every such object.

> Imagine allocating 100M of those structs, and also storing 100M copies
> of sizeof(Date) or whatever metadata is needed.

For the size to take up as much object as the struct itself, it
has to be a struct that whose size is sizeof(size_t), which is tiny:
often 8 bytes nowadays, or possibly 4.

An object that is as small as size_t should just be passed around
by value. It likely fits into a machine register, and so dynamically
allocating it is inefficient.

Every such allocation results in a pointer. The program has to retain at
least one copy of that pointer. The pointer is probably also 8 bits
wide, so even if those objects are allocated compactly without storing a
size field, it takes double the space just to retain pointers to them.

> Getting around that, by writing your own small-object allocator on top
> of malloc, is a lot harder that adding your own size-tracking on top of
> a malloc that does not store any extra data. As I've shown.

Writing small-object allocators on malloc is mostly a fool's errand,
in the absence of special justification.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> [...] Every such allocation results in a pointer. The
> program has to retain at least one copy of that pointer.
> The pointer is probably also 8 bits wide, so [...]

Surely you meant to write 8 *bytes* wide.

br,
KK

On Mon, 22 Jan 2024 11:55:38 +0000, bart wrote:

> Then on Windows I might get:
>
> ...
>
> Some odd results ...

.... but you repeat yourself.

On Mon, 22 Jan 2024 09:24:26 +0100, David Brown wrote:

> On 21/01/2024 22:31, Keith Thompson wrote:
>
>> I suspect that calling malloc() with one size and free() with a
>> different one would have been a rich source of subtle bugs.
>>
>>
> Sure. But that's part of the fun of C :-)

Not so much fun for the poor users who paid you the big bucks and expected
to get working code in return.

On 22/01/2024 19:36, Kaz Kylheku wrote:
> On 2024-01-22, bart <bc@freeuk.com> wrote:
>> On 22/01/2024 10:22, Richard Kettlewell wrote:
>>> I think the design of malloc got this one right.
>>
>> I think it got it wrong. Now everyone is lumbered with an allocation
>> scheme that will ALWAYS have to store the size of that struct, perhaps
>> taking as much space as the struct itself.
>
> Implementations of malloc have special strategies for small objects,
> to allocate them compactly, with minimal overhead and fragmentation.
> It is not necessary to store the size in every such object.
>
>> Imagine allocating 100M of those structs, and also storing 100M copies
>> of sizeof(Date) or whatever metadata is needed.
>
> For the size to take up as much object as the struct itself, it
> has to be a struct that whose size is sizeof(size_t), which is tiny:
> often 8 bytes nowadays, or possibly 4.
>
> An object that is as small as size_t should just be passed around
> by value. It likely fits into a machine register, and so dynamically
> allocating it is inefficient.
>
> Every such allocation results in a pointer. The program has to retain at
> least one copy of that pointer. The pointer is probably also 8 bits
> wide, so even if those objects are allocated compactly without storing a
> size field, it takes double the space just to retain pointers to them.

You keep talking about all the clever, space-efficient ways that malloc
/could/ manage memory. Unfortunately the people who write the mallocs I
use haven't got the memo.

If I go back to the program I posted earlier and allocate 8 bytes at a
time, then successive values from malloc are 32 bytes apart (when
allocations are clearly consecutive).

If my struct actually needs 32 bytes, then it will allocate 48 bytes: a
50% overhead.

Do you have an actual transcript from your machine where it does
anything different?

--------------------------
#include <stdio.h>
#include <stdlib.h>

enum {n=32};

int main(void) {
char* lastp=malloc(n);
char* p;
for (int i=0; i<10; ++i) {
p=malloc(n);
printf("%p %zu\n", p, p-lastp);
lastp=p;
}
} --------------------------

>> Getting around that, by writing your own small-object allocator on top
>> of malloc, is a lot harder that adding your own size-tracking on top of
>> a malloc that does not store any extra data. As I've shown.
>
> Writing small-object allocators on malloc is mostly a fool's errand,
> in the absence of special justification.
>

On the Binary Tree benchmark, using a small-object allocator on top of
malloc makes it three times as fast as just using malloc.

On 1/22/2024 2:14 PM, bart wrote:
> On 22/01/2024 19:36, Kaz Kylheku wrote:
>> On 2024-01-22, bart <bc@freeuk.com> wrote:
>>> On 22/01/2024 10:22, Richard Kettlewell wrote:
>>>> I think the design of malloc got this one right.
[...]
>
> On the Binary Tree benchmark, using a small-object allocator on top of
> malloc makes it three times as fast as just using malloc.

Fwiw, it is not unheard of to use malloc to implement a scheme that can
free things by rounding an address down to a large boundary, where
access to a header is right there... Basically, avoid as many calls to
malloc as you can. The over head is that all memory allocations must be
at least the size of a word where sizeof(word) == sizeof(word*). This
pointer is used to link memory into linked lists whose heads are
contained in the header sitting on a large alignment boundary. One time
I put the head right before the boundary. To get at the header:

free would round address down and subtract the size of the header to get
at it. The free could link the freed memory into a FIFO list or
something. Sometimes the header would have a region allocator as well...

If the allocator had to free a aligned main block, it could just free it
using free. Per thread blocks were also heavily used. So, wrapping up
malloc/free can be a good thing, indeed!

:^)

On 1/22/2024 2:38 PM, Chris M. Thomasson wrote:
> On 1/22/2024 2:14 PM, bart wrote:
>> On 22/01/2024 19:36, Kaz Kylheku wrote:
>>> On 2024-01-22, bart <bc@freeuk.com> wrote:
>>>> On 22/01/2024 10:22, Richard Kettlewell wrote:
>>>>> I think the design of malloc got this one right.
> [...]
>>
>> On the Binary Tree benchmark, using a small-object allocator on top of
>> malloc makes it three times as fast as just using malloc.
>
> Fwiw, it is not unheard of to use malloc to implement a scheme that can
> free things by rounding an address down to a large boundary, where
> access to a header is right there... Basically, avoid as many calls to
> malloc as you can. The over head is that all memory allocations must be
> at least the size of a word where sizeof(word) == sizeof(word*). This
> pointer is used to link memory into linked lists whose heads are
> contained in the header sitting on a large alignment boundary. One time
> I put the head right before the boundary. To get at the header:
>
> free would round address down and subtract the size of the header to get
> at it. The free could link the freed memory into a FIFO list or
> something. Sometimes the header would have a region allocator as well...
>
> If the allocator had to free a aligned main block, it could just free it
> using free. Per thread blocks were also heavily used. So, wrapping up
> malloc/free can be a good thing, indeed!
>
> :^)

Basically use standard malloc/free as a slow path..... ;^)

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-01-22, bart <bc@freeuk.com> wrote:
>> On 22/01/2024 10:22, Richard Kettlewell wrote:
>>> I think the design of malloc got this one right.
>>
>> I think it got it wrong. Now everyone is lumbered with an allocation
>> scheme that will ALWAYS have to store the size of that struct, perhaps
>> taking as much space as the struct itself.
>
>Implementations of malloc have special strategies for small objects,
>to allocate them compactly, with minimal overhead and fragmentation.
>It is not necessary to store the size in every such object.
>
>> Imagine allocating 100M of those structs, and also storing 100M copies
>> of sizeof(Date) or whatever metadata is needed.
>
>For the size to take up as much object as the struct itself, it
>has to be a struct that whose size is sizeof(size_t), which is tiny:
>often 8 bytes nowadays, or possibly 4.
>
>An object that is as small as size_t should just be passed around
>by value. It likely fits into a machine register, and so dynamically
>allocating it is inefficient.

Given the alignment requirements associated with various
application binary interfaces, malloc must generally
return an address aligned to an ABI specified boundary
(often 16-byte). Such an allocator will often round the allocation
size up to the next 16-byte boundary.

"The malloc() and calloc() functions return a pointer to the
allocated memory that is suitably aligned for any kind of variable"

On 1/22/2024 2:45 PM, Scott Lurndal wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-01-22, bart <bc@freeuk.com> wrote:
>>> On 22/01/2024 10:22, Richard Kettlewell wrote:
>>>> I think the design of malloc got this one right.
>>>
>>> I think it got it wrong. Now everyone is lumbered with an allocation
>>> scheme that will ALWAYS have to store the size of that struct, perhaps
>>> taking as much space as the struct itself.
>>
>> Implementations of malloc have special strategies for small objects,
>> to allocate them compactly, with minimal overhead and fragmentation.
>> It is not necessary to store the size in every such object.
>>
>>> Imagine allocating 100M of those structs, and also storing 100M copies
>>> of sizeof(Date) or whatever metadata is needed.
>>
>> For the size to take up as much object as the struct itself, it
>> has to be a struct that whose size is sizeof(size_t), which is tiny:
>> often 8 bytes nowadays, or possibly 4.
>>
>> An object that is as small as size_t should just be passed around
>> by value. It likely fits into a machine register, and so dynamically
>> allocating it is inefficient.
>
> Given the alignment requirements associated with various
> application binary interfaces, malloc must generally
> return an address aligned to an ABI specified boundary
> (often 16-byte). Such an allocator will often round the allocation
> size up to the next 16-byte boundary.
>
> "The malloc() and calloc() functions return a pointer to the
> allocated memory that is suitably aligned for any kind of variable"

Fwiw, then there is this little region allocator "thing" I made, that
can be fed with memory from malloc, iirc in this example it is using
stack memory... It does use some hack(s), but it does properly align
things to their lowest alignment requirements. It was a while back:

Link to raw text:

https://pastebin.com/raw/f37a23918

Where I "think" I first mentioned it:

https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

An interesting macro in here is:
________________
#define RALLOC_ALIGN_OF(mp_type) \
offsetof( \
struct { \
char pad_RALLOC_ALIGN_OF; \
mp_type type_RALLOC_ALIGN_OF; \
}, \
type_RALLOC_ALIGN_OF \
)
________________

;^D

bart <bc@freeuk.com> writes:
> Imagine allocating 100M of those structs, and also storing 100M copies
> of sizeof(Date) or whatever metadata is needed.

I’m comfortable with that. It’s a general-purpose interface, it doesn’t
have to be the most efficient conceivable option in any particular
specialized use case.

--
https://www.greenend.org.uk/rjk/

Kaz Kylheku wrote:

> On 2024-01-19, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>> Kaz Kylheku wrote:
>>> Of course, that's not what "behavior can be readily inferred" means,
>>> no matter where I got the example.
>>
>> Inferences may be makeäble, but they have no power.
>
> Yeah, tell that to your compiler when it surprisingly deletes code based
> on inference.

Apologies, let me clarify: In a technical standard, inferences from
nonnormative text cannot be used to make normative statements.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site

Richard Kettlewell <invalid@invalid.invalid> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> That's a half-assed argument. There are other ways a pointer might
>> have a null value than just being the result of a call to malloc().
>> If code might call memset() et al with a zero size and a null
>> pointer, it's better to address all possible cases at once rather
>> than just some of them:
>>
>> static inline void *
>> safer_memset( void *s, int c, size_t n ){
>> return n ? memset( s, c, n ) : s;
>> }
>>
>> static inline void *
>> safer_memcpy( void *d, const void *s, size_t n ){
>> return n ? memcpy( d, s, n ) : d;
>> }
>>
>> /* ... etc ... */
>
> Of course that's what the cautious programmer must do practice. But in
> terms of the total cost (over all users, implementers, etc) fixing the
> definitions of memcpy/memset/etc (as well as malloc) would have been the
> better answer.

Better in some ways, worse in others. Better for me is not
always the same as better for thee.

> Standard C is trying to have its own cake and eat it here: 0-sized
> allocations can be represented by null pointers when it's malloc, but
> not when it's memcpy.

Actually the two decisions have essentially nothing to do with
each other. You might want to read what the C Rationale
document has to say about the decisions behind various
memory allocation policies.

Richard Kettlewell <invalid@invalid.invalid> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> It's trivial to fix that problem: simply require implementations
>>> to define a preprocessor symbol about how the implementation
>>> works. Problem solved.
>>>
>>> (There are other instances of implementation-defined behavior
>>> that would benefit from analogous changes along these lines.)
>>
>> I tend to agree that such a preprocessor symbol would be an
>> improvement.
>>
>> I still think, as I wrote above, that removing the permission to
>> return a null pointer on a successful zero-sized allocation would
>> be a greater improvement.
>
> Fully agreed. That permission has been grit in the gears for a
> very long time, for much of which I had the misfortune of having
> to deal with it in real life thanks to IBM's bad decisions.
>
> Fixing it would have been, what, a 2-line change to the impacted
> implementations, [...]

Again you are assuming that one choice is good for everyone.
The people who wrote the C standard considered the question
at length and reached a different conclusion.

Incidentally, the change needed is a lot more than two lines.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 21/01/2024 12:04, Tim Rentsch wrote:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>> [...]
>>
>>> Not requiring the non-null return from malloc(0) to be distinct
>>> from previous malloc(0) return values (whether they were freed or not),
>>> could help to "sell" the idea of taking away the null return value.
>>>
>>> Some implementors might grumble that null return allowed malloc(0) to be
>>> efficient by not allocating anything. If they were allowed to return
>>> (void *) -1 or something, that would placate that concern. [...]
>>
>> You have the tail wagging the dog here. If the results of
>> different malloc(0) calls don't need to be distinguishable,
>> they might just as well all be null.
>
> No, because it's natural to write
>
> employees = malloc(Nemployees * sizeof(EMPLOYEE));
> if (!employees)
> goto out_of_memory;
>
> You don't want to have to special case Nemployees == 0.

(A) You misunderstood the point I was making (as Keith's
followups more or less explained).

(B) Handling both implementation choices is trivial:
employees = malloc(Nemployees * sizeof(EMPLOYEE));
if (!employees && Nemployees)
goto out_of_memory;

(C) Alternatively, it is quite straightforward to write
a wrapper to malloc() and free() that returns a non-null
pointer for a size of zero (and that is a lower cost
path in terms of cycles used and memory resources needed
than the behavior implementations are required to provide
if they return a non-null pointer).

(D) The code you suggest is "natural" for people who are
lazy programmers who don't care about their code being
correct. There are easy ways around the deficiencies
of your example and any competent developer will use them.

On 1/22/24 18:12, Blue-Maned_Hawk wrote:
> Kaz Kylheku wrote:
>
>> On 2024-01-19, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>>> Kaz Kylheku wrote:
>>>> Of course, that's not what "behavior can be readily inferred" means,
>>>> no matter where I got the example.
>>>
>>> Inferences may be makeäble, but they have no power.
>>
>> Yeah, tell that to your compiler when it surprisingly deletes code based
>> on inference.
>
>
> Apologies, let me clarify: In a technical standard, inferences from
> nonnormative text cannot be used to make normative statements.

True, but the relevant inferences were from normative text. The context
of the above comments has been snipped, so I'll repeat it here:

On 1/17/24 19:10, Kaz Kylheku wrote:
> On 2024-01-17, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>> It looks to me like it was always undefined behavior, but it just wasn't
>> explicitly stated as such in C99.
>
> That is incorrect. A behavior for the following can be readily inferred
> from C99:
>
> void *p = malloc(42);

Per C99:
"The malloc function returns either a null pointer or a pointer to the
allocated space." (7.22.3.4p2)

Thus, there are two possibilities:
A: p == NULL
B: p contains the address of a block of memory at least 42 bytes long,
suitably aligned to store an object of any type.

The standard does not mandate documentation of which of the two applies,
so this has unspecified behavior.

> void *q = realloc(p, 0);

Per C99:
"The realloc function deallocates the old object pointed to by ptr and
returns a pointer to a new object that has the size specified by size.
The contents of the new object shall be the same as that of the old
object prior to deallocation, up to the lesser of the new and old sizes.
Any bytes in the new object beyond the size of the old object have
indeterminate values.

If ptr is a null pointer, the realloc function behaves like the malloc
function for the specified size. Otherwise, if ptr does not match a
pointer earlier returned by a memory management function, or if the
space has been deallocated by a call to the free or realloc function,
the behavior is undefined. If memory for the new object cannot be
allocated, the old object is not deallocated and its value is
unchanged." (7.22.3.5p2)

Thus, if situation A applies, then "p = realloc(p, 0)" is the equivalent
of p = malloc(0).

If situation B applies, then the memory pointed at by p is deallocated.
Since the value of p was in fact earlier returned by a memory management
function, the only statement that might otherwise give that statement
undefined behavior doesn't apply.

Either way, C99 says the following:
"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." (7.22.3p1)

The behavior when the size is 0 is therefore implementation-defined.

Thus, situation A splits into two different possibilities:
A.a: q == NULL directly
A.b: q contains the same result as q = malloc(0), which splits into
A.b.a: q == NULL due to the equivalent of a call to malloc().
A.b.b: q points at a block of memory at least 1 byte of long, suitably
aligned to store an object of any type, but that pointer cannot be used
to access that memory (which renders the alignment effectively irrelevant).

A.a and A.b.a are indistinguishable, so there's really only two possible
outcomes for situation A.

Situation B is split the exact same way, except that B.b.b splits one
additional way: q might or might not end up containing a pointer to that
same memory that was allocated by the first call to malloc().

Thus, the behavior is a mixture of unspecified and
implementation-defined, giving several different possibilities, but none
of them has undefined behavior.

On 22/01/2024 23:09, Lawrence D'Oliveiro wrote:
> On Mon, 22 Jan 2024 09:24:26 +0100, David Brown wrote:
>
>> On 21/01/2024 22:31, Keith Thompson wrote:
>>
>>> I suspect that calling malloc() with one size and free() with a
>>> different one would have been a rich source of subtle bugs.
>>>
>>>
>> Sure. But that's part of the fun of C :-)
>
> Not so much fun for the poor users who paid you the big bucks and expected
> to get working code in return.

Hence the smiley :-)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Of course that's what the cautious programmer must do practice. But in
>> terms of the total cost (over all users, implementers, etc) fixing the
>> definitions of memcpy/memset/etc (as well as malloc) would have been the
>> better answer.
>
> Better in some ways, worse in others. Better for me is not
> always the same as better for thee.

The way I think it’s better is total cost over all users, implementers,
etc. I think the time and effort spent coping with the bugs arising from
the current loose rules is much greater than the time it’d take to add
‘if(size == 0) { size=1; }’ to a handful of allocators and update some
unit tests.

>> Standard C is trying to have its own cake and eat it here: 0-sized
>> allocations can be represented by null pointers when it's malloc, but
>> not when it's memcpy.
>
> Actually the two decisions have essentially nothing to do with
> each other. You might want to read what the C Rationale
> document has to say about the decisions behind various
> memory allocation policies.

Do you mean
https://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
s7.20.3?

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>
>>> Of course that's what the cautious programmer must do practice. But in
>>> terms of the total cost (over all users, implementers, etc) fixing the
>>> definitions of memcpy/memset/etc (as well as malloc) would have been the
>>> better answer.
>>
>> Better in some ways, worse in others. Better for me is not
>> always the same as better for thee.
>
> The way I think it's better is total cost over all users, implementers,
> etc. [...]

Yes, I got that. Not everyone shares that view. It's not
even a given that everyone thinks that's the best metric
to optimize.

>>> Standard C is trying to have its own cake and eat it here: 0-sized
>>> allocations can be represented by null pointers when it's malloc, but
>>> not when it's memcpy.
>>
>> Actually the two decisions have essentially nothing to do with
>> each other. You might want to read what the C Rationale
>> document has to say about the decisions behind various
>> memory allocation policies.
>
> Do you mean
> https://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
> s7.20.3?

I was looking at C99RationaleV5.10, although I believe the comments
are from the earlier, original Rationale document. I expect you
have the right section; I don't have the document open to check.

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>>>
>>>>>> I'm looking at the C99 and N3096 (April 2023) definitions of realloc
>>>>>> side by side.
>>>>>>
>>>>>> N3096 says
>>>>>>
>>>>>> "Otherwise, if ptr does not match a pointer earlier returned by a memory
>>>>>> management function, or if the space has been deallocated by a call to
>>>>>> the free or realloc function, or if the size is zero, the behavior is
>>>>>> undefined."
>>>>>>
>>>>>> Yikes! In C99 there is nothing about the size being zero:
>>>>>>
>>>>>> "Otherwise, if ptr does not match a pointer earlier returned by the
>>>>>> calloc, malloc, or realloc function, or if the space has been
>>>>>> deallocated by a call to the free or realloc function, the behavior is
>>>>>> undefined."
>>>>>>
>>>>>> Nothing about "or if the size is zero".
>>>>>>
>>>>>> Yikes; when did this criminal stupidity get perpetrated?
>>>>>
>>>>> I'm not sure what stupidity you are referring to, but IIRC, there was
>>>>> some recent standardization activity relating to realloc
>>>>> when size == 0 because there were differences in the behavior
>>>>> between different implementations. Making the behavior
>>>>> undefined was the only rational choice.
>>>>
>>>> Is that last sentence your own assessment, or are you simply
>>>> repeating someone else's assessment?
>>>
>>> My assessment. I've never found realloc useful, regardless of
>>> the value of the size parameter. YMMV.
>>
>> So you aren't really in a position to say whether this decision was
>> the only rational choice. Generally I hope people who would make
>> such a statement would first make an effort to learn and understand
>> other people's thoughts on the matter.
>
> The fact that I didn't find it useful, doesn't imply in any way
> that I don't understand other's thoughts on the matter. I did
> spend several years on various standards committees, compromise
> was often the best way to make forward progress and 'undefined
> behavior' was a rational compromise in that context.

There's a big difference between saying something is a rational
compromise and saying it's the only rational choice. And you
still haven't provided any evidence that you are in a position to
offer an informed judgment on either premise, for the particular
question of how realloc(p,0) should be treated. If all you're
expressing is a personal opinion, I have no problem with that.
If you want to claim that you are offering more than just a
personal opinion, I think it's reasonable to ask for some
supporting evidence to back that up.

On 2024-01-23, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>>
>>>> Of course that's what the cautious programmer must do practice. But in
>>>> terms of the total cost (over all users, implementers, etc) fixing the
>>>> definitions of memcpy/memset/etc (as well as malloc) would have been the
>>>> better answer.
>>>
>>> Better in some ways, worse in others. Better for me is not
>>> always the same as better for thee.
>>
>> The way I think it's better is total cost over all users, implementers,
>> etc. [...]
>
> Yes, I got that. Not everyone shares that view. It's not
> even a given that everyone thinks that's the best metric
> to optimize.

It is an inherently collectivist view; I would expect communists
to agree with it unanimously. (But then bungle the execution by
forming a five year plan in which the work is divided into groups
driven by meaningless local metrics and irrelevant incentives.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.