On 3/5/23 12:35 AM, Charlie Gibbs wrote:
> On 2023-03-05, 28B.I874 <28B.I874@noabzba.net> wrote:
>
>> Most software, ONE third is the actual "doing stuff"
>> part - the other TWO thirds revolves around handling
>> potential user screw-ups.
>
> And a lot of that work can be avoided if you
>
> 1. convince the user that he/she is stupid
> and is only getting what he/she deserves
>
> or
>
> 2. sell the users on your new corporate policy:
> "That's not a bug, it's a feature!"

Well, there are psychology issues there ...

Convince the user that they are "above average"
and are GETTING FINE SOFTWARE SUITED FOR THEIR
TALENTS :-)

> Microsoft's greatest crime against humanity is that they
> have lowered users' standards so far as to wean them off
> reliability. "Re-boot, re-format, re-install" is now the
> Way of the Universe in the minds of most users, and they'll
> meekly shrug their shoulders and accept the massive drain
> on their time (and wallets) - as long as the screens are
> pretty. I've heard this described as "trout management":
> dangle something shiny with a hook in it in front of them
> and they'll strike every time.

Yep. the "three-key salute" is the usual fix for M$ stuff.

What I really don't like is that they keep dumbing-down
their mainline apps - like their Office stuff. Options
that used to be there just AREN'T anymore. A few more
disappear with every release.

Yea ... making that "complicated" stuff work is EXPENSIVE
for them.

So, their strategy has just been to dumb-down the users,
their expectations.

> It's morally wrong to allow a sucker to keep his money.
> -- W.C. Fields

Dear WC :-)

And I liked his co-star Mae West too ... how'd she stay
out of jail, much less on-screen, in the 30s ??? :-)

(Research Mae - she was the Real Deal - writer/actress/
de-facto director/producer for most of her life in a
wide variety of media projects. A lot of IQ/talent
behind that 'madame' persona)

On 3/5/23 8:48 AM, Allodoxaphobia wrote:
> On Sun, 05 Mar 2023 05:35:56 GMT, Charlie Gibbs wrote:
>>
>> Microsoft's greatest crime against humanity is that they
>> have lowered users' standards so far as to wean them off
>> reliability. "Re-boot, re-format, re-install" is now the
>> Way of the Universe in the minds of most users, and they'll
>> meekly shrug their shoulders and accept the massive drain
>> on their time (and wallets) - as long as the screens are
>> pretty. I've heard this described as "trout management":
>> dangle something shiny with a hook in it in front of them
>> and they'll strike every time.
>
> Microsoft LONG AGO gave up any focus on fault-tolerant systems.
> Their main focus now is on fault-tolerant customers.

I think they won.

Must have studied DC pols .....

On 3/5/23 8:40 AM, The Natural Philosopher wrote:
> On 05/03/2023 01:24, 28B.I874 wrote:
>> On 3/4/23 4:54 AM, Richard Kettlewell wrote:
>>> "28A.I873" <28A.I873@noabzba.net> writes:
>>>>    Ah ... an interesting technical question about 'C' ...
>>>>    assume you're looking for the position of a given
>>>>    character in a string .......
>>>>
>>>>      for(x=0;x<strlen(TheStr);x++)
>>>>      {
>>>>        if(TheStr[x]==TheChar) return(x);
>>>>      }
>>>>      return(-1);
>>>>
>>>>   is a pretty common approach. HOWEVER, the QUESTION,
>>>>   is "strlen(TheStr)" calculated over and over again
>>>>   for every iteration ??? That seems SLOW, esp if
>>>>   TheStr is BIG.
>>>
>>> The short answer to your question is: stop hand-coding the search and
>>> use strchr.
>>
>>
>>    The above  was just an example. Usually you'd want
>>    to do a lot more than JUST find the index of TheChar.
>>    strchr() gets rid of those few lines of code, but
>>    what is IT doing, how they code it ? Same thing ?
>>    Kinda has to be. I can dig into the .h and see ...
>>
> I would code it - if its what think it is, as
>
> char *strchr( char *p, char a)
>     {
>     do {
>         if (a==*p) return p;
>          }
> while (*p++);
> return NULL;
> }

Also very good. Saves a line or two and a local var, so
maybe faster.

But I do prefer clear indexes to pointer math ...

However in a "simple" case like this, either is
fairly clear. Now if you start nesting, or worse
recurring, it gets yucky quick :-)

> I think I DID code it once years ago, when I was asked to create stdlib
> and basic  I/O functions for an embedded processor board.
>
> A modern c compiler would take that and make about 5 lines of assembler,
> and caching would make it lightning fast.

Not MUCH cache in microcontrollers. Sometimes none.
However I've seen compilers recognize when they can
"re-use" registers that aren't part of what you're
doing at the moment - and accessing those is fast.

>>    Now just a few more lines and you have a "find Nth
>>    instance of TheChar" and a few more lines you have
>>    strtok() and a few more you have "return Nth ascii-
>>    delimited field of TheStr" - which I needed yesterday
>>    to parse-out stuff generated by a system() call so
>>    I whipped this together >>
>>      void StrField(char *ss,char *dlims,int fn)
>>      {
>>        int cnt=0;
>>        char *p;
>>        p=strtok(ss,dlims);
>>        while (p != NULL)
>>        {
>>          if(cnt++>=fn) { strcpy(ss,p); return; } // found, return
>>          p=strtok(NULL,dlims);                   // get another chip
>>        }
>>        ss[0]=0;   // else return nothing
>>      }
>>
>>    which is a bit clunk but worked ok for what I needed.
>>
>>> The long answer is that it depends on the type of the pointer.
>>>
>>> If it’s ‘char *TheStr’ then the compiler is entitled to assume that
>>> the string doesn’t change during the execution of the code fragment. GCC
>>> and Clang will therefore call strlen only once.
>>
>>    Hmmm ... but look at strtok():
>>
>>      char *strtok(char *str, const char *delim)
>>
>>    and a number of other "mod in-place" functions that DO
>>    change the length of your *TheStr before all is done.
>>    Sometimes you need to waste memory creating a safe copy
>>    before  you call such functions. Fine if TheStr is 255
>>    bytes, not so great if it's megabytes.
>>
>>> If it’s ‘volatile char *TheStr’ then this assumption is prohibited - the
>>> string “may be modified in ways unknown to the implementation” in the
>>> language of the spec. (The intention is support memory-mapped hardware.)
>>> In this case a compiler must call strlen every time round the loop (and
>>> indeed GCC and Clang do so).
>>
>>    Got it. The bugaboo with compilers (and lots of other things)
>>    is that it is difficult to write a 'general solution' when
>>    the INTENT of the user may not be so clear. 'volatile char*'
>>    is one way to help with that but you never REALLY know what
>>    the user has in mind.
>>
>>    Anyhow, just for fun, I'm gonna actually CHECK to see when
>>    strlen() is and is not re-evoked in loops like the sample
>>    above.
>

On 3/5/23 11:29 AM, Dan Espen wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> On 05/03/2023 01:24, 28B.I874 wrote:
>>> On 3/4/23 4:54 AM, Richard Kettlewell wrote:
>>>> "28A.I873" <28A.I873@noabzba.net> writes:
>>>>>    Ah ... an interesting technical question about 'C' ...
>>>>>    assume you're looking for the position of a given
>>>>>    character in a string .......
>>>>>
>>>>>      for(x=0;x<strlen(TheStr);x++)
>>>>>      {
>>>>>        if(TheStr[x]==TheChar) return(x);
>>>>>      }
>>>>>      return(-1);
>>>>>
>>>>>   is a pretty common approach. HOWEVER, the QUESTION,
>>>>>   is "strlen(TheStr)" calculated over and over again
>>>>>   for every iteration ??? That seems SLOW, esp if
>>>>>   TheStr is BIG.
>>>>
>>>> The short answer to your question is: stop hand-coding the search and
>>>> use strchr.
>>>   The above  was just an example. Usually you'd want
>>>   to do a lot more than JUST find the index of TheChar.
>>>   strchr() gets rid of those few lines of code, but
>>>   what is IT doing, how they code it ? Same thing ?
>>>   Kinda has to be. I can dig into the .h and see ...
>>>
>> I would code it - if its what think it is, as
>>
>> char *strchr( char *p, char a)
>
> I believe if you look at string.h you might see that gcc goes a bit
> farther toward optimizing than any C code would do.

We'll have to check. A few issues have been mentioned here
and I think they deserve at least a little investigation
and/or benchmarking. There are trix and then there are the
PERFECT trix. Lots of lib routines involve scanning down
a string in one or more places, so it's important.

DID like Mr.Natural's pointery solution to the basic 'find
char in string'. It'll be in my next projects (with creds).

Note that strtok() does NOT take a char as the delimiter but
a STRING ... ie you can have multiple delims. I've used this
to advantage in ascii-delimited multivalue DB records (which
I sometimes make for simple apps - SO easy to assemble as you
go along). Easy to read also. ('general-purpose' EDITING, well,
that's not so easy ... "intent" becomes involved as there are
a number of ways to structure fields/sub-fields/sub-sub-fields)

On 05/03/2023 16:43, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 04/03/2023 11:22, Richard Kettlewell wrote:
>>> It’s suitable for coping with signals/interrupts too, yes.
>>> The point that sometimes causes confusion is that it’s _not_
>>> suitable
>>> for managing concurrent access from multiple threads.
>>
>> If I understand what exactly you mean by that, the question would be
>> 'why not?'
>
> ‘volatile’ affects what assembler instructions the compiler generates -
> it forces it to generate read and write instructions that otherwise
> wouldn’t be there.
>
> However, at runtime, the CPU core may re-order memory operations
> compared to how they appear in the assembler code, in pursuit of higher
> performance.
>
> Within a single core, this is invisible the programmer: a re-ordering
> isn’t allowed to change the execution of single-threaded code.
>
> With multiple cores, however, the effects can be visible. A memory write
> on CPU 1 may not be visible in a memory read by CPU 2 for many cycles
> after it was executed. There are more complex examples: for instance if
> CPU 1 does two memory writes, CPU 2 might see the effect of the second
> before the effect of the first.
>
> The exact rules differ between CPU architectures. x86 is one of the most
> forgiving (though even there a store may be re-ordered after a load) -
> presumably there is a lot of logic dedicated to maintaining consistency
> between cores. Arm is one of the least forgiving.
>
> For a programmer there are two solutions (or three if you count avoiding
> concurrency).
>
> * Use memory barrier instructions, which prohibit re-orderings across
> them. These instructions are generally built into locks, semaphores,
> etc, so properly written threaded code is already immunized against
> the issue.
>
> This explains the language in
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12:
> it is telling us which functions have to include a memory barrier.
>
> * Use atomic operations, which provide a set of memory operations with
> guarantees about re-ordering built in.
>
> (See https://en.cppreference.com/w/c/atomic for atomic operations in
> C.)
>

Ah. Thanks Richard. I never thought about multiple *cores*.

That explains it all nicely.

--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

On 06/03/2023 06:06, 28B.I874 wrote:
> On 3/5/23 8:40 AM, The Natural Philosopher wrote:
>> On 05/03/2023 01:24, 28B.I874 wrote:
>>> On 3/4/23 4:54 AM, Richard Kettlewell wrote:
>>>> "28A.I873" <28A.I873@noabzba.net> writes:
>>>>>    Ah ... an interesting technical question about 'C' ...
>>>>>    assume you're looking for the position of a given
>>>>>    character in a string .......
>>>>>
>>>>>      for(x=0;x<strlen(TheStr);x++)
>>>>>      {
>>>>>        if(TheStr[x]==TheChar) return(x);
>>>>>      }
>>>>>      return(-1);
>>>>>
>>>>>   is a pretty common approach. HOWEVER, the QUESTION,
>>>>>   is "strlen(TheStr)" calculated over and over again
>>>>>   for every iteration ??? That seems SLOW, esp if
>>>>>   TheStr is BIG.
>>>>
>>>> The short answer to your question is: stop hand-coding the search and
>>>> use strchr.
>>>
>>>
>>>    The above  was just an example. Usually you'd want
>>>    to do a lot more than JUST find the index of TheChar.
>>>    strchr() gets rid of those few lines of code, but
>>>    what is IT doing, how they code it ? Same thing ?
>>>    Kinda has to be. I can dig into the .h and see ...
>>>
>> I would code it - if its what think it is, as
>>
>> char *strchr( char *p, char a)
>>      {
>>      do {
>>          if (a==*p) return p;
>>           }
>> while (*p++);
>> return NULL;
>> }
>
>
>   Also very good. Saves a line or two and a local var, so
>   maybe faster.
>
>   But I do prefer clear indexes to pointer math ...
>
Pointers dont need an extra variable to iterate through a string.
When I first learnt C with very stupid compilers, trhat was an
advantage, as an indierect load from memory was a lot faster than using
an offset to a pointer

>   However in a "simple" case like this, either is
>   fairly clear. Now if you start nesting, or worse
>   recurring, it gets yucky quick  :-)
>
>
>> I think I DID code it once years ago, when I was asked to create
>> stdlib and basic  I/O functions for an embedded processor board.
>>
>> A modern c compiler would take that and make about 5 lines of
>> assembler, and caching would make it lightning fast.
>
>   Not MUCH cache in microcontrollers. Sometimes none.
>   However I've seen compilers recognize when they can
>   "re-use" registers that aren't part of what you're
>   doing at the moment - and accessing those is fast.
>
>
>
Oh this board was an 8088. It was the monitor and control board for a
specialised minicomputer. Sort of like a complex bios on a board. In
charge of booting everything up board by board and then testing the
interboard comms. I think. In its own right it was a pretty nice little
personal computer. Serial comms and a floppy drive and I ported FORTH
onto it as well..

>
--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

On 3/6/23 4:28 AM, The Natural Philosopher wrote:
> On 06/03/2023 06:06, 28B.I874 wrote:
>> On 3/5/23 8:40 AM, The Natural Philosopher wrote:
>>> On 05/03/2023 01:24, 28B.I874 wrote:
>>>> On 3/4/23 4:54 AM, Richard Kettlewell wrote:
>>>>> "28A.I873" <28A.I873@noabzba.net> writes:
>>>>>>    Ah ... an interesting technical question about 'C' ...
>>>>>>    assume you're looking for the position of a given
>>>>>>    character in a string .......
>>>>>>
>>>>>>      for(x=0;x<strlen(TheStr);x++)
>>>>>>      {
>>>>>>        if(TheStr[x]==TheChar) return(x);
>>>>>>      }
>>>>>>      return(-1);
>>>>>>
>>>>>>   is a pretty common approach. HOWEVER, the QUESTION,
>>>>>>   is "strlen(TheStr)" calculated over and over again
>>>>>>   for every iteration ??? That seems SLOW, esp if
>>>>>>   TheStr is BIG.
>>>>>
>>>>> The short answer to your question is: stop hand-coding the search and
>>>>> use strchr.
>>>>
>>>>
>>>>    The above  was just an example. Usually you'd want
>>>>    to do a lot more than JUST find the index of TheChar.
>>>>    strchr() gets rid of those few lines of code, but
>>>>    what is IT doing, how they code it ? Same thing ?
>>>>    Kinda has to be. I can dig into the .h and see ...
>>>>
>>> I would code it - if its what think it is, as
>>>
>>> char *strchr( char *p, char a)
>>>      {
>>>      do {
>>>          if (a==*p) return p;
>>>           }
>>> while (*p++);
>>> return NULL;
>>> }
>>
>>
>>    Also very good. Saves a line or two and a local var, so
>>    maybe faster.
>>
>>    But I do prefer clear indexes to pointer math ...
>>
> Pointers dont need an extra variable to iterate through a string.
> When I first learnt C with very stupid compilers, trhat was an
> advantage, as an indierect load from memory was a lot faster than using
> an offset to a pointer

I'm gonna use your method, at least for these simpler
cases where it's easy to keep track of what's what.
In 'complex' stuff though, I'll sacrifice a little
speed/size for down-the-road clarity.

>>    However in a "simple" case like this, either is
>>    fairly clear. Now if you start nesting, or worse
>>    recurring, it gets yucky quick  :-)
>>
>>
>>> I think I DID code it once years ago, when I was asked to create
>>> stdlib and basic  I/O functions for an embedded processor board.
>>>
>>> A modern c compiler would take that and make about 5 lines of
>>> assembler, and caching would make it lightning fast.
>>
>>    Not MUCH cache in microcontrollers. Sometimes none.
>>    However I've seen compilers recognize when they can
>>    "re-use" registers that aren't part of what you're
>>    doing at the moment - and accessing those is fast.
>>
>>
>>
> Oh this board was an 8088. It was the monitor and control board for a
> specialised minicomputer. Sort of like a complex bios on a board. In
> charge of booting everything up board by board and then testing the
> interboard comms. I think. In its own right it was a pretty nice little
> personal computer. Serial comms and a floppy drive and I ported FORTH
> onto it as well..

Oh, by 'embedded' I was assuming micro-controllers,
8051s or even PICs.

The 8088 wasn't the worlds greatest chip but it was
a 'microprocessor' and that gives a lot more wiggle
room.