This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

GNUWIN32 coding standards



I have made a few very minor modifications to some of the files
distributed with the user tools and I would like to know what coding
standards I should follow in order to minimize the amount of work you
have to do to incorporate the changes into the standard distribution
(should you decide to do so) and to minimize the amount of rework I
will have to do to get the changes to the point that you would
consider accepting them.  Specifically, I have made the following
changes:

1) Changed the default value for 'flag_sparse' in "cp.c" from
   'SPARSE_AUTO' to 'SPARSE_NEVER' because of W95's stupid behavior of
   padding a file with random swap space date rather than zeros when
   seeking beyond the end of a file.

2) Added code to "diff.c" to avoid calling 'stat()' for a filename
   called "/dev/null".  Apparently, CYGWIN.DLL allows a program to
   open "/dev/null" and handles reading and writing from the file
   appropriately, but 'stat()' was not modified similarly.  (Note that
   this is a personal theory -- I have not had the time to verify this
   in the code for CYGWIN.DLL myself).  I had to make this change in
   order to support my port of CVS to CYGWIN32.

Note that these changes are temporary fixes to workaound deficiencies
in CYGWIN.DLL.  IMHO the correct way to fix these problems is to
change the behavior of CYGWIN32, but I don't have the time nor the
intestinal fortitude to attempt that task yet.

3) Changed "cmp.c" to open its input files in binary mode rather than
   text mode.  Unfortunately, I have since found that this causes some
   "configure" scripts to fail when they attempt to do something like
   "echo foo | cmp - foo".  I will probably back up and add a "-b"
   flag to "cmp" and just alias "cmp" to be "cmp -b" at some point.

4) Changed "od.c" to open its input files in binary mode.

As I said, I probably will not submit the first two items for
inclusion in the standard distribution because they simply hide more
serious flaws in the DLL (IMHO), so my questions apply more to the
last two items.

1) Should I conditionalize my CYGWIN32 specific changes on
   __CYGWIN32__?

2) Is there a "standard" way (probably using autoconf/configure, with
   which I have had very little experience) to determine whether a
   system supports/needs the "b" flag for 'fopen()'?  (Or should I
   simply conditionalize my changes to "od.c" and "cmp.c" on
   __CYGWIN32__)?

3) I have looked at the source for GCC and have seen how you use
   $(exeext).  Should I make similar modifications to Makefile.in and
   (this I have never attempted before) configure.in for packages
   that I end up playing with?  It seems to me that I cannot install
   my new versions without doing something about the .exe extension
   (on my W95 boxes).

4) Is there a standard mechansim for telling configure/make that I
   would like to install the binaries stripped?

Thank you for any answers you may care to give.
-- 
--patrick


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]