Hi Paul,

"Thanks" to all who contributed. Aside from taking a wild guess at the use
of "d_namelen", I still haven't come up with any documentation showing the
issue (at least documentation that meant anything to an RPG pgmr).

You've already got a good answer from Jon, so I'm just going respond to your statement that you couldn't come up with the documentation...

If you want the official documentation from IBM, here it is in the Information Center:

That page states that d_namelen is "The length of the name in bytes, excluding the null terminator" and that d_name is "A string that gives the name of a file in the directory. This string ends in a terminating null, and has a maximum length of {NAME_MAX} bytes, not including the terminating NULL"

Seems clear enough that d_name is a null-terminated string, right? ("...string ends in a terminating null...")

It also seems clear to me what d_namelen means...

Here's the manual page for the %STR BIF:

That page states "%STR is used to create or use null-terminated character strings, which are very commonly used in C and C++ applications."

Seems pretty clear to me that %STR is designed for reading/using a null-terminated string (among other things), which is exactly what the readdir() manual page says it's providing.

As to why %ADDR() is used, the same page (for %STR) says:
"The first parameter must be a basing-pointer value. (Any basing pointer expression is valid, such as "%ADDR(DATA)" or "P+1".)"

Hope that helps.

Also, FWIW... I haven't benchmarked it, but I expect that %SUBST is faster than %STR because %SUBST simply copies bytes from the d_name field, whereas %STR() would have to first search for the x'00' (the "null", that is) and then copy the bytes.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].