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: Thu, 29 Oct 2026 13:38:20 -0700 Organization: A noiseless patient Spider Lines: 89 Message-ID: <861p98medf.fsf@linuxsc.com> References: <86ece2kppv.fsf@linuxsc.com> <11amvh2$14pou$3@kst.eternal-september.org> <11ao2mr$4l9$1@reader2.panix.com> <11ap0fo$1t8gq$2@kst.eternal-september.org> <11aqnp0$sb$1@reader2.panix.com> <11arlj9$2q39c$1@kst.eternal-september.org> <20261015163445.76@kylheku.com> <11b20os$3qlbh$1@paganini.bofh.team> <11b29gv$3pvda$3@dont-email.me> <11b2njv$3rvef$2@paganini.bofh.team> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 29 Oct 2026 20:38:26 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3895521"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/OKxL9OCgZOif1w8xG2IhX8eL+EDaxiN8="; posting-host="a9c9791c9dd02c83b2c564a620bcf3c6" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:aHqrV55eWILK9k/msAjUNmuIEAY= sha1:sl/STUJL3GqnlAd7Yela1G6mFpk= sha256:q82WXDr6iQ6hcATn171Pcn/hW/SHJLChKfDTsD/dcr8= sha1:c3ys+9PyS9bR2JjHV68oVct1atA= sha256:dl9rFjjEOFar70HnQFk+bKfMX7IOI2n37HiJrIEcVtM= Xref: csiph.com comp.lang.c:403797 antispam@fricas.org (Waldek Hebisch) writes: [I am responding to two postings, restoring a sentence that was removed by an intermediate poster] > Janis Papanagnou wrote: > >> On 2026-10-18 10:42, Waldek Hebisch wrote: >> >>>> [...] >>> >>> I read the above as: "can access part of object that fits in >>> allocated space". That is important for structs and unions: you >>> clearly do not want to allocate memory for biggest union variant. >>> And I think that allocating memory only for used part of a struct >>> is pretty common. I confess to being rather incredulous of these claims. More below. >> Mind to explain that opinion? >> >> If I define a (C-)'union' type I definitely want to store anything >> possible in those unions, changing the value to another type as >> necessary. - Mind the 'sizeof' of a union is [at least?] the size >> of its largest component. - If I 'malloc' a union I use that size. >> In cases where I want to use just one [smaller] component-type of >> a union I just allocate that specific type not the union-type. >> >> But maybe you meant something different? > > I meant what I wrote. I think your alleged facts are wrong. The vast majority of C programs, and the vast majority of C programmers, have no interest in doing either of those things. If C code needs to use some part of an allocated struct, a whole struct is allocated. Evidence for this pattern can be seen in the common idiom for calling malloc(): struct foo *pfoo = malloc( sizeof *pfoo ); The case for unions is even weaker. First it is unusual for a union to have highly disparate sizes for its members; a factor of two or four, maybe, but rarely more than that. Furthermore if it were important to access only a subset of the smaller members then it is simple to create a new union type with only those members. At some level it's necessary to do that to know what size to give to malloc(). (And if it's only one member that is meant to be accessed, then we expect to follow the above common idiom for malloc() with a pointer to the member's type.) Of course it is not impossible that there are C programs that violate these norms. But they are at best few and far between, and anyone who would write such programs runs a greatly increased risk of undefined behavior. No sensible developer would do so. In any case any use of such anti-patterns is so rare that it wasn't a factor in deciding how malloc() is supposed to work. > C type system is too weak to give exact > type for more complicated data structure. Instead, real program > give approximate type and depend on holes in type system. This idea is nonsense. The C type system is powerful enough to express any type that C code can deal with. > So you > have pointer to union and program is structured so that it only > accesses valid variant. Allocating memory for whole using may > waste a lot of memory and does not buy you any real safety: > accessing wrong variant is likely to lead to troubles regardless > of amount of memory that you allocated. And in case of > interesting data structures variant does not change after > creation (allocation). If you need different variant you simply > allocate new piece of memory. > > BTW: Pascal 'new' for variant records takes extra argument > specifying requested variant. Corresponding pointer has type > 'pointer to variant record', but legally can only be used with > the variant specified in call to 'new'. In C you get equivalent > effect (with essentially the same conditions) by allocating > amount of memory needed for specific variant of union, but > assigning 'malloc' result to pointer to union. Here we see the key to understanding the earlier comments: we have someone who wants to write code in C but who wants to think in Pascal. There is no reason to think the C standard means to support the anti-patterns being advocated.