On Sun, 1 Feb 2026 at 12:52, Martin D Kealey <[email protected]> wrote:
>
>
> 3-D imaging involves a lot of data, so how about:
> • an MRI scanner?
> • a self-driving car's lidar scanner?
> • an airplane's auto-nav?
> • an anti-missile missile guidance system?

This is again a case of satisfying the minority at the expense of the majority.

Of all the devices in the world, the total count of the above 4
devices should be under 2%.

According to my approach, minorities have to take care of themselves.

Minorities can get around my limitation of limiting all inputs to a maximum
of 75% of the RAM size in 2 ways:

1. Increase the RAM size.
2. Modify the source code and remove the checks.

If we satisfy the minority, then this will mean that we are putting the majority
of the users at the risk of getting hacked and active hacking is happening
even today.

I started following the hacking news from August 2024 and even till
now hacking is
happening and everything hasn't been fixed, and so probably, hacking will keep
happening in the future also.

If we take care of the minority, then the majority will have to put in
effort to validate the
inputs before calling insecure functions and I think that the number
of man hours
put in this effort by the majority will greatly exceed the number of
man hours put in
by the minority.

>
> The problem is, it's very close to maximised already, because any changes are 
> likely to break existing code, sometimes in ways that degrade or entirely 
> abrogate security.
>

Currently there is no maximization. POSIX/glibc functions don't
validate the inputs at all.
Same is the problem with PHP/Javascript code. Maybe the same problem
is with the Python
code too.

> Security improvements will require retiring/deprecating existing interfaces 
> and creating new ones, but that would conflict with the Austin Group's remit: 
> to document common/shared existing practice.

This is like the case of IPv4 and IPv6. We don't know what the future
will bring.

So, yes, a new standard will be needed for the safety of this world.

And I believe in changing with changing times. If we don't change with
time, then we can be rendered useless.

However, the C language itself has no issues. The main issue is that
people who write code in C or in
other languages, they don't validate the inputs.

I have seen lots of different code in different languages over my 25
years of career, and I see that software
engineers just don't have the habit of validating the inputs.

Amit

        • Re: ... Amit via austin-group-l at The Open Group
      • Re: Will... Guy Harris via austin-group-l at The Open Group
        • Re: ... Amit via austin-group-l at The Open Group
  • Re: Will the Open... David A. Wheeler via austin-group-l at The Open Group
    • Re: Will the... Amit via austin-group-l at The Open Group
      • Re: Will... David A. Wheeler via austin-group-l at The Open Group
        • Re: ... Guy Harris via austin-group-l at The Open Group
        • Re: ... Amit via austin-group-l at The Open Group
          • ... Niu Danny via austin-group-l at The Open Group
            • ... Amit via austin-group-l at The Open Group
          • ... Amit via austin-group-l at The Open Group
            • ... G. Branden Robinson via austin-group-l at The Open Group
              • ... Amit via austin-group-l at The Open Group
            • ... Guy Harris via austin-group-l at The Open Group
            • ... Andries E. Brouwer via austin-group-l at The Open Group
              • ... Amit via austin-group-l at The Open Group
          • ... Jonathan Wakely via austin-group-l at The Open Group
            • ... Amit via austin-group-l at The Open Group
      • Re: Will... Guy Harris via austin-group-l at The Open Group
      • Re: Will... Amit via austin-group-l at The Open Group
        • Re: ... Guy Harris via austin-group-l at The Open Group

Reply via email to