www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/11/20/10:00:59

To: simon AT tesla DOT ee DOT mcgill DOT ca ( Simon Chamlian tlf 340-1590)
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: quite confusing
Date: Sun, 20 Nov 94 14:25:07 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>

> Well you got me REAL confused now!
> I downloaded the latest version of DJGPP (i.e djdev112; dif26;
> bnu24 gas23; gcc260; gpp260 etc)!
>
> Than I received e-mails stating that
>
>
> 1) Somebody uploaded a corrected version of stat() and fstat()
>   library functions for DJGPP.  The first version had several bugs
>   which would crash your machine in DPMI mode.  
>
> 2) Somebody else ported GNU Diffutils 2.6 to DJGPP.
>
> [snip]
>
> What is going on?????
>
> If there are bugs in version 112 of djgpp, how come there is no
> maintenance files for this version or is there one that has not
> been announced?

Last question first: yes, there are maintenance releases for
1.12, two of them--1.12m1 and 1.12m2, they can be found on any
SimTel mirror, probably the same one you've got 1.12 in the
first place.

But they have nothing to do with the uploads which confused you.
Those uploads are add-ons to the standard package made by
volunteers (I am one of them) to improve on the ``official''
distribution.  Things which are broken in the ``official''
distribution indeed get fixed in the maintenance releases, but
what about adding functionality?  If you see some functionality
which is absent in the distribution, and is sometimes required
or useful, do you necessarily call it a bug?

The new versions of f?stat() make these functions much more
compatible with their Unix namesakes, even though in DOS world
this is *very* hard to do.  The original versions distributed
with libc.a aren't broken, they just don't return some fields
of struct stat as Unix-born programs expect them (e.g., inode
is returned 0).  Anybody who ever had to port a Unix program
to DOS bumped on the fragment like this:

   if (stbuf1.st_dev == stbuf2.st_dev && stbuf1.st_ino == stbuf2.st_ino)
      assume the files are the same;

Under DOS this is a bug: the program will think all files on any
drive are the same file.  These and many other portability-related
problems are corrected in that version.  DJGPP is not broken here,
you will see the same problems in any DOS-based C library.
Work is under way to incorporate the improved versions in DJGPP v2.0,
but I thought DJGPP community would benefit from these even before
that, and so uploaded them to omnigate.  The note about bug under
DPMI related to the previous version of those same improved functions,
not the ones in the current DJGPP library.

Diffutils 2.6 on omnigate are a complete port of this GNU package.
It includes Diff, Diff3, Cmp and Sdiff, all of them work on both
text and binary files.  DJGPP 1.12 only includes Diff and Cmp;
its Diff loses on binary files, and Cmp thinks all files are the
same in the above spirit.  The version on omnigate doesn't have
these problems.  Diffutils 2.7 (released by GNU about a month ago)
have a PC/ subdirectory which is still in beta, and so wasn't
included in the official 2.7 distribution on GNU ftp site, but
anybody who wants to build a full DJGPP version of Diffutils 2.7
right out of the box can ask me and I will mail him the contents
of that directory.  Hopefully, the next version of Diffutils
will have it officially included.

Other uploads you've mentioned were done for similar reasons: they
try to bring to you things which either aren't included in the
standard distribution (like imake) or which improve on them.  With
all due respect, I don't see how a wealth of free software can be
a nuisance, or even a cause of confuse.  Every such upload has a
README file which explains its rationale and is usually included
in the announcement so you don't have to download the package just
to see if you need it.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019