search for files

[Herbert Rosenau]

yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code, the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?

It's easy. We'll use the OS/2 APIs when on OS2 or xyz-AOIs when on the
system xyz. But never use the Windows-APIs when not on a Windows
version that accepts then.

Yes, it is possible to write programsd compatible to any specified
number of systems one likes. A proven method for that is to write
wrappers around system specific code and avoiding stirctly to write a
single system specific statement outside such wrappers and marked as
systemspecific functions or modules.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Keith Thompson]

Ok, thanks for that reference, lots of interesting reading there. I
don't see that it shows that calling system() with a non-NULL pointer
invokes undefined behaviour, though the majority view seemed to be
that the standard had no way of defining the behaviour (and for some
that counted as UB in all but name, a point I can see but which I
think confuses the use of the term UB).

C99 3.4.3:

undefined behavior

behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on
integer overflow.

C99 4p2:

If a shall or shall not requirement that appears outside of a
constraint is violated, the behavior is undefined. Undefined
behavior is otherwise indicated in this International Standard by
the words undefined behavior or by the omission of any explicit
definition of behavior. There is no difference in emphasis among
these three; they all describe behavior that is undefined.

As I understand it, that makes
the call implementation defined (which the standard also cannot
define, but requires the implementation to), which is not the same as
undefined.

Here's what the standard says about system() (C99 7.20.4.6):

If *string* is a null pointer, the *system* function determines
whether the host environment has a _command processor_. If
*string* is not a null pointer, the *system* function passes the
string pointed to by *string* to that command processor to be
executed in a manner which the implementation shall document; this
might then cause the program calling *system* to behave in a
non-conforming manner or to terminate.

The standard uses boldface (which I've represented as *...*) and
italics (which I've represented as _..._).

This doesn't actually say that the behavior of system() with a
non-null argument is undefined, but behaving "in a non-conforming
manner" seems to me to be about as undefined as you can get.

Of course, an implementation is free to document the behavior.

[...]

 

[David Thompson]

No. There is no reason to assume directories exist on a file
system. As an example, consider the CP/M-80 file system. Which
supported a lot of software.

That didn't have multiple (user or hierarchical) directories, but it
did have A (single, one) directory, which is all the OP asked for. I'm
pretty sure it didn't have an 'API' (then just an OS function number)
to enumerate the directory. Which as I recall was at a fixed location
and definitely in a fixed format, so easy enough to read on your own.

RT-11 similarly had a single directory per volume, in a fixed format
at a fixed location (block 6 IIRC), and no API. Heck, I remember
patching damaged RT-11 dirs/volumes with DDT or equivalent.

And 'a lot' of software is arguable. Even for its day, compared to
larger machines then existing. _Enough_ software, I'd agree.

- formerly david.thompson1 || achar(64) || worldnet.att.net