* Fix REALLOC_ZERO_BYTES_FREES comment
@ 2021-04-11 21:42 Paul Eggert
2021-04-12 6:05 ` Paul Zimmermann
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2021-04-11 21:42 UTC (permalink / raw)
To: GNU C Library
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]
While looking into problems with glibc's documentation of
malloc/free/etc. I noticed that the comment for REALLOC_ZERO_BYTES_FREES
was out of date: its reference to "the C standard" refers to ISO C11,
but that compatibility problem has been fixed in C17. I installed the
attached commentary fix as obvious.
[-- Attachment #2: 0001-Fix-REALLOC_ZERO_BYTES_FREES-comment-to-match-C17.patch --]
[-- Type: text/x-patch, Size: 1376 bytes --]
From dff9e592b8f74e2e7be015cbee1c0fad3ef96d37 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 11 Apr 2021 14:39:20 -0700
Subject: [PATCH] Fix REALLOC_ZERO_BYTES_FREES comment to match C17
* malloc/malloc.c (REALLOC_ZERO_BYTES_FREES):
Update comment to match current C standard.
---
malloc/malloc.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/malloc/malloc.c b/malloc/malloc.c
index 6640385282..0cd3ba78ca 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -346,10 +346,13 @@ __malloc_assert (const char *assertion, const char *file, unsigned int line,
#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
/*
- REALLOC_ZERO_BYTES_FREES should be set if a call to
- realloc with zero bytes should be the same as a call to free.
- This is required by the C standard. Otherwise, since this malloc
- returns a unique pointer for malloc(0), so does realloc(p, 0).
+ REALLOC_ZERO_BYTES_FREES controls the behavior of realloc (p, 0)
+ when p is nonnull. If nonzero, realloc (p, 0) should free p and
+ return NULL. Otherwise, realloc (p, 0) should do the equivalent
+ of freeing p and returning what malloc (0) would return.
+
+ ISO C17 says the behavior is implementation-defined here; glibc
+ follows historical practice and defines it to be nonzero.
*/
#ifndef REALLOC_ZERO_BYTES_FREES
--
2.27.0
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix REALLOC_ZERO_BYTES_FREES comment
2021-04-11 21:42 Fix REALLOC_ZERO_BYTES_FREES comment Paul Eggert
@ 2021-04-12 6:05 ` Paul Zimmermann
2021-04-12 6:13 ` Florian Weimer
0 siblings, 1 reply; 7+ messages in thread
From: Paul Zimmermann @ 2021-04-12 6:05 UTC (permalink / raw)
To: Paul Eggert; +Cc: libc-alpha
Dear Paul,
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 11 Apr 2021 14:42:22 -0700
>
> While looking into problems with glibc's documentation of
> malloc/free/etc. I noticed that the comment for REALLOC_ZERO_BYTES_FREES
> was out of date: its reference to "the C standard" refers to ISO C11,
> but that compatibility problem has been fixed in C17. I installed the
> attached commentary fix as obvious.
>
> [2:text/x-patch Show Save:0001-Fix-REALLOC_ZERO_BYTES_FREES-comment-to-match-C17.patch (1kB)]
you write "If nonzero, ... should free p .... Otherwise ... should do the
equivalent of freeing p". Is there a difference between "free p" and "do the
equivalent of freeing p"?
Also "ISO C17 says the behavior is implementation-defined here": I guess you
mean the "default value of REALLOC_ZERO_BYTES_FREES", since for me the
behavior is what is described above.
Paul
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix REALLOC_ZERO_BYTES_FREES comment
2021-04-12 6:05 ` Paul Zimmermann
@ 2021-04-12 6:13 ` Florian Weimer
2021-04-12 6:19 ` Paul Zimmermann
0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2021-04-12 6:13 UTC (permalink / raw)
To: Paul Zimmermann; +Cc: Paul Eggert, libc-alpha
* Paul Zimmermann:
> Dear Paul,
>
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sun, 11 Apr 2021 14:42:22 -0700
>>
>> While looking into problems with glibc's documentation of
>> malloc/free/etc. I noticed that the comment for REALLOC_ZERO_BYTES_FREES
>> was out of date: its reference to "the C standard" refers to ISO C11,
>> but that compatibility problem has been fixed in C17. I installed the
>> attached commentary fix as obvious.
>>
>> [2:text/x-patch Show Save:0001-Fix-REALLOC_ZERO_BYTES_FREES-comment-to-match-C17.patch (1kB)]
>
> you write "If nonzero, ... should free p .... Otherwise ... should do the
> equivalent of freeing p". Is there a difference between "free p" and "do the
> equivalent of freeing p"?
It's freeing p followed by malloc (0).
> Also "ISO C17 says the behavior is implementation-defined here": I guess you
> mean the "default value of REALLOC_ZERO_BYTES_FREES", since for me the
> behavior is what is described above.
This part I find confusing as well, and also the “If nonzero”
clause—it's probably best to mention the REALLOC_ZERO_BYTES_FREES macro.
And maybe also clarify that the range of permitted C17 behaviors goes
beyond the two choices controlled by REALLOC_ZERO_BYTES_FREES.
Thanks,
Florian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix REALLOC_ZERO_BYTES_FREES comment
2021-04-12 6:13 ` Florian Weimer
@ 2021-04-12 6:19 ` Paul Zimmermann
2021-04-12 7:48 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Paul Zimmermann @ 2021-04-12 6:19 UTC (permalink / raw)
To: Florian Weimer; +Cc: eggert, libc-alpha
Hi Florian,
> > you write "If nonzero, ... should free p .... Otherwise ... should do the
> > equivalent of freeing p". Is there a difference between "free p" and "do the
> > equivalent of freeing p"?
>
> It's freeing p followed by malloc (0).
sorry I was not clear. The complete sentence proposed by Paul is
"Otherwise, realloc (p, 0) should do the equivalent of freeing p and returning
what malloc (0) would return."
Why not simply the following?
"Otherwise, realloc (p, 0) should free p and return what malloc (0) would."
Am I overlooking something? What puzzles me is why we write "free p" in the
first part and "do the equivalent of freeing p" in the second one.
Paul
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix REALLOC_ZERO_BYTES_FREES comment
2021-04-12 6:19 ` Paul Zimmermann
@ 2021-04-12 7:48 ` Paul Eggert
2021-04-12 7:53 ` Florian Weimer
2021-04-12 19:44 ` DJ Delorie
0 siblings, 2 replies; 7+ messages in thread
From: Paul Eggert @ 2021-04-12 7:48 UTC (permalink / raw)
To: Paul Zimmermann, Florian Weimer; +Cc: libc-alpha
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
On 4/11/21 11:19 PM, Paul Zimmermann wrote:
> Why not simply the following?
>
> "Otherwise, realloc (p, 0) should free p and return what malloc (0) would."
Thanks, that is better wording. I installed the attached comment patch,
which also attempts to address the other points you and Florian made.
[-- Attachment #2: 0001-Further-fixes-for-REALLOC_ZERO_BYTES_FREES-comment.patch --]
[-- Type: text/x-patch, Size: 1552 bytes --]
From 9f1bed18f9466ac886addb2f79d8e4c52fb65eb5 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 12 Apr 2021 00:33:15 -0700
Subject: [PATCH] Further fixes for REALLOC_ZERO_BYTES_FREES comment
* malloc/malloc.c (REALLOC_ZERO_BYTES_FREES): Improve comment further.
---
malloc/malloc.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/malloc/malloc.c b/malloc/malloc.c
index 0cd3ba78ca..e2d7b1b583 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -346,13 +346,14 @@ __malloc_assert (const char *assertion, const char *file, unsigned int line,
#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
/*
- REALLOC_ZERO_BYTES_FREES controls the behavior of realloc (p, 0)
- when p is nonnull. If nonzero, realloc (p, 0) should free p and
- return NULL. Otherwise, realloc (p, 0) should do the equivalent
- of freeing p and returning what malloc (0) would return.
-
- ISO C17 says the behavior is implementation-defined here; glibc
- follows historical practice and defines it to be nonzero.
+ The REALLOC_ZERO_BYTES_FREES macro controls the behavior of realloc (p, 0)
+ when p is nonnull. If the macro is nonzero, the realloc call returns NULL;
+ otherwise, the call returns what malloc (0) would. In either case,
+ p is freed. Glibc uses a nonzero REALLOC_ZERO_BYTES_FREES, which
+ implements common historical practice.
+
+ ISO C17 says the realloc call has implementation-defined behavior,
+ and it might not even free p.
*/
#ifndef REALLOC_ZERO_BYTES_FREES
--
2.27.0
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix REALLOC_ZERO_BYTES_FREES comment
2021-04-12 7:48 ` Paul Eggert
@ 2021-04-12 7:53 ` Florian Weimer
2021-04-12 19:44 ` DJ Delorie
1 sibling, 0 replies; 7+ messages in thread
From: Florian Weimer @ 2021-04-12 7:53 UTC (permalink / raw)
To: Paul Eggert; +Cc: Paul Zimmermann, libc-alpha
* Paul Eggert:
> diff --git a/malloc/malloc.c b/malloc/malloc.c
> index 0cd3ba78ca..e2d7b1b583 100644
> --- a/malloc/malloc.c
> +++ b/malloc/malloc.c
> @@ -346,13 +346,14 @@ __malloc_assert (const char *assertion, const char *file, unsigned int line,
> #define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
>
> /*
> - REALLOC_ZERO_BYTES_FREES controls the behavior of realloc (p, 0)
> - when p is nonnull. If nonzero, realloc (p, 0) should free p and
> - return NULL. Otherwise, realloc (p, 0) should do the equivalent
> - of freeing p and returning what malloc (0) would return.
> -
> - ISO C17 says the behavior is implementation-defined here; glibc
> - follows historical practice and defines it to be nonzero.
> + The REALLOC_ZERO_BYTES_FREES macro controls the behavior of realloc (p, 0)
> + when p is nonnull. If the macro is nonzero, the realloc call returns NULL;
> + otherwise, the call returns what malloc (0) would. In either case,
> + p is freed. Glibc uses a nonzero REALLOC_ZERO_BYTES_FREES, which
> + implements common historical practice.
> +
> + ISO C17 says the realloc call has implementation-defined behavior,
> + and it might not even free p.
> */
I think this is a really good explanation of the situation. Thanks.
Florian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix REALLOC_ZERO_BYTES_FREES comment
2021-04-12 7:48 ` Paul Eggert
2021-04-12 7:53 ` Florian Weimer
@ 2021-04-12 19:44 ` DJ Delorie
1 sibling, 0 replies; 7+ messages in thread
From: DJ Delorie @ 2021-04-12 19:44 UTC (permalink / raw)
To: Paul Eggert; +Cc: libc-alpha
I'll add that, had this been in the *manual*, the original wording would
have been more appropriate. Otherwise, there's a missed expectation of
what calls an interposer would see.
We can be more lax with internal comments ;-)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-12 19:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-11 21:42 Fix REALLOC_ZERO_BYTES_FREES comment Paul Eggert
2021-04-12 6:05 ` Paul Zimmermann
2021-04-12 6:13 ` Florian Weimer
2021-04-12 6:19 ` Paul Zimmermann
2021-04-12 7:48 ` Paul Eggert
2021-04-12 7:53 ` Florian Weimer
2021-04-12 19:44 ` DJ Delorie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).