what happened to diropen, dirnext & dirclose?

[sverx]

I tried to compile a, well, not-so old project of mine and it returns

Code: Select all

c:/.../main.c:82: undefined reference to `diropen'
c:/.../main.c:89: undefined reference to `dirnext'
c:/.../main.c:102: undefined reference to `dirclose'

Any hint? Where did they disappear?

[elhobbs]

you should use opendir, readdir, and closedir. I think that diropen, etc. are non standard.

[sverx]

I see. BTW I was using those because I saw them in the examples on the chishm libfat page... (and they were working until... somewhen 2011...)

I rewrote that code part using this example on libnds documentation website anyway.

Thanks!

[elhobbs]

IIRC there were some stability issues with diropen - different struct size or something along those lines - probably a thread on it if you care to search. instead of fixing it, they were dropped for the C standard versions.

[WinterMute]

There wasn't a way to fix them, the functions were dependent on the programmer supplying a large enough buffer and apparently nobody was capable of doing that. The API would have needed to change to make the functions safer so I decided we'd be better off using standard functions instead.

[sverx]

[...] the functions were dependent on the programmer supplying a large enough buffer and apparently nobody was capable of doing that [...]

You mean this? (taken again from chishm's libfat page)

Code: Select all

char filename[MAXPATHLEN]; // always guaranteed to be enough to hold a filename

[WinterMute]

yeah, apparently people are incapable of using that, I have bug reports in my inbox with people using 256, 512, 1024, NAME_MAX, PATH_MAX, FILENAME_MAX ...

Then there's stuff like this - MAXPATHLEN isn't actually guaranteed to hold a full path, it's merely an arbitrary maximum.

https://bugzilla.mozilla.org/show_bug.cgi?id=412610

In the end, the dir* functions were non standard so it seemed better to remove them in favour of more standard, portable code.

[sverx]

[...] MAXPATHLEN isn't actually guaranteed to hold a full path, it's merely an arbitrary maximum. [...]

I see. BTW file names (not full paths) shouldn't be longer than 255 UTF-16 chars, which I believe cannot be longer than 255*2*2... so 1024 shouldn't give any problem... at least I never had any problem/bug report with my XM7Play XM/MOD Player, which used the aforementioned functions and char array...

BTW... thanks