From:	wdoyle AT bode DOT cdsp DOT neu DOT edu (Patrick Doyle)
Subject:	GNUWIN32 coding standards
11 Jul 1997 20:45:10 -0700 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<199707111507.LAA03648.cygnus.gnu-win32@cdsp.neu.edu>
Original-To:	noer AT cygnus DOT com
Original-Cc:	gnu-win32 AT cygnus DOT com
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

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 AT cygnus DOT com" with one line of text: "help".

- Raw text -