Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 13 Sep 2024 23:16:19 +0000
Organization: Rocksolid Light
Message-ID: <6cd02e4b37b109607fb10dd02db9c668@www.novabbs.org>
References: <vaqgtl$3526$1@dont-email.me> <memo.20240830090549.19028u@jgd.cix.co.uk> <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com> <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z> <2024Sep11.123824@mips.complang.tuwien.ac.at> <vbsoro$3ol1a$1@dont-email.me> <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com> <865xqzg63u.fsf@linuxsc.com> <20240913144411.00005866@yahoo.com> <vc2ber$120mf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1962338"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$doapsM7vHJ9eBrLjaa6.Au19rgRq0WP5tQyh3YK6pzNPMyi8m.43G
Bytes: 3238
Lines: 54

On Fri, 13 Sep 2024 21:39:39 +0000, Thomas Koenig wrote:

> Michael S <already5chosen@yahoo.com> schrieb:
>> On Fri, 13 Sep 2024 04:12:21 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>
>>> > struct {
>>> >  char x[8]
>>> >  int  y;
>>> > } bar;
>>> > bar.y = 0; bar.x[8] = 42;
>>> >
>>> > IMHO, here behavior should be fully defined by implementation.  And
>>> > in practice it is.  Just not in theory.
>>>
>>> Do you mean union rather than struct?  And do you mean bar.x[7]
>>> rather than bar.x[8]?  Surely no one would expect that storing
>>> into bar.x[8] should be well-defined behavior.
>>>
>>> If the code were this
>>>
>>>     union {
>>>       char x[8];
>>>       int  y;
>>>     } bar;
>>>     bar.y = 0;  bar.x[7] = 42;
>>>
>>> and assuming sizeof(int) == 4, what is it that you think should
>>> be defined by the C standard but is not?  And the same question
>>> for a struct if that is what you meant.
>>
>>
>> No, I mean struct and I mean 8.
>> And I mean that a typical implementation-defined behavior would be
>> bar.y==42 on LE machines and bar.y==42*2**24 on BE machines.
>> As it actually happens in reality with all production compilers.
>
> Ah, you want to re-introduce Fortran's storage association and
> common blocks, but without the type safety.

FORTAN allowed::
subroutine1:
       COMMON /ALPHA/i,j,k,l,m,n
subroutine2:
       COMMON /ALPHA/x.y.z
expecting {i,j} which are INT*4 to overlap with x Read*8 ;...
{Completely neglecting the BE/LE problems,...}

>                                             Good idea, that.
> That created *really* interesting bugs, and Real Programmers (TM)
> have to have something that pays their salaries, right?
>
> SCNR