Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.os.linux.misc
Subject: Re: VMS
Date: Fri, 20 Jun 2025 10:19:08 +0100
Organization: A little, after lunch
Lines: 48
Message-ID: <103392c$lpbg$5@dont-email.me>
References: <wCqdnYde9MIbmND1nZ2dnZfqnPadnZ2d@giganews.com>
 <102ka4k$9umt$2@dont-email.me> <87tt4i9nw5.fsf@eder.anydns.info>
 <102l0h9$fjtb$5@dont-email.me>
 <Z2udned3u9ZgqtP1nZ2dnZfqnPudnZ2d@giganews.com>
 <slrn1054j9c.3ce8.candycanearter07@candydeb.host.invalid>
 <PpudnVnCnvuYxc_1nZ2dnZfqnPudnZ2d@giganews.com>
 <wwva564xjps.fsf@LkoBDZeT.terraraq.uk>
 <4_GdncCsf-Nqe8n1nZ2dnZfqnPSdnZ2d@giganews.com>
 <wwv5xgqkfl9.fsf@LkoBDZeT.terraraq.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 20 Jun 2025 11:19:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="59005c96598adc071216bb379c5cedd9";
	logging-data="714096"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1943hJdC/MHrmPtl2EVAZ9Cx9Zda2p9nzo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XSxjc1LmZqeJgMn8d7fYMmb2YiI=
In-Reply-To: <wwv5xgqkfl9.fsf@LkoBDZeT.terraraq.uk>
Content-Language: en-GB

On 20/06/2025 09:00, Richard Kettlewell wrote:
> c186282 <c186282@nnada.net> writes:
>> On 6/19/25 3:40 AM, Richard Kettlewell wrote:>
>>> c186282 <c186282@nnada.net> writes:
>>>     IMHO, stick to 'C' ... but use GOOD PRACTICES.
>>>
>>> The software industry has been trying this for decades now. It does
>>> not work.
>>
>> At some point, soon, they need to start flagging the unsafe functions
>> as ERRORS, not just WARNINGS.
> 
> The problem is not just a subset of unsafe functions. The whole language
> is riddled with unsafe semantics.
> 
> There is some movement towards fixing the easy issues, e.g. [1]. But the
> wider issues are a lot harder to truly fix, so much so that one of the
> more promising options is an architecture extension[2]; and there
> remains considerable resistance[3] in the standards body to fixing other
> issues, despite their recurring role in defects and vulnerabilities.
> 
> [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf
> [2] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
> [3] https://www.youtube.com/watch?v=DRgoEKrTxXY
> 
> Most languages after C designed these issues out, one way or another.
> The clever bit is figuring out how to combine performance and safety,
> and that’s what language designers have been working out, increasingly
> successfully.
> 
I don't really see how you can have a program that cannot write or read 
memory beyond the intentions of the original programmer.

Sure if its a different process but simply reading one byte beyond the 
end of a buffer is going to be hard.

And probably make the language very hard to use when you are dealing 
with multi-typed data.

I do like, at a cursory glance, the second link. Hardware that protects 
memory is a great leap forward

-- 
For every complex problem there is an answer that is clear, simple, and 
wrong.

H.L.Mencken