Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: AVL tree insertion - programming exercise Date: Wed, 14 Oct 2026 20:54:58 -0700 Organization: A noiseless patient Spider Lines: 59 Message-ID: <86se27r52l.fsf@linuxsc.com> References: <86ece2kppv.fsf@linuxsc.com> <11akqm4$c6h9$1@dont-email.me> <11al0l0$eefv$1@dont-email.me> <11alfgs$t7q$1@reader2.panix.com> <11amttk$14pou$2@kst.eternal-september.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 15 Oct 2026 03:55:01 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2185445"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Bw/Yle//yM4iK6A0VTf78UDVCZ6E2SQY="; posting-host="8e248dd53a94b2a901695ff9f1057f0e" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:46VF+3706h7hl9T0VNZ5LVoCYWs= sha1:3S482RhQqeH0SMiLJF3O70zRVk4= sha256:Xs3IGs78lKlq8qUbRe7ZagTrhxBJTAY9kj/wcDWoYDo= sha1:Tr8EG1aAnh8z5tKsRmZwx3iTHeA= sha256:Y8F0ALt8uqxfYDg7jeVcVCbCcdoZKY98/WzZaxvlJzQ= Xref: csiph.com comp.lang.c:403174 Keith Thompson writes: > cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <11al0l0$eefv$1@dont-email.me>, >> James Kuyper wrote: >> >>> On 13/10/2026 10:38, chine.bleu wrote: >>> ...> As a precaution check the return >>> >>>> address of malloc >>>> >>>> p = malloc(m); >>>> if ((uintptr_t)p)&1!=0) abort(); >>> >>> Just to be pedantic, the standard doesn't guarantee that the >>> expression you use will test what you want to test. Since there >>> is a guarantee that malloc() returns a universally aligned memory, >>> I think it's actually more likely that the test will fail than >>> that malloc() will fail, though both probabilities are quite >>> negligible, so it's hard to be sure. >> >> The syntax and precedence errors aside, the test is clearly >> meant to ensure that the low bit in the return from `malloc` is >> clear, so that it can be repurposed for other things. It should >> likely be: >> >> p = malloc(m); >> if (p == NULL || ((uintptr_t)p & 1) != 0) abort(); > > I'm not sure the NULL test adds anything useful. The low-order bits > of a null pointer are very likely to be 0 on any real-world system. Surely we would like to protect against a null pointer being used to access a non-existent object. > Also, the test only looks at the low-order bits of the result of > the current malloc() call. If you have an exotic system where > an aligned pointer can have a low-order bit set to 1, it might > *sometimes* be set to 0. As long as the bit in question /is/ zero it doesn't matter if it might have been one. The bit will always be cleared before using the pointer as a pointer, so the pointer value in use will match the pointer value originally returned. Thus we might write a safe allocation function as follows: void * safe_new( size_t n ){ void *p = 0; while( !p || (uintptr_t)p %2 != 0 ) free( p ), p = malloc( n++ ); return p; } Of course it might not succeed in some cases, but it will be quite obvious if it doesn't. :)