Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!convex!rosenkra From: rosenkra@convex.com (William Rosencranz) Newsgroups: comp.sys.atari.st Subject: Re: New standards for MiNT programs? Message-ID: <1991Mar19.215534.6339@convex.com> Date: 19 Mar 91 21:55:34 GMT References: <1991Mar18.140901.1919@doe.utoronto.ca> <1991Mar19.150319.25547@qut.edu.au> <1991Mar19.105139.28070@jato.jpl.nasa.gov> Sender: news@convex.com (news access account) Organization: Convex Computer Corporation; Richardson, TX Lines: 80 Nntp-Posting-Host: convex1.convex.com In article <1991Mar19.105139.28070@jato.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: >In article <1991Mar19.150319.25547@qut.edu.au> lunnon@qut.edu.au writes: >>Huh, why not use dirent ??? This seems reasonably capable and is portable >>to boot ??? > >I'd agree, we should try to hide the Fsfirst/Fsnext layer completely and >use the Unix *dir routines instead. (This seems reasonable, given MiNT's >apparent intent to provide as much BSD functionality as possible...) i agree with howard. only i think we should pick BSD or USG, but *not* both. POSIX would be ideal (does it say anything about opendir/readdir/etc? wait, i just checked... yes it does). i have to carry around ndir.h direct.h dirent.h and all the others from BSD and USG for portability. let's stick to posix, here, and do away with the duplicity. posix synopsi are: #include #include DIR *opendir(dirname) char *dirname; struct dirent *readdir(dirp) DIR *dirp; void rewinddir(dirp) DIR *dirp; int closedir(dirp) DIR *dirp; typical use: DIR *dirp; struct dirent *d; char *name; if ((dirp = opendir(name)) != (DIR *) NULL) { while ((d = readdir(dirp)) != (struct dirent *) NULL) do_something_with_d (d); if (closedir(dirp)) check_errno_right_now (); } else check_errno_right_now (); issues: is int 32-bit or 16-bit (note that DTA uses 16-bit ints in its low-level structure)? will we support errno? zillions of (incompatible) versions (like lharc :-). note that readdir(3) provides space for the dirent so it gets wacked on subsequent calls. i have more or less working (BSD-flavor) versions of these. it made porting BSD ls(1) easy. only trouble is it is slow as molasses for large directories. i think gulam's ls reads the FAT directly. it is great for recursive searches (i think i have a traverse(3), if memory serves). i try to hide Fsfirst/next as much as i can, though they do exist in MSDOS. not that both turbo C and MSC on the PC support the *dir functions (i think) so applications port to dos, too (if that matters). my versions use Fs*. in general, i think sticking to posix as much as possible is what we really want. that's why it was developed, after all: portability. speed is another issue altogether. in fact, with these functions in place, it should be possible to use either GEMDOS Fs* or direct reads of the FAT and still have a portable program. if u want, i can post these... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com