View unanswered posts | View active topics It is currently Sat May 26, 2018 6:40 pm



Reply to topic  [ 8 posts ] 
 what happened to diropen, dirnext & dirclose? 
Author Message

Joined: Wed Aug 12, 2009 2:56 pm
Posts: 90
Location: github.com/sverx
I tried to compile a, well, not-so old project of mine and it returns
Code:
c:/.../main.c:82: undefined reference to `diropen'
c:/.../main.c:89: undefined reference to `dirnext'
c:/.../main.c:102: undefined reference to `dirclose'

:o
Any hint? Where did they disappear?


Mon Apr 23, 2012 1:03 pm
Profile WWW

Joined: Thu Jul 02, 2009 1:19 pm
Posts: 349
you should use opendir, readdir, and closedir. I think that diropen, etc. are non standard.


Mon Apr 23, 2012 1:38 pm
Profile

Joined: Wed Aug 12, 2009 2:56 pm
Posts: 90
Location: github.com/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! :)


Mon Apr 23, 2012 2:47 pm
Profile WWW

Joined: Thu Jul 02, 2009 1:19 pm
Posts: 349
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.


Mon Apr 23, 2012 4:27 pm
Profile
Site Admin

Joined: Tue Aug 09, 2005 3:21 am
Posts: 1236
Location: UK
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.

_________________
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog


Mon Apr 23, 2012 9:11 pm
Profile ICQ WWW

Joined: Wed Aug 12, 2009 2:56 pm
Posts: 90
Location: github.com/sverx
WinterMute wrote:
[...] 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:
char filename[MAXPATHLEN]; // always guaranteed to be enough to hold a filename


Mon Apr 23, 2012 9:38 pm
Profile WWW
Site Admin

Joined: Tue Aug 09, 2005 3:21 am
Posts: 1236
Location: UK
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.

_________________
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog


Mon Apr 23, 2012 10:53 pm
Profile ICQ WWW

Joined: Wed Aug 12, 2009 2:56 pm
Posts: 90
Location: github.com/sverx
WinterMute wrote:
[...] 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... :roll:

BTW... thanks :)


Tue Apr 24, 2012 9:39 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 8 posts ] 

Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads