On 1/26/2024 12:27 AM, David Brown wrote:
> On 25/01/2024 22:40, Keith Thompson wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 1/25/2024 11:35 AM, Keith Thompson wrote:
>>> [...]
>>>> Unfortunately, code does not have access to the implementation's
>>>> documentation.
>>>
>>> Mind if I quote that from time to time? Nice one.
>>
>> Feel free.
>>
>> To expand on that, I think it was Tim Rentsch who recently suggested
>> adding predefined macros that code can query to find out which choices
>> an implementation has made.  I'm concerned that that would introduce a
>> lot of new symbols into the global namespace, so I'm thinking about a
>> new preprocessor pseudo-function, something like:
>>
>>      #if IMPL(MALLOC0, NON_NULL_RESULT)
>>      ...
>>      #elif IMPL(MALLOC0, NULL_RESULT)
>>      ...
>>      #endif
>>
>> This is just off the top of my head.  On the other hand, a bunch of
>> macros that can be queried with #ifdef would be simpler to implement.
>>
>
> I believe you can have your cake and eat it here.
>
> IMPL could be implemented as :
>
> #define IMPL(__group, __detail) defined(_IMPLEMENTATION_DETAIL_ ## \
>     __group ## _IS_ ## __detail)
>
>
> Then the implementation detail would just have to define macros such as:
>
> #define _IMPLEMENTATION_DETAIL_MALLOC0_IS_NON_NULL_RESULT
>
>
> That would be easy to implement and avoid a risk of identifier collisions.
>
> All you need to do now is persuade the main C compiler and library
> implementers to follow this new standard !
>

I bet the chaos pp lib has some interesting things that can be used for
"version" control... ;^)

https://github.com/rofl0r/chaos-pp

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> On 2024-01-26, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>>> On 2024-01-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Your understanding of the term "implementation-defined" is flawed.
>>>
>>> No it isn't.
>>>
>>> Obviously, an implementation cannot vaccilate among different
>>> choices of how malloc(0) should behave. [...]
>>
>> I think you've lost track of what point it is you are trying
>> to make. I know I have.
>
> Here I'm simply defending myself against the accusation that I
> don't understand the definition of implementation-defined
> behavior. (Based on what I'm guessing might be the basis of the
> perceived misunderstanding.)

I would say you have done so. There was a miscommunication and
you have identified the particular miscommunication sufficiently
so that it is no longer an issue.

> This is a mostly self-contained topic, which has a connection to
> an earlier point, that point being a relatively minor.

My problem is that I have lost track of what your overall point
is (if indeed I ever had a good fix on that). So I remain
confused about what you were trying to get at.

> I walked into it like you wanted me to, executing your plan
> to disconnect.

That is a baseless accusation. Throughout this discussion I have
been trying to improve communication, not impede it.

Richard Kettlewell <invalid@invalid.invalid> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>
>>> C's history since standardization does include a disregard for the
>>> costs born by its users, yes.
>>
>> I don't think that's true. Probably it is true that the
>> priorities of folks who have worked on the ISO C committee
>> don't exactly match your priorities.
>
> The practical impacts and the complaints have been widespread for many
> years. It?s not just me.
>
>>> It is thoroughly unenlightening as an explanation.
>>
>> Oh. I suppose that depends on what it is one thinks the writing
>> is trying to explain.
>
> You were the one who recommend it in the context of this thread...
>
> It claims to be trying to explain the treatment of null pointers and
> zero-length allocations. You may have to take it on trust, but for
> someone who happens not to like the treatment chosen, it singularly
> fails to explain that.
>
>>> * The example includes no attempt at error handling, which is
>>> where the pain point from the permission for malloc(0)=NULL
>>> arises. So it seems like the author of that section didn't
>>> consider the impact of the rules adopted.
>>
>> The code pattern shown is something that was observed to be in
>> widespread use, not something that the Rationale's authors
>> constructed to illustrate a point. It isn't surprising that
>> there isn't any mention of error handling, because it isn't
>> important to what the section is trying to explain.
>
> The implication is that error handling (and its relevance to reliability
> and robustness) was not of interest.
>
>>> * Nothing about the example depends either on malloc(0)=NULL or
>>> malloc(0)!=NULL, making it mysterious why the example is said
>>> to support the decisions made in C89.
>>
>> Nothing in the Rationale document says that the given code
>> pattern supports the decisions made in the C standard. Any
>> implication actually goes the other direction, that decisions
>> about how malloc() works were guided (in part) by a desire to
>> support the given code pattern.
>
> The point is alternative decisions (for example, the V7 behavior) would
> have supported it just as well.
>
>>> * The principle that 'zero-length objects' are invalid does not
>>> seem to be rationalized anywhere in the text. While there may
>>> be some advantage to it, nobody wrote them down.
>>
>> What the text actually says is that the C89 Committee decided not
>> to accept the idea of zero-length objects. Probably the phrasing
>> could have been better; in any case what is meant is that they
>> decided not to /require/ support of zero-length objects, but
>> rather have it be optional (and implementation-defined).
>
> The text describes requiring zero-length objects as a ?compelling
> theoretical disadvantage?, without explaining why it?s so compelling or
> even why requiring them would be a disadvantage. Earlier implementations
> apparently didn?t find any difficulty with them, or at least
> insufficient difficulty to influence the rules for malloc.
>
>>> A couple of other notes:
>>>
>>> * The Unix V7 rules for malloc neatly bypass any concerns about
>>> zero-length objects (if anybody cared about that at the time);
>>> the definition is "returns a pointer to a block of at least size
>>> bytes". malloc(0) returning a pointer to a 1-byte block would be
>>> a non-issue under this definition regardless of any theoretical
>>> objections.
>>
>> I don't know anything about what Unix V7 says about malloc(), so
>> I have nothing to say about that.
>
> You know what I told you above.
>
>>> * If it happens that c=0 at any point in the loop, the new C23
>>> rules make the example in 7.20.3 undefined behavior. I guess
>>> the example has fallen out of favour.
>>
>> Invalidating working code is a significant part of why people
>> object to the decision to make zero-sized realloc() calls be
>> undefined behavior.
>
> The rationale notes that the C89 rules change the behavior of existing
> code (despite ?existing code is important, existing implementations are
> not? and ?avoid quiet changes?).
>
>>> Finally back to the relationship to malloc:
>>>
>>>> Actually the two decisions have essentially nothing to do with
>>>> each other.
>>>
>>> It does seem like nobody considered the question of whether the
>>> two decisions were compatible; [...]
>>
>> They may or may not have. You may want to read the Introduction
>> section of the Rationale document.
>
> Being more specific about what you?re getting at might cause me to want
> to read that in more detail. So far I?ve just identified a couple of
> ?important principles? that were violated by the rules C89 introduced
> for malloc.

I have read through your comments, carefully, and read through
them again once or twice more. I have nothing useful to say at
this time.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 24/01/2024 04:28, Tim Rentsch wrote:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>>> I got a response from JeanHeyd Meneide.
>>>>>>
>>>>>> If realloc(ptr, 0) returns a null pointer there's no way to tell
>>>>>> whether allocation failed (and ptr has not been freed), or the
>>>>>> implementation returns a null pointer for zero-sized allocations
>>>>>> (and ptr has been freed). Some implementations set errno, but C
>>>>>> doesn't require it.
>
> To avoid any confusion, I wrote the above paragraph; JeanHeyd Meneide
> (the editor for C23 standard) did not.

Thank you, I appreciate the clarification.