[Proj] NADCON, et al.

[Glynn Clements]

Gerald I. Evenden wrote:

> > > The following is something that should work on Linux and probably BSD,
> > > Unix but I have *no idea* if it will work on any of the Microsoft
> > > compilers.  If anyone is so inclined could you compile and test the
> > > following.
> >
> > MSVC doesn't have readdir().
> 
> That figures.  Small wonder I have so much respect for M$.

To be fair, readdir() is POSIX, not ANSI C (ANSI C doesn't have any
concept of directories, and only a vague notion of files), and
Microsoft doesn't aim to provide Unix.

The Windows equivalent is FindFirstFile, FindNextFile, FindClose.

> > MinGW has readdir(), but the d_type field isn't present.
> 
> Of course d_type is a critical element.
> 
> > POSIX only specifies d_name; d_type originates from BSD, and isn't
> > generally found on SysV-derived Unices. Even on Linux, only some
> > filesystems support it.
> >
> > If you want better portability at the expense of performance, use
> > stat() rather than the d_type field.
> 
> It seems that stat(2) may also have system dependencies, for example does 
> st_mode provide S_ISREG indication.

The S_ISxxx macros are standard, although S_ISSOCK and S_ISLNK weren't
present in earlier versions of POSIX.

> If one ignores M$, would opendir, readdir (just to get file names) and stat(2) 
> be a more reasonable route?

Yes; that's the standard mechanism.

> The most critical element with this basic method is to get the damn file 
> names.  Otherwise a preoperation with a shell program of some sort and an 
> ancillary program is required to create a special file.

d_name is standard, and XSI adds d_ino. Any other fields are
platform-specific extensions.

-- 
Glynn Clements <glynn at gclements.plus.com>