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: Wed, 21 Oct 2026 02:41:12 -0700
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <86h5ifo0g7.fsf@linuxsc.com>
References: <86ece2kppv.fsf@linuxsc.com> <11al4mu$fqtl$1@kst.eternal-september.org> <11ali2e$pi$1@reader2.panix.com> <86v775h9o2.fsf@linuxsc.com> <11am74c$54g$1@reader2.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 21 Oct 2026 09:41:13 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="3987493"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19WvfVEU0XSsB/Fyro46DvYAC2dxFdwUR8="; posting-host="dcce9549cab60c9dc2e15c40a16373a5"
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:6soTqcFQl4vYYCakql8zGfnvdEw= sha1:aK+FTYIOEaxvyDpAaDt8khIjkec= sha256:dHxJxZHxmyAzquiN/ZFATJ5Y+V1VSfnE0PUYBGAQSps= sha1:IgPUzmM8wv23yaZNw7+K07wBLvI= sha256:U2wvTNQDZZ5cs5wjA8XFoTzvZeMEo5tyoBSYagUzCMk=
Xref: csiph.com comp.lang.c:403405

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

> In article <86v775h9o2.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>
>> 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.
>
> Nope.  Not even close.

I am confident my assessment is on fairly solid ground in this
case.

That said, I don't think there is any value in taking part in a
shouting match, which seems to be all you want to do here.