[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: diffutils 2.8.1 ISO C90 compliance patch

From: Paul Edwards
Subject: Re: diffutils 2.8.1 ISO C90 compliance patch
Date: Wed, 15 Nov 2006 08:37:20 +1100

From: "Paul Eggert" <address@hidden>
> > Because you can't portably do a pipe, I
> > added 2 extra positional parameters to diff3 so that you
> > have to do the individual diffs outside of diff3 and pass
> > the results in as parameters.
> I'm afraid that part of the change is pretty much a nonstarter; users
> of diff3 wouldn't put up with that.

Users have no choice.  It doesn't work otherwise.  Regardless,
on MVS I have put the 2 calls 2 diff and 1 call to diff3 inside
a JCL PROC (think script) so that the user only needs to provide
3 filenames.

> We'd need a better solution, if
> you really want to run diff3 on your platform.

Yes, I really want to run diff3 on MVS.  It is an incredibly
useful tool.  It should be taught at university as one of the
fundamental tools of programming.  It would increase
productivity and quality control worldwide.  I don't know
why this program is such a well-kept secret.  And the
highly sophisticated merging that CVS provides, based on
the concept of diff3.

> > + #if HAVE_SYS_TYPES_H
> >   #include <sys/types.h>
> > + #endif
> For this sort of thing, I suggest you create an empty file lib/sys/types.h.
> That way, you don't have to modify the source code.

There is no concept of directories on MVS.  There's nowhere
to create a "/sys/types.h".  There are ridiculous checks for
things like whether you can include string.h or not, when
string.h is standard.  Why not a check for non-standard includes?

> >   #ifndef __attribute__
> >   /* This feature is available in gcc versions 2.5 and later.  */
> > ! # if 1 || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
> >   #  define __attribute__(Spec) /* empty */
> >   # endif
> I don't understand why this change was needed.  I assume __attribute__
> was not defined but __GNUC__ was defined?  If so, why redefine __attribute__
> to nothing?  GCC supports __attribute__.

You're right.  It is no longer causing me a problem.  I don't
know what the original problem was.

> > + #ifdef SIGPIPE
> >          SIGPIPE
> > + #endif
> It's a bit more complicated than that, since it'd mean a comma just
> before the } and some compilers don't like that.

I think a compiler needs to accept that in order to be C90 compliant.
Now that GCC 3.2.3 has been ported to MVS, everyone should have
a free C90-compliant compiler available.  Admittedly the runtime
library provided (PDPCLIB) is not C90-compliant yet.  I look
forward to the day when everyone has a free C90 compiler with
no known bugs and a public domain C90 runtime library with no
known bugs.  1990 here I come!

> A better fix is below.


> >   # define sigprocmask(how, n, o) \
> > !     /*((how) == SIG_BLOCK ? *(o) = sigblock (*(n)) : sigsetmask (*(n)))*/
> >   #endif
> This fails on BSD hosts that have sigblock and sigsetmask but not
> sigprocmask.  But we can add a test for that, as shown below.
>  # define sigprocmask(how, n, o) \
>      ((how) == SIG_BLOCK \
>       ? *(sigset_t *) (o) = sigblock (*(n)) \

I commented it out because the 3rd parameter (o) can be 0,
and that means that code resolves to *(sigset_t *)0 = something,
which is going to cause a core dump if executed.

BFN.  Paul.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]