hall@cod.NOSC.MIL (Robert R. Hall) (08/27/89)
All though C. E. Chew new ls.c may compile without errors on the
ST-ATARI and with Microsoft C, I got lots of error messages when
trying to compile with Version 1.3 Minix C compiler on the IBM-PC.
jerry@buita.BU.EDU <Jerry Shekhel> suggested he got rid of the
warning messaged by changing the statement
#define NIL ((void *)0)
to
#define NIL (0)
and after line 859 adding the statement
extern struct tm *localtime();
To get rid of the mutidefine error message, I found I need to
change the statement
#define BOOL(b) static char b = 0
to
#define BOOL(b) char b = 0
The following cdiff contains the total patches I needed to
get it to compile with MINIX on the IBM-PC
To compile this I used the command:
cc -DMINIX -Di8088 -T. -o ls ls.c
I have observed that this ls print dates that are more the a
year old for the year as 3888 instead of 1988
Robert R. Hall
hall@nosc.mil
----------------------- ls.cdif ----------------------------
echo x - ls.cdif
sed '/^X/s///' > ls.cdif << '/'
X*** /dr_a/ls/ls.c Mon Jul 31 08:30:03 1989
X--- ls.c Sat Aug 26 19:02:05 1989
X***************
X*** 43,51 ****
X #ifdef MINIX
X #include <minix/const.h>
X #include <minix/type.h>
X! #include <fs/const.h>
X! #include <fs/type.h>
X! #undef printf
X #endif
X
X #define DEFAULTDIR "." /* default for ls without args */
X--- 43,52 ----
X #ifdef MINIX
X #include <minix/const.h>
X #include <minix/type.h>
X! #include "../fs/const.h"
X! #include "../fs/type.h"
X! #undef printf
X! extern int errno;
X #endif
X
X #define DEFAULTDIR "." /* default for ls without args */
X***************
X*** 60,66 ****
X #define HALFYEAR ((long) 60*60*24*365/2) /* half year in seconds */
X #define BASEYEAR 1900 /* struct tm.tm_year base */
X
X! #define NIL ((void *) 0) /* nil pointer */
X
X /*
X * Flags are maintained in a bitmap. Access should be fast
X--- 61,67 ----
X #define HALFYEAR ((long) 60*60*24*365/2) /* half year in seconds */
X #define BASEYEAR 1900 /* struct tm.tm_year base */
X
X! #define NIL (0) /* nil pointer */
X
X /*
X * Flags are maintained in a bitmap. Access should be fast
X***************
X*** 82,88 ****
X * useful when working with the flags since these are
X * read-only.
X */
X! #define BOOL(b) static char b = 0
X #define EVAL(b,a) ((b ? b : (b = (a)+1)) > 1)
X
X /*
X--- 83,89 ----
X * useful when working with the flags since these are
X * read-only.
X */
X! #define BOOL(b) char b = 0
X #define EVAL(b,a) ((b ? b : (b = (a)+1)) > 1)
X
X /*
X***************
X*** 858,864 ****
X
X {
X struct tm *tmbuf; /* output time */
X!
X tmbuf = localtime(&t);
X (void) printf("%.3s %2d ",
X "JanFebMarAprMayJunJulAugSepOctNovDec"+tmbuf->tm_mon*3,
X--- 859,866 ----
X
X {
X struct tm *tmbuf; /* output time */
X! extern struct tm *localtime();
X!
X tmbuf = localtime(&t);
X (void) printf("%.3s %2d ",
X "JanFebMarAprMayJunJulAugSepOctNovDec"+tmbuf->tm_mon*3,
/cechew@bruce.OZ (Earl Chew) (08/28/89)
From article <1618@cod.NOSC.MIL>, by hall@cod.NOSC.MIL (Robert R. Hall): > > All though C. E. Chew new ls.c may compile without errors on the > ST-ATARI and with Microsoft C, I got lots of error messages when > trying to compile with Version 1.3 Minix C compiler on the IBM-PC. > jerry@buita.BU.EDU <Jerry Shekhel> suggested he got rid of the > warning messaged by changing the statement > #define NIL ((void *)0) > to > #define NIL (0) This change is relatively harmless although I would punt for ((char *) 0). > and after line 859 adding the statement > extern struct tm *localtime(); Hmm. The only reason this line isn't in ls.c is that I thought that time.h should contain a function prototype for it. Mine has such a prototype. So do the Pyramid and Sun systems here. > To get rid of the mutidefine error message, I found I need to > change the statement > #define BOOL(b) static char b = 0 > to > #define BOOL(b) char b = 0 The whole idea of BOOL(b) is to compute the result of a complicated boolean expression once. That's why it's static. On subsequent passes, the result of the expression is available in the boolean and the expression need not be reevaluated. Changing from static to automatic means that the boolean expression is reevaluated on every pass through the code. Is this because of a bug in the Minix C compiler? > > I have observed that this ls print dates that are more the a > year old for the year as 3888 instead of 1988 This does not appear to be a fault of ls. ls does not format the dates. localtime() does. It appears that your localtime is broken. The errno declaration has been inserted for the next release (real soon now). This also includes fixes to support fifos and limited stuff for symbolic links (which aren't in yet). Please note the bug fix which has been posted for getdents.c. Funny, I didn't notice that error ever occurring. Earl
wsincc@eutrc3.urc.tue.nl (Wim van Dorst) (08/28/89)
In article <1618@cod.NOSC.MIL> hall@cod.NOSC.MIL (Robert R. Hall) writes: >I have observed that this ls print dates that are more the a >year old for the year as 3888 instead of 1988 I had a similar problem with a ls.c submitted by Mr. Housel some time ago. He pointed out to me that my localtime() (the official 1.4a version of it) is broken according to the Unix books. It should give YEAR-1900, instead is gives the year itself. You can either mend the localtime() function, or adapt ls.c. The question of myself: there have been I believe three postings of ls.c's recently. As the one by Mr. Housel is written for speedy display I am extremely happy with it. Has any tried them all and if so: How do they compare? Met vriendelijke groeten, Wim van Dorst, wsincc@tuerc3.urc.tue.nl