Craig A. Berry wrote:
At 4:46 PM -0500 12/13/05, John E. Malmberg wrote:
Obviously we are so far not having the desired effect of reducing
stack space usage.
Obviously I have an error somewhere.
I do see one example of allocating a long filename on the stack:
$ SEARCH/EXACT vms.c "tmp[VMS_MAXRSS"
char *dirend, *rslt, *cp1, *cp3, tmp[VMS_MAXRSS];
Dunno if that's the problem or not.
I do not think so. Currently VMS_MAXRSS is still set to 255 characters
until I get the rest of the code caught up.
I have started a debug build now of the latest blead.
It just failed with:
I32 unlnk (const char*);
....^
%CC-E-PARNOIDENT, Missing identifier.
at line number 3660 in file PERL_BUILD_ROOT:[000000]perl.h;1
By the way, what options are you passing to the CONFIGURE.COM?
I enabled threads, but not upcalls.
Change 26344 is suggesting to me that my vmsish.h is out of sync
with blead also because there should not be any conflicts with using the
system supplied utime.h file so that time values are properly modified
on ODS-5 volumes.
Yes, I missed checking in the vmsish.h matching changes.
Handling access dates when they are enabled has been on the to-do
list for awhile, but simply replacing the home-grown routine loses
the effect of the vmsish 'times' pragma. We could either extend the
FID and DID fiddling of the current implementation so it does for the
posix-style dates what it's already doing for ATR$C_REVDATE, or we
could beef up the wrapper around decc$utime so it does the time shift
if requested.
I looked at extending the current implementation, and the result did not
look like it would be easy to do or maintain.
I will look again at the vmsish 'times' impact after I find out what is
causing the problem with the threaded build.
-John
[EMAIL PROTECTED]
Personal Opinion Only
