Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: *rubeyes*: realloc(ptr, 0) is UB?
Date: Mon, 22 Jan 2024 20:01:42 -0800
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <86plxsg0k9.fsf@linuxsc.com>
References: <20240116162506.143@kylheku.com> <QdTpN.168167$vFZa.62153@fx13.iad> <20240117094759.508@kylheku.com> <9iYpN.354613$83n7.275953@fx18.iad> <86r0ifjbiw.fsf@linuxsc.com> <QfbqN.230722$c3Ea.54531@fx10.iad> <uobqhg$2mt8c$1@dont-email.me> <20240118112920.465@kylheku.com> <uoc030$2ndid$2@dont-email.me> <20240118144021.3@kylheku.com> <87r0iech8j.fsf@nosuchdomain.example.com> <20240118185544.347@kylheku.com> <865xzmj4bv.fsf@linuxsc.com> <wwvh6j5mzxv.fsf@LkoBDZeT.terraraq.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="c985c2e759848cd31734101b28e08031"; logging-data="1198051"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+RNUZWINTyfz9G4W+F1jKPzRVU7G45aM0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:4nhBFeOAGFaUzpGEDMqM7FqwJGQ= sha1:rA4+HUdup6qkYcsSI87WpmcI9KE=
Xref: csiph.com comp.lang.c:380667

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.