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

[Bill Gunshannon]

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.

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

Probably a deliberate decision.

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

The same being true of pretty  much every other language.  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.  :-)

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?

bill