Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Fri, 18 Oct 2024 06:00:54 -0700
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <86h699woop.fsf@linuxsc.com>
References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <memo.20241006163428.19028W@jgd.cix.co.uk> <2024Oct7.093314@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@mips.complang.tuwien.ac.at> <ve5ek3$2jamt$1@dont-email.me> <ve6gv4$2o2cj$1@dont-email.me> <ve6olo$2pag3$2@dont-email.me> <73e776d6becb377b484c5dcc72b526dc@www.novabbs.org> <ve7sco$31tgt$1@dont-email.me> <2b31e1343b1f3fadd55ad6b87d879b78@www.novabbs.org> <ve99fg$38kta$1@dont-email.me> <veh6j8$q71j$1@dont-email.me> <vej5p5$1772o$1@dont-email.me> <vejagr$181vo$1@dont-email.me> <vejcqc$1772o$3@dont-email.me> <20241014190856.00003a58@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Fri, 18 Oct 2024 15:00:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6b29217a9f0925357c063ddd8fabd2b5"; logging-data="3460863"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/k10ncmyv3tFUj46cjQETQHDAFx72ULSg="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:WSRhHS9Kvt+gTA4qV5NQ9OZFOVE= sha1:oIr8kEL8QdBWqYhN+PduaZ0aX6s=
Xref: csiph.com comp.arch:109800

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 14 Oct 2024 17:19:40 +0200
> David Brown <david.brown@hesbynett.no> wrote:

[...]

>> My only point of contention is that the existence or lack of such
>> instructions does not make any difference to whether or not you can
>> write a good implementation of memcpy() or memmove() in portable
>> standard C.
>
> You are moving a goalpost.

No, he isn't.

> One does not need "good implementation" in a sense you have in mind.
> All one needs is an implementation that pattern matching logic of
> compiler unmistakably recognizes as memove/memcpy.  That is very easily
> done in standard C. For memmove, I had shown how to do it in one of the
> posts below.  For memcpy its very obvious, so no need to show.

You have misunderstood the meaning of "standard C", which means
code that does not rely on any implementation-specific behavior.
"All one needs is an implementation that ..." already invalidates
the requirement that the code not rely on implementation-specific
behavior.