Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.std.c
Subject: Re: Does reading an uninitialized object have undefined behavior?
Date: Tue, 05 Sep 2023 05:39:57 -0700
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <867cp4pzdu.fsf@linuxsc.com>
References: <87zg3pq1ym.fsf@nosuchdomain.example.com> <87zg3pnuse.fsf@bsb.me.uk> <874jlxozzz.fsf@nosuchdomain.example.com> <87fs5hnipv.fsf@bsb.me.uk> <87a5vpnegz.fsf@nosuchdomain.example.com> <86a5uv95g7.fsf@linuxsc.com> <fcb2be8f-b346-421f-9804-5f94c93266b0n@googlegroups.com> <864jkz7hrm.fsf@linuxsc.com> <e043af84-3153-4097-9505-666869fcf727n@googlegroups.com> <867cpu5h8w.fsf@linuxsc.com> <a3199783-d8b7-4065-836b-08f647a6808en@googlegroups.com> <868r9xz0ek.fsf@linuxsc.com> <5+eRe7cp3yQjL4=AX@bongo-ra.co> <86sf82ulmb.fsf@linuxsc.com> <KvVxh3+WExIyDnM+5@bongo-ra.co> <86zg28t563.fsf@linuxsc.com> <S+3le+7=sc9SPmPL3@bongo-ra.co>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="6793c8bc2747e0ba6d3890411794594c"; logging-data="2084334"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19oTDwT01H2dtFhgr3uP4EzP3byC8dCgaE="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:rMFZ8QPqtIiZe+fzthTyn5yqK8Y= sha1:ZR7O2PME4rcI6p4iAPwWQre6VwA=
Xref: csiph.com comp.std.c:6563

Spiros Bousbouras <spibou@gmail.com> writes:

> On Wed, 30 Aug 2023 17:40:52 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

[...]

>> You're conflating writing something in C and writing something
>> in completely portable C.  It's already possible to do these
>> things writing in C.
>
> I wrote
>
>     One might want to experiment with different allocation
>     algorithms and it seems to me that this sort of thing is
>     within the "remit" of C. So ideally one should be able to
>     write it in C and prove , starting from the standard or
>     precise specifications in compiler documentation , that it
>     works correctly.  I don't necessarily mean prove the
>     correctness of the whole code but certain key parts.
>
> .This doesn't conflate anything.  One can do the writing but
> can one do the proving or something close ?

A substitute for malloc()/free() can be written in standard C.

A substitute for malloc()/free() can not be written in completely
portable standard C.

I hope this clarifies my earlier comments.