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

[Arne Vajhøj]

On 5/25/2021 9:31 AM, Bill Gunshannon wrote:
> On 5/25/21 8:46 AM, Arne Vajhøj wrote:
>> On 5/24/2021 9:06 PM, Bill Gunshannon wrote:
>>> On 5/24/21 7:58 PM, Dave Froble wrote:
>>>> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>>>>> The choice of implementation language does not decide the 
>>>>> functionality
>>>>> of an operating system. It is however a major factor in how easy or 
>>>>> not
>>>>> it is to port that operating system to another architecture.
>>>>
>>>> Even when (hawk, spit, gag) C doesn't work the same on different 
>>>> architectures?
>>>
>>> Got any good examples?  Are you sure it wasn't just a bad
>>> implementation?
>>
>> C compiler bugs are getting relative rare today.
>>
>> But the C standard leaves a lot to the implementation.
>>
>> Character set, actual size of basic data types, ones vs
>> twos complement, FP format, data alignment, actual size of
>> size_t, a lot around volatile etc.etc..
> 
> Except6 for "volatile" all of this is architecturally or OS
> dependent and not a part of the C language.

All these items are explicit listed as implementation
defined in the C standard.

And defined in other more high level
languages standard.

>> This makes it possible to write a "hardware close"
>> C compiler on any platform.
> 
> Probably a deliberate decision.

Yes.

>> 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.

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.

Doing an >> on it? Better be sure that it is positive. The
result of right shifting a negative int is also implementation
defined.

> 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.

>                                                         Where
> does Fortran define size_t?  Where does Pascal define floating
> point format?  Where does Python define data alignment?  COBOL
> does let you select character set but it, too, is limited to
> what is supported by the architecture or OS.  Can't select
> Fielddata on a PC using Ryan/McFarland COBOL.  :-)

Fortran 1957
Cobol 1959
Pascal 1970

Python does not define alignment for ctypes Structure. But we can blame
that on C.

Documentation states:

<quote>
By default, Structure and Union fields are aligned in the same way the C 
compiler does it. It is possible to override this behavior by specifying 
a _pack_ class attribute in the subclass definition. This must be set to 
a positive integer and specifies the maximum alignment for the fields. 
This is what #pragma pack(n) also does in MSVC.
</quote>

So if C got it then Python would get it.

> There was a company once that made a car that also functioned
> as a boat.  Can we now say that all other cars are deficient
> because they don't float?

No.

But one can say that both floating and non-floating are not
guaranteed characteristics of a car.

Arne