Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: And they say C is obscure
Date: Mon, 10 Apr 2017 08:22:07 -0700
Organization: None to speak of
Lines: 72
Message-ID: <lnmvbowan4.fsf@kst-u.example.com>
References: <20170409-035940.754.0@Peabody.ssl.astraweb.com> <026b3f5e-2d15-4736-9cec-f31f5818ba2d@googlegroups.com> <lntw5xwaxt.fsf@kst-u.example.com> <96yGA.365951$987.313962@fx20.am4>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="eb9d33061c36d0ffb98b49126e9f4d7d"; logging-data="19222"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uCe10VlWQMi9ebH8Robwb"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:AGbM1N2P5KdAPaAP0vKvtxWVRig= sha1:/c2Dgy4fWVrcfdPFt//J5tjtMIo=
Xref: csiph.com comp.lang.c:107997

bartc <bc@freeuk.com> writes:
> On 09/04/2017 22:03, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> The C for loop is too flexible.
>>
>> I believe that's a minority opinion.
>
> A minority of at least two then.
>
>> The flexibility means, for example, that you can use the same construct
>> to iterate over a linked list:
>>
>>     for (node *ptr = head; node != NULL; node = node->next)
>>
>> that you'd use to iterate over an array.
>
> That's the trouble: it can be practically anything. If trying to
> understand code (or transcribe into a generic algorithm or whatever)
> you have to stop and analyse a for-statement. The header tends to be
> written on one line so you also have to scan it looking for commas and
> semicolons to properly identify the different parts.
>
> Here's a nice selection from sample code:
>
>   for (x0 = 8;  x0;  --x0) {
>   for (i = 0, c = nj.comp;  i < nj.ncomp;  ++i, ++c) {
>   for (mbx = mby = 0;;) {
>   for (;*zTok;zTok++){
>   for(n=1; z[n] && z[n]!=':' && !sqlite3Isspace(z[n]); n++){}
>   for(i=0, n=1; zFmt[i]; i++, n++){
>   for(i=j=0; zFmt[i]; i++){
>   for(i=*pRoot; i>0; i=iNext){
>   for(toFree=nBlock*16; toFree<(mem3.nPool*16); toFree *= 2){
>   for(iFullSz=mem5.szAtom, iLogsize=0; iFullSz<nByte; iFullSz *= 2,
> iLogsize++){}
>   for(n=0, j=mem5.aiFreelist[i]; j>=0; j = MEM5LINK(j)->next, n++){}
>   for(; (x=(*pre))!=0; pre++) *(--bufpt) = x;
>   for(idx=precision&0xfff, rounder=0.5; idx>0; idx--, rounder*=0.1){}
>   for(i=n=0; k!=0 && (ch=escarg[i])!=0; i++, k--){
>   for (workp2 = workp + coll_symbol_length ; workp < workp2 ;)
>   for (i = 0, j = 0; i < len0 && ! ISALPHA ((unsigned char)mangled[i]);
>        i += 1, j += 1)
>   for (acount = 0;; acount++)
>   for (result = &node->value.answers; *result; result = &(*result)->next)
>   for (; ; i--, mask >>= 1)
>   for (; !fake ;)
>   for (p = &pfile->free_buffs;; p = &(*p)->next)
>   for (map = &set->maps[set->used - 1]; ! MAIN_FILE_P (map);
>        map = INCLUDED_FROM (set, map))

It isn't, and IMHO it shouldn't be, up to the standard to restrict
what kinds of expressions can appear in a for loop header.  It's up
to each programmer.

The vast majority of C for loops I've seen are reasonably
straightforward.

I challenge you to come up with a consistent and reasonable
definition for the for loop that's more restrictive than the
current one.  I predict that the resulting wording would be far
more complicated than what's currently in the standard, and that
it would be difficult to understand.

And any such restrictions would not make it the least bit more
difficult to write ugly and convoluted C code.  So don't do that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"