Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #380993

Re: *rubeyes*: realloc(ptr, 0) is UB?

Show all headers | View raw

Richard Kettlewell <invalid@invalid.invalid> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> 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.
>
> The cost is an objective statement, not a view.

What I mean is that not everyone agrees with the idea that
changing the definitions of memcpy/memset/etc will achieve the
goal of minimizing the total cost of ownership.

> In principle I could be wrong that the cost of everyone dealing
> with the resulting bugs, adding workarounds, etc, is greater than
> the cost of fixing implementations, but frankly it doesn't seem
> very plausible.

My comment is only about what other people consider to be so,
not to assess the question itself.

>> It's not even a given that everyone thinks that's the best metric
>> to optimize.
>
> 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.

>>>>> 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.
>
> It is thoroughly unenlightening as an explanation.

Oh.  I suppose that depends on what it is one thinks the writing
is trying to explain.

> * It says the rules about zero-length allocations are intended to
>   permit a particular paradigm, of which an example is given.

Actually it doesn't say that.  What it does say is that the
treatment of such cases was guided in part by a desire to
support the given pattern.

> * 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.

> * 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 text talks about the distinction betwen 'nothing' and 'zero'
>   but in the context of malloc the distinction the caller actually
>   needs to make is between success and failure.

That may indeed be an important distinction, but it is not
important to what this part of the Rationale document is trying
to explain.

> * 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).

> 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.

> * 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.

> 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.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 03:47 -0800
  Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-22 10:21 +0000
    Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-22 18:54 +0000
    Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 20:01 -0800
      Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-23 09:35 +0000
        Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-23 09:08 -0800
          Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:56 +0000
            Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 05:51 -0800
          Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-24 23:37 +0000
            Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 07:54 -0800
              Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-26 21:04 +0000
                Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:39 -0800

csiph-web