14 November 2023, 22:36 | #1 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 183
|
Where did I see that non-recursive directory handling c-example?
I can not relocate this example I read a while ago. I believed it was in a programming book I have as PDF. But searching the PDFs comes up just as empty as my recollection.
I remember the text was about stack usage. Either in shared libraries, or in code that was called in the context of some OS process. And then gave an example of walking a path(or scanning a directory tree), without using recursive functions. Do anyone with better recollection than me recognize where I might have read this? |
16 November 2023, 11:52 | #2 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 538
|
Quote:
|
|
16 November 2023, 13:31 | #3 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 183
|
Yes, please.
|
16 November 2023, 14:28 | #4 |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 538
|
Here you are - This was written for Kickstart 2.x or better, but the traversal method will work just fine on Kickstart 1.x (if you remove/replace the Kickstart 2.x-specific functions).
|
16 November 2023, 20:58 | #5 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 183
|
Thank you for the example. But unless my recollection is completely wrong(or I'm misunderstanding something basic), it is not analog to the example I was trying to relocate. Unless my memory is playing tricks on me, the text I'm looking for stated that one should avoid recursive functions. I only skimmed the text, and did not look twice at the example, because I just noticed it briefly while looking for some other info. Later when I needed it, and only remembering this much, I assume the example I'm looking for would be without any "for", "do" or "while" statements.
|
17 November 2023, 03:39 | #6 |
Coder/webmaster/gamer
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,706
|
"for", "do" and "while" are just for iteration; they have nothing to do with recursion.
|
17 November 2023, 06:34 | #7 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 183
|
Thank you. I did not realize the distinction at the moment. This answers all my questions on this issue.
|
17 November 2023, 08:25 | #8 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,432
|
You can always replace recursion with a stack. In this case, the stack would contain the locks of the currently walked directory and the FileInfoBlock structure. That being said, you can get away with less information on the stack, and the Bantam manual provides indications that the fib_Key data from the FileInfoBlock ought to be enough, but if you do so, you're really creating stress at the file system level as it potentially needs to reconstruct state information from that little data. I will not provide further details on this as it is really discouraged to do so.
|
17 November 2023, 10:48 | #9 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 183
|
My issue was not really the directory handling. That was just an artifact of me getting more hung up on the fact that I could not find the answer even-tough I'd recently seen it, than the issue itself.
My issue was about the stack usage for shared libraries, and the fact that I totally blanked on the existence of iteration as a word/concept. There are two code-bases in question. One is dealing with linked lists of unknown length. This code originates from a link library. And after transplanting it into a shared library, I was unsure how much modification was needed to reduce stack usage. The other is a old shared library that handles paths of unknown depth/length(but does not access the filesystem itself) I'm suspecting of using more stack than strictly necessary. But thank you for the extra detail. I would never have guessed that the magic google search phrase for relevant examples for reducing stack usage was "replace recursion with a stack". |
17 November 2023, 23:25 | #10 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,432
|
Quote:
There is really no specific protocol. If the linked list is too long, or cyclic, then operating on it make take very long, or never terminate. There is nothing in AmigaOs which prevents feeding a "too long" list to a function. Quote:
The best you can do is not working with paths at all. Instead, work with locks and file names, and navigate through a file system by means of Lock() and Parent(). This makes AmigaDOS somehwat fragile to handle, and it is quite different from *ix style operating systems where you frequently work with paths as character strings. This is for the above reason not advisable for AmigaDOS. Probably the only functions of the dos.library that could, in principle, work with arbitrarily long paths (provided the buffer is large enough) are AddPart(), FilePart() and PathPart(), but these functions never interact with handlers and thus never require the arguments to be converted to BSTRs. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Recursive coverdisks | coldacid | project.TOSEC (amiga only) | 9 | 27 February 2023 01:48 |
Compile directory, work directory and relative paths | phx | Coders. Asm / Hardware | 13 | 25 July 2022 15:31 |
Handling keys in MUI | AlfaRomeo | Coders. Blitz Basic | 6 | 18 August 2019 15:10 |
Recursive Directory Listing | atrionfo | support.Other | 4 | 01 July 2009 22:58 |
Cookie handling | alexh | project.EAB | 1 | 22 October 2007 21:52 |
|
|