Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: size_t best practice
Date: Mon, 19 Aug 2024 11:13:03 +0300
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <20240819111303.00004a7a@yahoo.com>
References: <VdCcne2MOeshN1z7nZ2dnZfqnPWdnZ2d@brightview.co.uk>
	<operator-20240818131412@ram.dialup.fu-berlin.de>
	<20240818154013.00002ed7@yahoo.com>
	<86a5h9eagx.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Aug 2024 10:12:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="63e4d7165886f0c08d939b274e907ed0";
	logging-data="2440532"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19HChAw1uZCMBXQF+nrjdVPZk48UbGjJYo="
Cancel-Lock: sha1:WNr/f5WR5mOEL0ajod/EnvnpYCE=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3870

On Sun, 18 Aug 2024 15:23:58 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > On 18 Aug 2024 12:17:36 GMT
> > ram@zedat.fu-berlin.de (Stefan Ram) wrote:
> >  
> >> Mark Summerfield <mark@qtrac.eu> wrote or quoted:
> >>  
> >>> So is it considered best practice to use int, long, long long, or
> >>> size_t, in situations like these?  
> >>
> >>   In *cough*C++*cough* you could whip up a "SafeSize" class with
> >>   a bulletproof "operator--", so you don't space on the check.
> >>   You could still keep cranking out your code in what's basically C
> >> and just cherry-pick this one gnarly feature from that other
> >> language.
> >>
> >> SafeSize& operator--()
> >> { if( value == 0 )
> >>   { throw std::underflow_error("SafeSize decrement underflow"); }
> >>   --value;
> >>   return *this; }  
> >
> > But that's not a desired behavior for people that want to write
> > downcounting for() loops in intuitive manner.  
> 
> Kind of a funny use of the word intuitive, for two reasons.
> 
> The first is that writing for() loops, especially C for() loops,
> is learned behavior.  There can be patterns that one is used to,
> but they are not "intuitive" in the usual sense of the word.
> 
> The second is that people who program in C are accustomed to the
> idea of an asymmetry between counting up and counting down,
> because of how pointers work.  It's okay to increment a pointer
> to one past the end of an array;  it is not okay to decrement a
> pointer to one before the beginning of an array.  Because of that
> the patterns for going forward and for going backward are just
> different.  It seems odd to use the word "intuitive" to recognize
> that distinction.
>

I would think that very large part of 'C' programmers ignores this
asymmetry. They are helped by the fact that 100% of production 'C'
compilers ignore it as well, which means that in practice code that
compares &arr[0] with &arr[-1] works as naively expected on all targets
that have flat memory model and far more often than not works on more
tricky targets as well.

> Which is not to say I disagree with what you are saying.  Actually
> I guess I'd have to say I'm not sure what it is you are saying.
> To my way of thinking the function above doesn't change the way I
> would write down-counting loops.  It might be useful as a debugging
> aid aide, but nothing more (and an assert() is probably better).
> I think though that what you're saying is something else but I'm
> not sure what it is.

Nothing fancy. Just an ability to write downcounting loops in a
way that I, obviously mistakenly, consider intuitive.
for (i = len-1; i >= 0; --i)