On 04.10.24 09:52, Kevin Chadwick via Dng wrote:

> 4 Oct 2024 03:17:42 Erik Christiansen via Dng < dng@??? >:

>

> > all healthy pointer work.

>

> I think you're trolling?

A sadly closed mind could make that mistake. Modern dogmas are no more

true than old. It can be useful to understand that aversion therapy

doled out to beginners to protect them from their own clumsy ineptitude

does not apply to competent practitioners with enough burnt fingers to

check their work, and enough skill to both avoid many pitfalls and

promptly debug any misfire. Over more than half a century of

programming, I have consistently used pointers throughout, never seeing

them as anything other than a useful mainstream coding element. If

you're programming in assembler there is no alternative - that's how the

CPU actually implements what is hidden by syntactic sugar in HLLs.

Electricians are allowed to work on 230 Vac circuits, while muggles are

not. That is not because electricians are high voltage insulators, but

because of expertise.

> All needless and dangerous and non portable "pointer work".

>

> Even misra C isn't safe or reliable.

>

> Quote from the below video.

> "All C programs contain undefined behaviour

>

>      Ex: 2-line program in Appendix I of MISRA C:2012

> "

>

> https://youtu.be/CVlkJ-ryeoQ?si=hq5NsfrcuqaX_5Xt

Yup, a dogmatic position needs supporting documentation. Good stuff.

I'll give marks for that. But it's just another writer's opinion.

What counts is what works.

In large OS-supported code bases, protective syntactic sugar can save a lot of money and time chasing bugs, but on Bare Iron, luxuries tend to be few, and  in providing pointers, C merely mimics the behaviour of the hardware. In assembler, they're unavoidable.

It seems clear that your experience is in the "cotton wool" environment

of coding on top of a protective OS, with support for all sorts of HLLs.

Coding on "Bare Iron" is a different world. It is much more DIY, with

much less fancy support. The dogmatists haven't been there, to learn

that the difference between theory and practice is much greater in

practice than it is in theory.

If you can compile an ADA program to run on an ATtiny2313, with its 2kB

(1000 instructions) of ROM, 128 bytes of RAM, Harvard architecture, and

a minimalist RISC instruction set, to control the on-chip PWM hardware

and I/O ports, e.g. to produce a 3-channel LED lamp dimmer with

elementary serial communications for remote control, then fear of

pointers might no longer be a capability limit.

But please don't forget that even passing a function parameter "by

reference rather than by value" is pointer work. In the function, the

"reference" is "dereferenced" by using that pointer to address the

array, struct, or whatever was passed - in reality by pointer.

Euphemisms can hide only so much, and only with complicity.

Erik

--

On the basis of evidence we may be sure that we are wrong

but we can never be sure that we are right.        - Richard Feynman