Sujet : Re: Cray style vectors
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.archDate : 11. Mar 2024, 20:30:38
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <usnm4u$3pitn$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Mozilla Thunderbird
On 11/03/2024 19:10, Michael S wrote:
On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Thomas Koenig <tkoenig@netcologne.de> schrieb:
>
David Brown <david.brown@hesbynett.no> schrieb:
On 20/02/2024 07:31, Thomas Koenig wrote:
>
Even further on the side: I wrote up a proposal for finally
introducing a wrapping UNSIGNED type to Fortran, which hopefully
will be considered in the next J3 meeting, it can be found at
https://j3-fortran.org/doc/year/24/24-102.txt .
>
In this proposal, I intended to forbid UNSIGNED variables in
DO loops, especially for this sort of reason.
>
(Testing a new news server, my old one was decomissioned...)
>
I was quite delighted, but also a little bit surprised that the
proposal (somewhat modified) actually passed.
>
Now, what's left is the people who do not want modular arithmetic,
for a reason that I am unable to fathom. I guess they don't like
multiplicative hashes...
What do they like?
To declare unsigned overflow UB? Or implementation defined? Or
trapping?
Speaking for myself only, I'd like a choice. For the most part, I consider overflow (signed or unsigned) to indicate an error in the code. The two appropriate actions then are a run-time error, or that the compiler assumes that such overflow does not happen for the purposes of optimisation. (Whether the choice of handling here is determined by the source code, or compiler options, or a combination of both, is another matter of choice.) And for some unusual code, I want overflow (signed or unsigned) to be defined behaviour - either wrapping, or with additional information about overflows or carries, or perhaps more special cases such as saturation.
Basically, I think it is a mistake for a language to pick one kind of treatment and pretend that this is /the/ correct handling of overflow. Different circumstances could call for a variety of different behaviours.
If I had to pick only one possible choice of treatment, then I suppose it would be wrapping - because sometimes you really need that in code, while UB based optimisation or run-time checking is just "nice to have" rather than essential. Standard C having UB for signed overflow and wrapping for unsigned overflow is a reasonable compromise when keeping things simple, but I'd prefer a choice.
(Similarly, I'd prefer a choice regarding another favourite source of UB and complaints in C - that of type-based alias analysis. I'd sometimes like 16-bit, 32-bit and 64-bit types that could alias anything, and I'd sometimes like 8-bit types that did /not/ alias anything.)