definitions again (Developers)
> #include <io.h>
> _WCRTLINK extern long _findfirst( const char *__filespec,
> struct _finddata_t *__fileinfo );
> _WCRTLINK extern int _findnext( long __handle,
> struct _finddata_t *__fileinfo );[/code]
I was thinking - this burdens the library or OS with
the need to do pattern matching (filespec), and
quite possibly not everyone would agree on which
wildcards to use.
In addition, the library would need to make a decision
on whether to match case or not.
On more thing is that it requires fixed space to be
allocated for the resultant data. If this had been
done right from the start, there would be nowhere to
store a long filename, and not enough space to do
so either.
Would it be more appropriate to simply open a directory -
if you want portability anyway - and then let the
library give you the next entry, so the onus is on it
to provide sufficient space? I believe POSIX has an
opendir() which may provide guidance.
I think long filenames would operate in conjunction with
FILENAME_MAX - if a C90-extended platform suddenly starts
returning long filenames - fine, they should have increased
FILENAME_MAX at the same time, so applications are not
affected at the source code level.
Ultimately my interest is in well-behaved programs at the
source code level. Not binary backward compatibility with
everything from CP/M upwards (not that MSDOS 1.0 did that
anyway).
BFN. Paul.
Complete thread:
- definitions again - kerravon, 19.03.2024, 07:28 (Developers)
- definitions again - samwdpckr, 19.03.2024, 13:15
- definitions again - ecm, 19.03.2024, 14:15
- definitions again - kerravon, 19.03.2024, 15:52
- definitions again - marcov, 19.03.2024, 20:11
- definitions again - kerravon, 20.03.2024, 09:39
- definitions again - marcov, 20.03.2024, 12:53
- definitions again - kerravon, 20.03.2024, 13:36
- definitions again - marcov, 20.03.2024, 12:53
- definitions again - kerravon, 20.03.2024, 09:39
- definitions again - Oso2k, 21.03.2024, 01:00
- definitions again - Oso2k, 21.03.2024, 01:06
- definitions again - kerravon, 21.03.2024, 10:53
- definitions again - Oso2k, 22.03.2024, 18:30
- definitions again - marcov, 22.03.2024, 22:49
- definitions again - Rugxulo, 11.04.2024, 02:48
- definitions again - kerravon, 11.04.2024, 04:03
- definitions again - Rugxulo, 13.04.2024, 05:55
- definitions again - kerravon, 13.04.2024, 08:53
- definitions again - boeckmann, 14.04.2024, 16:12
- definitions again - kerravon, 20.04.2024, 03:09
- definitions again - tom, 20.04.2024, 09:50
- definitions again - kerravon, 20.04.2024, 10:57
- definitions again - tom, 21.04.2024, 11:27
- definitions again - kerravon, 21.04.2024, 15:18
- definitions again - tom, 21.04.2024, 21:20
- definitions again - kerravon, 22.04.2024, 02:48
- definitions again - kerravon, 22.04.2024, 03:37
- definitions again - Rugxulo, 23.04.2024, 02:13
- definitions again - kerravon, 23.04.2024, 10:04
- definitions again - Rugxulo, 23.04.2024, 02:13
- definitions again - tom, 21.04.2024, 21:20
- definitions again - kerravon, 23.04.2024, 11:50
- definitions again - Rugxulo, 23.04.2024, 13:03
- definitions again - kerravon, 21.04.2024, 15:18
- definitions again - tom, 21.04.2024, 11:27
- definitions again - kerravon, 20.04.2024, 10:57
- definitions again - tom, 20.04.2024, 09:50
- definitions again - kerravon, 20.04.2024, 03:09
- definitions again - boeckmann, 14.04.2024, 16:12
- definitions again - kerravon, 13.04.2024, 08:53
- definitions again - Rugxulo, 13.04.2024, 05:55
- definitions again - bretjohn, 11.04.2024, 16:34
- definitions again - glennmcc, 11.04.2024, 18:15
- definitions again - kerravon, 11.04.2024, 04:03
- definitions again - Oso2k, 22.03.2024, 18:30
- definitions again - kerravon, 21.03.2024, 10:53
- definitions again - samwdpckr, 19.03.2024, 13:15