Re: diffutils 2.8.1 ISO C90 compliance patch

[Paul Edwards]

From: "Paul Eggert" <address@hidden>
> > Users have no choice.  It doesn't work otherwise.
> 
> The port you sent may not work otherwise, but another MVS port might
> work more compatibly.  For example, diff3 could put the sub-diff
> output into files, and then read the files.  

It is not natural to create files on the fly in MVS.  You need
to specify the files upfront, before calling the executable.
And even then, the executable receives a "handle" (a DD
name) for the file, not the filename itself.

> It could do this
> transparently to "diff3", as part of its implementation of pipe(...)
> and fork().

These are basically unimplementable on MVS.  All those
things in the C90 standard that say "implementation-defined"
are basically designed for systems like MVS.  The filename
string is "implementation defined", which is why you
shouldn't hardcode filenames.  A typical string passed to
fopen() on MVS is "dd:INPUT".

In the JCL you set up before executing the program you
then have a DD statement of the form:

//INPUT DD DSN=DIFFUTIL.SOURCE(DIFF3),DISP=SHR

That's how native MVS works.  It can be made C90 compliant,
because the standard is flexible enough to cater for systems
like MVS.  That's what's so great about C90.  It's a universal
language.

> > There is no concept of directories on MVS.  There's nowhere
> > to create a "/sys/types.h".
> 
> You shouldn't need to create "/sys/types.h"; it should suffice to
> create "lib/sys/types.h", just as there is already a "lib/alloca.h".
> And "diff" doesn't care whether it's a single file named "sys/types.h"
> (with a slash in its name), so perhaps you can just create that -- I
> assume MVS allows slashes in file names?

No it doesn't.  Filenames are basically 8.8.8(8).  But that's not what
programs expect.  Programs expect an 8-character DD name.
It is up to the JCL (Job Control Language) or CLIST to associate
a filename with a DD name before calling the executable.

There's nowhere to put a sys/types.h or lib/sys/types.h.  It is
a non-standard include and should not be used.  string.h is a
standard include and can be used without #ifdefs.  But not
sys/types.h.  It should be excluded by default.  It is non-standard
and doesn't exist on MVS and can't exist on MVS.  It's not MVS
that is non-compliant, it is programs that include sys/types.h that
are non-compliant.

BFN.  Paul.