[Info-vax] misstatement of Unix origin [was Re: A portable VMS, was: Re: OS Ancestry]

[Arne Vajhøj]

On 5/25/2021 2:07 PM, Simon Clubley wrote:
> On 2021-05-25, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 5/25/2021 9:31 AM, Bill Gunshannon wrote:
>>> On 5/25/21 8:46 AM, Arne Vajhøj wrote:
>>>> But it also makes it a bit tricky to write a C
>>>> program with guaranteed behavior on all
>>>> standard compliant C compilers.
>>>
>>> The parts that are C will behave the same under any non-broken
>>> C compiler.  But stuff that is not a part of the C language is
>>> obviously going to be a crap shoot.
>>
>> Not true.
>>
>> Implementation defined behavior is features that exist in
>> all implementations of the language but behave differently.
>>
>> Let us take the example of int. Most C programs will have
>> a lot of variables of that type.
> 
> Even when they should be using unsigned integers but that's no
> different to any other languages that make signed integers the default.

Sometimes signed is needed.

But there are certainly a lot that should be unsigned.

>> But the C standard only guarantees that it can keep values
>> from -32767 to +32767. Any C program that relies on an
>> int variable keeping a value outside of that range is not
>> guaranteed to produce same result everywhere.
> 
> As you should well know Arne, that has been irrelevant for any new code
> for at least a couple of decades due to the introduction of data types
> whose size (and signed/unsigned attribute) _are_ guaranteed as part of
> the standard.
> 
> I am of course talking about (for example) uint8_t, int16_t, uint32_t, etc.
> 
> If you need a guaranteed integer size in your code, use one of the
> above or one of the various other similar data types instead of an int.

Then you know that your code will either work or not compile.

But there is no guarantee that it will work.

These types are optional in the standard.

int_leastn_t and uint_leastn_t are not optional but they are not
exactly widely used.

>>> The same being true of pretty  much every other language.
>>
>> No. It may be true of many languages more than 40 years old,
>> but it is not generally true of newer languages.
>>
>> Most newer languages define integers that are 16/32/64 bit
>> two's complement, FP's that are 32/64 bit IEEE, sizes/lengths that
>> are fixed bit size, memory models that define volatile
>> behavior etc.. And in memory alignment is typical made
>> irrelevant because it has to be specified explicit as part
>> of marshalling and unmarshalling.
> 
> C also has rules about the scope of volatile statements and what
> reordering of statements is and is not allowed by the standard
> between volatile points.

C volatile guarantees that access is not optimized away and that
volatile accesses are not reordered.

Which may be fine when used for direct HW access, but it totally
insufficient for multi-threaded programming.

A bunch of atomic stuff has been added to C 11 to try and solve that.

> Beyond that, you have to know your architecture for the small bits
> of your code that need volatile attributes and that level of detail
> does not depend on the programming language.

For many languages the behavior of volatile is defined in the
languages memory model. The generated code and runtime has to
ensure compliant behavior.

Arne