Where did I see that non-recursive directory handling c-example?

[hceline]

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?

[Olaf Barthel]

Originally Posted by hceline

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?

While I don't remember where you might have seen it, I have some charmingly overengineered 'C' example code which demonstrates how to do this, in case you are interested. Are you?

[hceline]

Yes, please.

[Olaf Barthel]

Originally Posted by hceline

Yes, please.

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).

[hceline]

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.

[Minuous]

"for", "do" and "while" are just for iteration; they have nothing to do with recursion.

[hceline]

Thank you. I did not realize the distinction at the moment. This answers all my questions on this issue.

[Thomas Richter]

Originally Posted by hceline

Unless my memory is playing tricks on me, the text I'm looking for stated that one should avoid recursive functions.

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.

[hceline]

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".

[Thomas Richter]

Originally Posted by hceline

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.

Unfortunately, AmigaOs does not define a protocol here. Most libraries assume that there is "sufficient" stack space avaialble, without defining what "sufficient" is. In some rare cases, there is an explicit stack check and automatic stack swapping involved. Intuition as an example does that - it checks the stack usage of its callers for *some* functions that are known to take a lot of stack, such as EasyRequest(), and if there is not enough stack space available, it will allocate more and run the function with a swapped stack.

Originally Posted by hceline

One is dealing with linked lists of unknown length.

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.

Originally Posted by hceline

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.

You might be surprised - it is even worse. The dos.library currently cannot handle paths longer than 256 characters at all, and an attempt to feed a longer path will not even trigger an error condition - it will just forward an invalid path to the file system.
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.