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: why is there not a ipow version of pow? Date: Tue, 18 Aug 2026 18:18:14 -0700 Organization: A noiseless patient Spider Lines: 68 Message-ID: <86mrui29ih.fsf@linuxsc.com> References: <115eks4$3pn1s$1@dont-email.me> <115f01a$3ugcg$1@raubtier-asyl.eternal-september.org> <115f20j$3un9e$1@dont-email.me> <115f64m$ml3$1@raubtier-asyl.eternal-september.org> <115f7h5$1659$2@dont-email.me> <115f7v8$1b5d$1@raubtier-asyl.eternal-september.org> <115facm$1659$3@dont-email.me> <115fchf$2e17$1@dont-email.me> <86y0e62kzd.fsf@linuxsc.com> <115sk02$189sr$4@dont-email.me> <864igs3bmj.fsf@linuxsc.com> <115vi86$183lr$10@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 19 Aug 2026 01:18:17 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2408603"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+h7gbW0EuJ0QWxKlcRTc/uRBUdoqCcC5c="; posting-host="d6f68e827472d35b9db1fc199aad88a7" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:OhuwTQp9bNi87uh2r2ERwMtCfnU= sha1:Ym2X8rmjfruXg8TsusWxqQFBG30= sha256:bWyRkzYgTEv2OPHOCQsubq0U3wpSfIsumwZLTxkuRG8= sha1:7/1sirqjZ9j2O+Qzg1dvrxCHZ8Q= sha256:OQWTrVOleZmQfaF5d2RYoiTDyCshI8O7JnePmgpQvXQ= Xref: csiph.com comp.lang.c:401321 Janis Papanagnou writes: > On 2026-08-17 19:22, Tim Rentsch wrote: > >> Janis Papanagnou writes: >> >>> On 2026-08-16 16:33, Tim Rentsch wrote: >>> >>>> One: one of the recursive calls is not properly tail recursive so >>>> the recursion isn't always optimized out. >>> >>> You could as well write that also from the beginning in an iterative >>> form (and not rely on optimizations of recursive functions - in case >>> that this is a problem for the compilers in mind). >> >> I find it easier simply to write a properly tail-recursive >> implementation from the outset, > > Fair enough. > >> where I know compilers will have >> no difficulty optimizing out the tail calls. > > Not all might know whether and what sorts of constructs their > compilers are able to optimize. I wasn't advising anyone else what to write; just saying what I would find easier. > To me it's not obvious that > simple (but non-tail-) recursions are typically not optimized. By always using a tail-recursive formulation I don't have to care about what other forms are optimized. As a rule when I write recursive calls that are not tail recursive I expect them to generate actual calls; I don't mind if such cases are optimized but I don't care if they aren't. > YMMV, but sensible optimizations is IMO task of the compilers; > it shouldn't be necessary that you have to formulate programs > using a specific programming pattern; Perhaps I have given a wrong impression. I write code in a functional, and sometimes tail-recursive, style, not because I am thinking about whether it will be optimized but because I find it simple and natural and easy to understand. Of course I wouldn't do that if I thought it were going to perform badly, but I know from experience that it usually gets optimized to a non-recursive form. > ideally - but "C" as had > been discussed not long ago exposes anyway a peculiar view of > optimizations. (I'm sure YMMV.) Tail call elimination has both a long history and a good theoretical underpinning. Part of why it is so attractive is that it's easy to accomplish; I've been aware of and making use of tail call elimination since the early 1970s. I don't find it surprising at all that C compilers (and also compilers for other languages) exploit the ease of effecting these transformation, not only to help runtime performance but also as a way of reducing pressure on stack size. It's like compilers recognizing that multiplying or dividing by powers of two can be turned into shifts -- it allows developers to write code in a natural way, without having to think about what low-level transformations might be helpful to get around simplistic code generators. We are well past the primitive code generators of the 1950s.