Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Wed, 23 Apr 2025 17:31:29 +0200
Organization: A noiseless patient Spider
Lines: 130
Message-ID: <vub14h$3d9kt$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <vu01k7$1bfv2$1@dont-email.me>
 <vu0720$1dva7$1@dont-email.me> <vu2hmg$3jn88$1@dont-email.me>
 <vu2mkc$3noft$1@dont-email.me> <vu38da$735n$1@dont-email.me>
 <vu3j7s$g755$1@dont-email.me> <87ecxmv4t4.fsf@nosuchdomain.example.com>
 <vu401g$reom$1@dont-email.me> <20250420200823.908@kylheku.com>
 <vu5bqp$230jl$2@dont-email.me> <20250421113640.839@kylheku.com>
 <vu67up$2ubvr$1@dont-email.me> <20250421125957.29@kylheku.com>
 <vu6kkt$392e6$1@dont-email.me> <vu6q3b$3jhq1$1@paganini.bofh.team>
 <vu7r19$da0o$1@dont-email.me> <20250422103555.547@kylheku.com>
 <vu8sm8$18fhc$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 23 Apr 2025 17:31:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9c60b54993b1503c0c34a5be768da3e9";
	logging-data="3581597"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18eBTu1xdqdfq6f3dFIGQCUclSgsfPkGVY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:u8wvEN2X9vrwrCMRJfYfl3P9VE0=
Content-Language: en-GB
In-Reply-To: <vu8sm8$18fhc$2@dont-email.me>
Bytes: 7129

On 22/04/2025 22:03, bart wrote:
> On 22/04/2025 20:26, Kaz Kylheku wrote:
>> On 2025-04-22, bart <bc@freeuk.com> wrote:
> 
>>> Or would you automatically say it was reasonable no matter how many
>>> levels there were, just to disagee with me and to side with a fellow C
>>> programmer?
>>
>> You're trying to say that C is a bad language because you can have
>> 7 or more layers of macro expansion, but you're not considering how
>> bizarre and crippling restriction it would be to put a cap on it.
> 
> Here, I'm trying to determine if this is the poster's honest, objective 
> opinion, or whether they'd always going to be defend such code no matter 
> what.
> 
> 14 levels of macros? No problem; I'm sure there was a good reason!

If there is good reason for 14 levels of macros, then fine.

If there are not /good/ reasons for multiple levels, but the result is 
correct code that compiles efficiently (on reasonable compilers with 
reasonable options), then maybe it is appropriate to leave it untouched.

Too few levels of functions and/or macros (there is no semantic 
difference between macros and functions in this matter) makes code hard 
to write and hard to get correct - you are doing too much at a time. 
Splitting things up - divide and conquer - is a big win.  But too many 
levels also makes it hard to see what is going on and can be a 
maintenance challenge.

So once you first have too many levels - for whatever reasons - and the 
code is correct and does the job, you have to decide whether or not to 
refactor into simpler, neater and clearer code.  The result would be 
easier to maintain in the future, but it has a cost in time, effort and 
the risk of making mistakes.

> 
> I did ask at one point whether anybody could link to some truly terrible 
> C code; nobody has so far.

There are probably two reasons for that.  One is that everyone, except 
perhaps you, understands that this is very subjective.  I've seen plenty 
of code posted in this group, written by regulars whose programming 
skill and knowledge I highly respect, and yet which I would classify as 
"truly terrible" and reject it immediately if it were presented to me 
for code review in my work.  The other reason is that nobody else is 
particularly interested in seeing bad code, or going out of their way to 
look for it.

> 
> I just want to find out the threshold at which some will actually agree 
> that macros have been abused or their use is over the top and unjustified.
> 

Why?

We are all going to have different first-glance opinions on different 
bits of code.  But to form a solid, justifiable opinion I would want to 
see a lot more of the code in question.  I'd want to look at the macro 
definitions, and how they are used in the code - the macros alone are 
far from enough.  I'd want to know the history of the project.  I'd want 
to know the target usage of the code.  I'd want to see its 
documentation, its roadmap for the future, its history of bugs and other 
problems.  I'd want to know more about the developers behind the code. 
I'd want to know if other people are expected to read the code, to work 
with it, to re-use it, or if they would simply see it as a finished 
product.  I'd want to know if it is targeting a specific device, OS, 
processor, compiler, or if it is intended to be portable.  I'd want to 
know how it is tested.  I'd want to know if it is viewed as low-risk, 
low-cost software, or intended to be secure or highly reliable.

Clearly, I haven't the slightest interest in going to that effort just 
to please you.

So the best I can offer you is a very cursory glance at the code, and 
the opinion that - in the case of the Lua source code snippet - it's 
probably fine, but a bit more finely divided than I would like myself, 
though there may be good reasons behind that.

I really can't see what any of that gives you.

We all know that some people write bad code, or have written bad code. 
I don't think anyone will deny that.  We also all have different 
thoughts and experiences on what makes code good or bad, or when bad 
code might be perfectly acceptable - all such judgements are very 
subjective, and therefore of little use here.

And we all know this is entirely independent of programming language.


> There doesn't seem to be any limit - or not any that they want to admit 
> to me.

It is absolutely correct that there is no dividing line between "good 
code" and "bad code", or "use" and "abuse".

> 
> 
>  > but you're not considering how
>  > bizarre and crippling restriction it would be to put a cap on it.
> 
> There WILL be a cap.

No.

Very few things in this world are black-or-white.

> Some deep nesting might be justified in special 
> cases, for example some recursive macro that builds a string a character 
> at a time.
> 
> But this was not such a case; it was simply decided to make it work 
> using macros instead of functions.

How do you know that?

> 
> As for being crippling: I've written all sorts of language apps, 
> including interpreters like this, without ever using more than one 
> level, and for several decades, zero levels.
> 

And how do you know that is a good choice, or would be better in this case?

> A language like C provides all these odd-ball features, people are going 
> to use them.

Macros are hardly odd-ball.