Bug in 2022f version of zic.c
Hi, tzcode2022f/zic.c has a bug in its memory checker routine in static void* memcheck(void*). This code throws an error and exits when the pointer returned by malloc is NULL. However, malloc is allowed to return a NULL pointer when the allocation size is 0. And, on one machine I am building the TZ code on, malloc(0) does indeed return NULL. This is an AIX 6.1 box, with C compiler xlC 13.01.0000.0011. This is easy enough to work around locally. However, it would be nice to get this fixed for any future release of the TZ code. --- Tim McBrayer Ab Initio Software NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.
On Nov 4, 2022, at 11:28 AM, Tim McBrayer via tz <tz@iana.org> wrote:
tzcode2022f/zic.c has a bug in its memory checker routine in static void* memcheck(void*). This code throws an error and exits when the pointer returned by malloc is NULL. However, malloc is allowed to return a NULL pointer when the allocation size is 0. And, on one machine I am building the TZ code on, malloc(0) does indeed return NULL. This is an AIX 6.1 box, with C compiler xlC 13.01.0000.0011.
This is easy enough to work around locally.
In what cases in zic is emalloc() - or erealloc() - called with 0 as the size argument? If there are any, are any where it *should* be doing that, rather than just skipping whatever it's doing if there zero items/bytes/whatever on which to do it? (ecpyalloc() - which should probably be called estrdup() to make it clearer that it's "strdup() with quit on out-of-memory" - is safe, as even strdup("") returns NULL only if the allocation fails.)
On 2022-11-04 16:11, Guy Harris via tz wrote:
In what cases in zic is emalloc() - or erealloc() - called with 0 as the size argument?
It's when zic sees a Zone with no continuation lines. I didn't notice the bug in testing, since I don't test with AIX. The portability bug was triggered by the removal of the Qt bug workaround in tzcode 2022f, which when combined with the -bslim option introduced in tzcode 2019b means that zic can generate TZif files with no time transitions. Thanks for reporting the bug, Tim. I installed the first attached patch; please give it a try. I think this fixes the only place that might call malloc(0) or realloc(p, 0). It's unfortunate that the C standard allows malloc to return NULL on success, as this complicates error checking. Of course zic.c should be portable even to platforms that exploit this glitch in C.
(ecpyalloc() - which should probably be called estrdup() to make it clearer that it's "strdup() with quit on out-of-memory"
Good suggestion, thanks. I installed the attached second patch to do that.
Paul Eggert via tz said:
It's unfortunate that the C standard allows malloc to return NULL on success, as this complicates error checking. Of course zic.c should be portable even to platforms that exploit this glitch in C.
We're back to the "there are no zero-sized objects in C" point. Therefore malloc(0) is an error by definition. I remember us coming up with the compromise wording that allowed either failure or success (but you can't access the returned memory), but I don't recall the details of why. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Paul, Both patches work as designed on Linux and AIX for me. I have reports that our z/OS build has hit the same issue. That one will take some time for the fix to percolate through the build system to validate it; I don't have easy individual access to z/OS. --- Tim McBrayer From: "Paul Eggert" <eggert@cs.ucla.edu> To: "Guy Harris" <gharris@sonic.net>, "Tim McBrayer" <TMcBrayer@ABINITIO.com> Cc: "Time zone mailing list" <tz@iana.org> Date: 11/04/2022 09:25 PM Subject: Re: [tz] Bug in 2022f version of zic.c On 2022-11-04 16:11, Guy Harris via tz wrote:
In what cases in zic is emalloc() - or erealloc() - called with 0 as the size argument?
It's when zic sees a Zone with no continuation lines. I didn't notice the bug in testing, since I don't test with AIX. The portability bug was triggered by the removal of the Qt bug workaround in tzcode 2022f, which when combined with the -bslim option introduced in tzcode 2019b means that zic can generate TZif files with no time transitions. Thanks for reporting the bug, Tim. I installed the first attached patch; please give it a try. I think this fixes the only place that might call malloc(0) or realloc(p, 0). It's unfortunate that the C standard allows malloc to return NULL on success, as this complicates error checking. Of course zic.c should be portable even to platforms that exploit this glitch in C.
(ecpyalloc() - which should probably be called estrdup() to make it clearer that it's "strdup() with quit on out-of-memory"
Good suggestion, thanks. I installed the attached second patch to do that. [attachment "0001-Port-to-AIX-6.1-malloc.patch" deleted by Tim McBrayer/AbInitio] [attachment "0002-Rename-ecpyalloc-to-estrdup.patch" deleted by Tim McBrayer/AbInitio] NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.
participants (4)
-
Clive D.W. Feather -
Guy Harris -
Paul Eggert -
Tim McBrayer