Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Wed, 10 Jul 2024 21:52:04 +0200
Organization: A noiseless patient Spider
Lines: 153
Message-ID: <v6mop4$21n94$3@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me>
 <v687h2$36i6p$1@dont-email.me> <871q48w98e.fsf@nosuchdomain.example.com>
 <v68dsm$37sg2$1@dont-email.me> <87wmlzvfqp.fsf@nosuchdomain.example.com>
 <v6ard1$3ngh6$4@dont-email.me> <v6b0jv$3nnt6$1@dont-email.me>
 <87h6d2uox5.fsf@nosuchdomain.example.com> <v6d779$6rk5$2@dont-email.me>
 <v6e76u$c0i9$1@dont-email.me> <v6esqm$fian$2@dont-email.me>
 <v6f7vg$hgam$1@dont-email.me> <20240707164747.258@kylheku.com>
 <v6gl83$s72a$1@dont-email.me> <v6h8ao$ur1v$1@dont-email.me>
 <v6jhk3$1drd6$1@dont-email.me> <v6k13q$1g7uk$1@dont-email.me>
 <v6k66h$1g2d7$1@dont-email.me> <v6kat7$1hcpd$1@dont-email.me>
 <v6ldug$1qbpb$1@dont-email.me> <v6mi70$20iud$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Jul 2024 21:52:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c985da9317a18f8af2811d5dea43797f";
	logging-data="2153764"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19MvW+l5gyXC+zX4KUXEQh6Owkno4FCxOo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:r36yErD/AviiCehU9Q+qUTXRC6o=
In-Reply-To: <v6mi70$20iud$1@dont-email.me>
Content-Language: en-GB
Bytes: 7500

On 10/07/2024 19:59, BGB wrote:
> On 7/10/2024 2:41 AM, David Brown wrote:
>> On 09/07/2024 23:43, BGB wrote:
>>> On 7/9/2024 3:22 PM, James Kuyper wrote:
>>>> On 7/9/24 14:55, BGB wrote:
>>>> ...
>>>>> The pass by reference, in this context, was referring to the ABI, not
>>>>> to C itself.
>>>>>
>>>>> It looks from C's POV as-if it were by-value.
>>>>>
>>>>>
>>>>> Which it is, depends on if one is looking at things at the language
>>>>> level, ABI level, or IR level, ...
>>>>
>>>> The C standard doesn't explicitly specify pass by value, or pass by
>>>> reference, or anything other passing mechanism. What it does say is 
>>>> what
>>>> a programmer needs to know to use the passing mechanism. It says that
>>>> the value of a function parameter that is seen by the code inside that
>>>> function is a copy of the value passed as an argument to the function.
>>>> The copy can be modified without changing the original. When a C
>>>> function's declaration looks as though it takes an array as an 
>>>> argument,
>>>> what that declaration actually means is that it takes a pointer 
>>>> value as
>>>> an argument, and it is a copy of that pointer's value which is seen
>>>> inside the function, and can be modified. The memory it points at is 
>>>> the
>>>> same as the memory pointed at by the corresponding argument.
>>>>
>>>>
>>>
>>>
>>> We can probably agree that, in C:
>>>    typedef struct Foo_s Foo;
>>>    struct Foo_s {
>>>      int x, y, z, a, b, c;
>>>    };
>>>
>>>    int FooFunc(Foo obj)
>>>    {
>>>      obj.z = obj.x + obj.y;
>>>      return(obj.z);
>>>    }
>>>
>>>    int main()
>>>    {
>>>      Foo obj;
>>>      int z1;
>>>      obj.x=3;
>>>      obj.y=4;
>>>      obj.z=0;
>>>      z1=FooFunc(obj);
>>>      printf("%d %d\n", obj.z, z1);
>>>    }
>>>
>>> Should print "0 7" regardless of how the structure is passed in the ABI.
>>>
>>
>> ABI's are irrelevant to how the language is defined and how these 
>> expressions are evaluated.  ABI's go along with details of the target 
>> - they can affect implementation-dependent behaviour but no more than 
>> that.  (A clear example would be that alignment of fundamental types 
>> would normally be specified by an ABI.)
>>
>> So code that does not depend on implementation-dependent behaviour, 
>> such as your code here, will necessarily give the same results on all 
>> conforming C implementations.
>>
> 
> These sorts of things may bleed through depending on implementation 
> choices (and "optimizations"). 

No, they will not.

If a compiler makes manipulation of the code and gives results contrary 
to the requirements of the language, it is a compiler bug, not an 
optimisation.

> Part of the compiler writing fun is 
> trying to get good performance while also not breaking C semantics.

Sure.  But you always aim to err on the side of "slow and correct" 
rather than "fast but possibly wrong".  And you read the language 
standards so that you know what "correct" means.

> 
> But, a language more aggressively tuned for performance would have even 
> more wonky semantic edge cases than it does already.

Nope.  You can make a wonky, buggy compiler if you like, but don't 
expect anyone to be happy about it.

(And to be clear - you can, if you want, write a compiler that only 
works for a subset of C, or that works for a language that is only 
similar to C.  It could be useful for what you need for your own work, 
but it won't be a conforming C compiler.  And if you get this particular 
stuff wrong, it's not just a minor non-conformance - it's a killer bug 
for anyone else who writes "normal" C.)

> 
> 
> Though, one thing is that some of my code (both my Boot ROM) and 
> kernel/shell program, has a bunch of sanity check stuff to try to detect 
> if ISA features are broken or if the compiler breaks C semantics in 
> various ways. But, there are limits to how much coverage there is with 
> such checks.
> 
> 
>>>
>>> Though, one possibility being to relax the language such that both "0 
>>> 7" and "7 7" are valid possibilities (the latter potentially allowing 
>>> more performance by not needing to make a temporary local copy). 
>>> Though, AFAIK, C doesn't really allow for this.
>>
>> It continues to astound me that people who claim to have written C 
>> compilers themselves - such as you and Bart - regularly show 
>> misunderstandings or ignorance about things that are clear in the C 
>> standards and which I would expect any experienced C programmer to know.
>>
>> All arguments to function calls in C are passed by value.  This is in 
>> 6.5.2.2p4 - it is a two sentence paragraph that you really ought to 
>> have read before even considering writing a C compiler.
>>
>> Some languages do have pass by reference (or other types of parameter 
>> passing systems), and would give "7 7".  C is not such a language.  
>> (And I have never heard of a language that would either result.)
>>
> 
> Note that I did say: "C doesn't really allow for this".

No, you wrote "AFAIK" ...  That says you are not sure.

> 
> As-in, such a tweak would allow things to be slightly faster, but would 
> violate the language rules as it stands.
> 
> 
>>>
>>> An implementation could be clever though and only make local copies 
>>> in cases where the structure is modified by the callee, as in the 
>>> example above.
>>>
>>
>> A clever implementation would turn the whole of main() into a single 
>> puts("0 7") call.
>>
>> Compliers can generate whatever code they like, as long as the results 
>> are correct hin the end.
>>