I may not have put my finger on this properly.

I was aiming to have a "pure C90 suite of applications" that
ship with PDOS.

And the C compiler - my flavor of gcc 3.2.3 - is one such pure
C90 application - it takes in a bunch of text files, and outputs
another text file. 400,000 lines of C code.

But one of the "essential" apps I ship is msged, which allows you
to read and write Fidonet messages (basically similar concept to
Usenet *.nws files). And this app reads messages (*.MSG) from
a bunch of directories, which I specify in a config file. I'm happy
with the config file (text file, can be read with C90). But now I
have a challenge of opening a directory, and I can't do that with
C90. I would need to use POSIX or a rival of POSIX.

It occurred to me that if I were to use a database for all these
messages, I could have a btree or whatever implementation in
C90 and in my config file I just point to the database file, and
everything can be done in C90. msged would be portable, as
desired. Even to something like traditional MVS that doesn't
have directories in the normal sense.

Then it occurred to me that my OS, PDOS, already has a fat.c
to process a FAT filesystem. Instead of using a database, why
not just expand fat.c to make sure all the desired operations are
there, and have a filesystem in a single file?

But ideally I would have a special filename, like !CURFS (for
current filesystem) where my fat.c code detects that file and
instead of operating on a (large) file that contains a filesystem,
instead does POSIX etc calls to directly update the normal
filesystem.

I don't mind my C library containing system-specific stuff (and
for traditional MVS, that is pretty radical). So why not also allow
this C library - fat.c - to similarly contain system-specific stuff?
Does that still meet the definition of "C90 portable"? Also, I'm
willing to extend C90 into a "new, practical, standard", so a
filesystem suite of functions could be included in that, if that is a
logical thing to do.

And the definition of "practical" I am using is "being able to stand
up my essential suite of apps to do Fidonet messaging, on an
arbitrary platform (ie portable)".

While it may seem that I rigidly stick with C90, that was only the
case until I found a compelling reason to move from there, with a
very basic goal. C90 has been mostly sufficient up till now.

So I'm looking for dilineation of responsibilities, and whether a
filesystem API is a better way of encapsulating opendir() etc.

Thanks. Paul.



--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)