Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: AVL tree insertion - programming exercise
Date: Tue, 13 Oct 2026 09:01:17 -0700
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <86v775h9o2.fsf@linuxsc.com>
References: <86ece2kppv.fsf@linuxsc.com> <11akqm4$c6h9$1@dont-email.me> <11akuf1$bq6c$1@dont-email.me> <11al4mu$fqtl$1@kst.eternal-september.org> <11ali2e$pi$1@reader2.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 13 Oct 2026 16:01:18 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="730664"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ecXkvehCw1lCFpF4He49D62ShLegdCfQ="; posting-host="065d2eee2cd7241f5f1e4f229d8fc207"
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:eWcpinLtoYB1MtAjQ9gawmy36Rc= sha1:oX/RJ1ZDvxEMp+icI8ZL9CHcqzg= sha256:eubSz0llMwdGzSu9RiO+Tium/Waam/9hRIL5cDEI23I= sha1:npww+3AZgycJ3dT3Hj5p85h4k7s= sha256:cx5n0qqhrZSPOT88t+JEI5KqzCTD/3nQycUZkPxXqbg=
Xref: csiph.com comp.lang.c:403110

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <11al4mu$fqtl$1@kst.eternal-september.org>,
> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 13/10/2026 10:38, chine.bleu wrote:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> sons[2] array.  These links are basically pointers, but held
>>>>> as uintptr_t so they can take one of the bits to mean "tall",
>>>>> which means taller than the other subtree of the node.  The
>>>>> tree structure should maintain an invariant that at most one
>>>>
>>>> Memory is cheap.
>>>
>>> Not any more!
>>>
>>>> Do not encode tags into low bits of an address unless you really
>>>> know what your doing.
>>>
>>> Agreed, as a principle.
>>>
>>>> As a precaution check the return address of malloc
>>>>      p = malloc(m);
>>>>      if ((uintptr_t)p)&1!=0) abort();
>>>
>>> malloc always returns an address with suitable alignment for any
>>> fundamental alignment on the target.
>
> I don't think this is true anymore, as of C23.  Here's the
> relevant text from n3220, sec 7.24.3, describing the return
> value from `malloc` et al:
>
> |The pointer returned if the allocation succeeds is suitably
> |aligned so that it may be assigned to a pointer to any type of
> |object with a fundamental alignment requirement and size less
> |than or equal to the size requested.
>
> This sentence is somewhat ambiguous because it's unclear whether
> the "less than or equal to the size requested" criteria applies
> to both the pointer type's size _and_ fundamental alignment
> requirement, or _just_ the size, [...]

It's poorly constructed but in English it has only one
grammatical parse.