Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

On Wed, 1 Mar 2023 22:58:59 +0100
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> On Wed, 1 Mar 2023 22:28:56 +0100
> Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> 
> > Remarks:
> > 1) We should do this in if-conversion (?) on our own.
> >    I suppose. Independently of -fdelete-null-pointer-checks  
> 
> and iff we can prove that ptr was NULL when passed to free(ptr) then we
> can elide the call, of course. Likewise for realloc(ptr, 0), obviously.
> [or reallocarray -- yikes -- if nmemb == 0 || size == 0]
> 
> But that would probably be a ranger call in DCE, i guess. Didn't look.
> thanks,

And, if under C, we rule out validity of a life ptr as a return value of
malloc(0),
---8<---
 If size is 0, either:

A null pointer shall be returned [CX] [Option Start]  and errno may be set to an implementation-defined value, [Option End] or

A pointer to the allocated space shall be returned. The application shall ensure that the pointer is not used to access an object.
---8<---
Where CX == "Extension to the ISO C standard" 
https://pubs.opengroup.org/onlinepubs/9699919799/help/codes.html#CX

then one might be baffled that malloc(0) still is underspecified or
at least unpleasantly specified WRT realloc(NULL,0) after all these
years in the wild.

The exact quote from CX is
---8<---
[CX] [Option Start] Extension to the ISO C standard [Option End]
The functionality described is an extension to the ISO C standard. Application developers may make use of an extension as it is supported on all POSIX.1-2017-conforming systems.

With each function or header from the ISO C standard, a statement to the effect that "any conflict is unintentional" is included. That is intended to refer to a direct conflict. POSIX.1-2017 acts in part as a profile of the ISO C standard, and it may choose to further constrain behaviors allowed to vary by the ISO C standard. Such limitations and other compatible differences are not considered conflicts, even if a CX mark is missing. The markings are for information only.

Where additional semantics apply to a function or header, the material is identified by use of the CX margin legend.

---8<---
So, what in the end this all gives is IMHO that natural stuff like valid
C or C++ can only borderline elide any of these calls which hinders
everyone and helps nobody for real IMHO. Doesn't it.

That's how conceptually devirt does it's thing for just a very
particular flavour of the family and rightfully leaves the rest alone,
which really is a pity IMHO.

But that's enough as far as an unfounded rant goes for today and should
probably be addressed elsewhere either way.

So, please remind me, why, again, does C do it's life ptr thing, short
of an optimisation barrier?

thanks,