Marcel Hendrix schrieb am Samstag, 29. Januar 2022 um 12:20:53 UTC+1:
> On Saturday, January 29, 2022 at 9:23:13 AM UTC+1, minf...@arcor.de wrote:
> > dxforth schrieb am Samstag, 29. Januar 2022 um 01:05:11 UTC+1:
> > > On 29/01/2022 06:55, Gerry Jackson wrote:
> > > > ...
> > > > Of course other systems that I quoted where the simple accesses do
> > > > appear to work may be corrupting something that has no visible effect in
> > > > such simple non-standard examples.
> > > Ideally a system would be designed such that even if a user makes a
> > > simple stack error it won't trash the system. Fine if the system/OS
> > > can sense under/overflow before it happens but least harm done if it
> > > can't.
> > Ideally user errors like stack underflow should throw an exception _without_
> > crashing the system.
> >
> > Perhaps system words should use their own stacks/registers without
> > affecting user stacks at all ...
> >
> > It is a bit diametricical to the prevailing Forth "philosophy" of sacrificing
> > safety for speed.
> I seldomly see stack errors in code once it is debugged. There might be
> unchecked code paths for situations that I initially thought extremely
> unlikely.
>
> What I notice in my own code is lots of errors with illegal memory access.
> The reason it appears so frequenly is that I know that this type of error
> is almost perfectly caught by the system and is very easy to correct,
> so I just run the word without carefully desk-checking that portion of
> the code.
>
> The same happens when I program in C, I tend to run code with
> complicated macros and library calls without carefully looking
> up the documentation and have the debugger disassemble or
> untangle the confusing parts :--)
>

True, running on an OS, signal SIGSEGV is the most important error signal to catch.
Without extra guard cells, stack over/underflow will also trigger SIGSEGV.

I used to have two program versions: DEBUG with all error-checks incl. paranoid
runtime checks enabled, and RELEASE without error checking.

But I found out that on the average DEBUG is just about 5-7 % slower than RELEASE.
Therefore today with modern CPUs there is so much application speed reserve
more often than not, that I just leave the DEBUG version in place.

On 30/01/2022 00:34, minf...@arcor.de wrote:
> Marcel Hendrix schrieb am Samstag, 29. Januar 2022 um 12:20:53 UTC+1:
>> On Saturday, January 29, 2022 at 9:23:13 AM UTC+1, minf...@arcor.de wrote:
>> > dxforth schrieb am Samstag, 29. Januar 2022 um 01:05:11 UTC+1:
>> > > On 29/01/2022 06:55, Gerry Jackson wrote:
>> > > > ...
>> > > > Of course other systems that I quoted where the simple accesses do
>> > > > appear to work may be corrupting something that has no visible effect in
>> > > > such simple non-standard examples.
>> > > Ideally a system would be designed such that even if a user makes a
>> > > simple stack error it won't trash the system. Fine if the system/OS
>> > > can sense under/overflow before it happens but least harm done if it
>> > > can't.
>> > Ideally user errors like stack underflow should throw an exception _without_
>> > crashing the system.
>> >
>> > Perhaps system words should use their own stacks/registers without
>> > affecting user stacks at all ...
>> >
>> > It is a bit diametricical to the prevailing Forth "philosophy" of sacrificing
>> > safety for speed.
>> I seldomly see stack errors in code once it is debugged. There might be
>> unchecked code paths for situations that I initially thought extremely
>> unlikely.
>>
>> What I notice in my own code is lots of errors with illegal memory access.
>> The reason it appears so frequenly is that I know that this type of error
>> is almost perfectly caught by the system and is very easy to correct,
>> so I just run the word without carefully desk-checking that portion of
>> the code.
>>
>> The same happens when I program in C, I tend to run code with
>> complicated macros and library calls without carefully looking
>> up the documentation and have the debugger disassemble or
>> untangle the confusing parts :--)
>>
>
> True, running on an OS, signal SIGSEGV is the most important error signal to catch.
> Without extra guard cells, stack over/underflow will also trigger SIGSEGV.
>
> I used to have two program versions: DEBUG with all error-checks incl. paranoid
> runtime checks enabled, and RELEASE without error checking.
>
> But I found out that on the average DEBUG is just about 5-7 % slower than RELEASE.
> Therefore today with modern CPUs there is so much application speed reserve
> more often than not, that I just leave the DEBUG version in place.

Strange, isn't the whole point of interactive programming/debugging that
it runs correctly the first time? But perhaps you were both talking about
C where not only do you doubt library code or your ability to use it, but
your own code as well. With so many unknowns at play, it is any wonder C
turns programmers into barn stormers or paranoids. I was browsing Arduino
forums and was surprised how many times users were told 'don't worry about
the compiler warnings - it runs fine'.

dxforth schrieb am Sonntag, 30. Januar 2022 um 00:50:07 UTC+1:
> On 30/01/2022 00:34, minf...@arcor.de wrote:
> > Marcel Hendrix schrieb am Samstag, 29. Januar 2022 um 12:20:53 UTC+1:
> >> On Saturday, January 29, 2022 at 9:23:13 AM UTC+1, minf...@arcor.de wrote:
> >> > dxforth schrieb am Samstag, 29. Januar 2022 um 01:05:11 UTC+1:
> >> > > On 29/01/2022 06:55, Gerry Jackson wrote:
> >> > > > ...
> >> > > > Of course other systems that I quoted where the simple accesses do
> >> > > > appear to work may be corrupting something that has no visible effect in
> >> > > > such simple non-standard examples.
> >> > > Ideally a system would be designed such that even if a user makes a
> >> > > simple stack error it won't trash the system. Fine if the system/OS
> >> > > can sense under/overflow before it happens but least harm done if it
> >> > > can't.
> >> > Ideally user errors like stack underflow should throw an exception _without_
> >> > crashing the system.
> >> >
> >> > Perhaps system words should use their own stacks/registers without
> >> > affecting user stacks at all ...
> >> >
> >> > It is a bit diametricical to the prevailing Forth "philosophy" of sacrificing
> >> > safety for speed.
> >> I seldomly see stack errors in code once it is debugged. There might be
> >> unchecked code paths for situations that I initially thought extremely
> >> unlikely.
> >>
> >> What I notice in my own code is lots of errors with illegal memory access.
> >> The reason it appears so frequenly is that I know that this type of error
> >> is almost perfectly caught by the system and is very easy to correct,
> >> so I just run the word without carefully desk-checking that portion of
> >> the code.
> >>
> >> The same happens when I program in C, I tend to run code with
> >> complicated macros and library calls without carefully looking
> >> up the documentation and have the debugger disassemble or
> >> untangle the confusing parts :--)
> >>
> >
> > True, running on an OS, signal SIGSEGV is the most important error signal to catch.
> > Without extra guard cells, stack over/underflow will also trigger SIGSEGV.
> >
> > I used to have two program versions: DEBUG with all error-checks incl. paranoid
> > runtime checks enabled, and RELEASE without error checking.
> >
> > But I found out that on the average DEBUG is just about 5-7 % slower than RELEASE.
> > Therefore today with modern CPUs there is so much application speed reserve
> > more often than not, that I just leave the DEBUG version in place.
> Strange, isn't the whole point of interactive programming/debugging that
> it runs correctly the first time? But perhaps you were both talking about
> C where not only do you doubt library code or your ability to use it, but
> your own code as well. With so many unknowns at play, it is any wonder C
> turns programmers into barn stormers or paranoids. I was browsing Arduino
> forums and was surprised how many times users were told 'don't worry about
> the compiler warnings - it runs fine'.

Well ... just don't let them get close to serious devices. Product lawyers could sue the
hell out of them.

On 30/01/2022 19:50, minf...@arcor.de wrote:
> dxforth schrieb am Sonntag, 30. Januar 2022 um 00:50:07 UTC+1:
>> On 30/01/2022 00:34, minf...@arcor.de wrote:
>> > Marcel Hendrix schrieb am Samstag, 29. Januar 2022 um 12:20:53 UTC+1:
>> >> On Saturday, January 29, 2022 at 9:23:13 AM UTC+1, minf...@arcor.de wrote:
>> >> > dxforth schrieb am Samstag, 29. Januar 2022 um 01:05:11 UTC+1:
>> >> > > On 29/01/2022 06:55, Gerry Jackson wrote:
>> >> > > > ...
>> >> > > > Of course other systems that I quoted where the simple accesses do
>> >> > > > appear to work may be corrupting something that has no visible effect in
>> >> > > > such simple non-standard examples.
>> >> > > Ideally a system would be designed such that even if a user makes a
>> >> > > simple stack error it won't trash the system. Fine if the system/OS
>> >> > > can sense under/overflow before it happens but least harm done if it
>> >> > > can't.
>> >> > Ideally user errors like stack underflow should throw an exception _without_
>> >> > crashing the system.
>> >> >
>> >> > Perhaps system words should use their own stacks/registers without
>> >> > affecting user stacks at all ...
>> >> >
>> >> > It is a bit diametricical to the prevailing Forth "philosophy" of sacrificing
>> >> > safety for speed.
>> >> I seldomly see stack errors in code once it is debugged. There might be
>> >> unchecked code paths for situations that I initially thought extremely
>> >> unlikely.
>> >>
>> >> What I notice in my own code is lots of errors with illegal memory access.
>> >> The reason it appears so frequenly is that I know that this type of error
>> >> is almost perfectly caught by the system and is very easy to correct,
>> >> so I just run the word without carefully desk-checking that portion of
>> >> the code.
>> >>
>> >> The same happens when I program in C, I tend to run code with
>> >> complicated macros and library calls without carefully looking
>> >> up the documentation and have the debugger disassemble or
>> >> untangle the confusing parts :--)
>> >>
>> >
>> > True, running on an OS, signal SIGSEGV is the most important error signal to catch.
>> > Without extra guard cells, stack over/underflow will also trigger SIGSEGV.
>> >
>> > I used to have two program versions: DEBUG with all error-checks incl. paranoid
>> > runtime checks enabled, and RELEASE without error checking.
>> >
>> > But I found out that on the average DEBUG is just about 5-7 % slower than RELEASE.
>> > Therefore today with modern CPUs there is so much application speed reserve
>> > more often than not, that I just leave the DEBUG version in place.
>> Strange, isn't the whole point of interactive programming/debugging that
>> it runs correctly the first time? But perhaps you were both talking about
>> C where not only do you doubt library code or your ability to use it, but
>> your own code as well. With so many unknowns at play, it is any wonder C
>> turns programmers into barn stormers or paranoids. I was browsing Arduino
>> forums and was surprised how many times users were told 'don't worry about
>> the compiler warnings - it runs fine'.
>
> Well ... just don't let them get close to serious devices. Product lawyers could sue the
> hell out of them.

The only detail such lawyers care about is how much you're worth.

dxforth <dxforth@gmail.com> writes:
>Strange, isn't the whole point of interactive programming/debugging that
>it runs correctly the first time?

It has advantages in various situations. E.g., one use I have heard
is to test out whether hardware actually behaves as advertized. I
tend to use it to investigate parts of a program when one of the
pre-written tests fails; no point in not recording the tests.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Saturday, January 29, 2022 at 5:50:07 PM UTC-6, dxforth wrote:

> turns programmers into barn stormers or paranoids. I was browsing Arduino
> forums and was surprised how many times users were told 'don't worry about
> the compiler warnings - it runs fine'.

The few C programmers I worked with produced quality code
but not one of them would bother to clean up compiler warnings.
--
me

On 1/02/2022 02:39, S Jack wrote:
> On Saturday, January 29, 2022 at 5:50:07 PM UTC-6, dxforth wrote:
>
>> turns programmers into barn stormers or paranoids. I was browsing Arduino
>> forums and was surprised how many times users were told 'don't worry about
>> the compiler warnings - it runs fine'.
>
> The few C programmers I worked with produced quality code
> but not one of them would bother to clean up compiler warnings.

Interesting. From a user's perspective it doesn't inspire confidence.
Why when compiling the DX-Forth sources with TASM/MASM there are nil
warnings (the last time I checked anyway :)