Re: "RESET"

On 6/5/2025 1:36 AM, Martin Brown wrote:

Some code is irreversibly complex and necessarily so, but a lot of it is just the software equivalent of a rats nest prototype in electronics but treated as if it was production quality code. Management's ship it and be damned policy since they always wanted their sales target bonus.

If you look at the *process* used by most shops to create software, there
is very little discipline -- or, overly much (e.g., DoD).  Both extremes
leave the developer(s) floundering; the coder who is "playing it by ear"
(without a formal specification telling him EXACTLY what he is developing
and EXACTLY the criteria that will be tested/validated) and the one who
is so far removed from the function of the product that he has little
insight into what might be wrong about the specification that's been imposed
on him.
Blame the powers that be in both cases.  Often, folks who have been promoted
to their level of incompetence (Peter Principle)

However, it is entirely true that some code will be marked as very high
complexity by tools and yet easily and simply understood by human
reviewers.  If that is happening a lot in a code base, automatic tools
(at least the ones you are trying) are not going to be much use.

 That goes with the territory but you only have to look at it once.

If the code has a formal specification, then you have a set of test
criteria that come with the territory.  And, solvers (e.g., KLEE)
that can look for holes in the implementation.

I would expect AI to be more useful in the context of static error
checkers, simulators, and fuzz testers rather than code coverage at
run-time.

>
Forgotten from earlier: "Just to be clear - are you using
non-intrusive statistical code coverage tools (i.e., a background
thread, timer, etc., that samples the program counter of running code?
Or are you using a tool that does instrumentation when compiling?  I'm
trying to get an understanding of the kinds of "false hits" you are
seeing."
>
The focus here is non-intrusive code evaluation tools.
>
We also use intrusive tools and instrumentation in the integration
lab.

 I find instrumentation often disturbs the problem that I am looking at. YMMV

Analyzing a "textual representation" leaves too many possibilities for
reality to differ from theory.
Are you 100% sure the compiler is bug free?
Do you completely understand the execution environment (e.g., multithreading
and multiprocessing) and the hazzards it creates?
Are you sure the textual description of the solution (program) fits the
actual problem model?
Are you sure the developed model reflects the reality of the application?
Are you sure the opcode fetched from memory *now* is exactly the one
that the compiler placed, there?  Ditto for data?

I'm a fan of Intel's vTune for finding hotspots in serious code.

I litter code with invariants -- and leave them in the production release
(changing the FAIL case to panic()).  The cost (space and time) is relatively
insignificant.  The reassurance it provides (when "can't happen" actually
DOES happen!) far outweighs the burden on the product's performance.
If you are "sure" of something, then you shouldn't have any problem making
that declaration in the codebase.  Then, if your assumption is proven wrong,
you have positive evidence of it -- instead of wondering why it did something
unexpected.
By far, the problems I see in most products are poorly defined models.
E.g., we have a stove/oven with a "big knob" UI:  spin to choose from
a list of values; press to make the selection.  Trivial to implement.
*Appears* to handle all cases (it doesn't).  Easy to verify -- as a
stand-alone module.
The problem comes when you put that module into a device that has multiple
processes running concurrently.  E.g., there are two ovens, each with a
cooking mode and temperature constraints.  PLUS, individual timers to
limit the operation.  Plus another general purpose timer.
But, only one UI ("big knob").  So, if the user is engaged with the UI
(e.g., to set or alter the operating conditions of one of the ovens
OR the timer) and one of the processes (oven 1, oven 2, timer) needs
attention, there's only one way to talk to that process (big knob) but
that is "busy" with some other activity.
As a result, you end up "STOPping" the process (e.g., turn off the oven)
and then restarting it -- just to disconnect the UI from the process
that was in use when the "other" process called for service.
I can just see the developer "proving" that his implementation worked -- one
process at a time:  "See, this is how you select CONVECTION instead of
BAKE; and this is how you specify the temperature; and the cook time;
and what to do when that time is expired; and how to START the process!"
But, clearly never tried to actually *use* that while other processes were
active in the device.
These sorts of bugs have to be caught at the specification level; by
someone *designing* the model instead of just naively implementing a
part of it.