[Info-vax] The (now lost) future of Alpha.

[Chris]

On 08/05/18 19:16, Craig A. Berry wrote:


>
> But fopen, fwrite, fread, and fclose implemented in terms of open,
> write, read, and close, which are syscalls, not C library functions. I'm
> not sure whether a compiler would be more likely to use stdio or unix
> I/O, but just wanted to point out that it might well use things that are
> not in the C library. It doesn't matter as long as they are available,
> but it might play a role in what has to get done first when implementing
> a new compiler on a new OS port.
>

Sorry, but that's rubbish. These functions have been part of the
standard C library for decades. Check K&R or Harbison  & Steele if
you doubt that. Have you any idea just how rich the C library is these 
days ?. if you pert to new hardware or os, you just need  a slip layer
between the library functions and the underlying hardware, irrespective
of what hw drivers or file system is in use at lower layers..

One of the reasons why unix and C became so popular in the early days
is because the C library provides platform independent access to i/o,
storage and a shed load of other functions. If I write a c program for
any flavour of unix, or linux and don't try to be too clever, it will
almost always compile and run on anything else. So long as you don't
use stuff like bit fields (ugh), the compiler  generally sorts all
the endian stuff as well. I can quibble a bit about some of the
sloppy typing (eg: char is signed etc), historical, but it generally
just works...

Chris