Re: revisiting MY ftp_list problem - (not ftp_list's problem ;)

["Richard B Baird" <rbaird@xxxxxxxxxxxxxxxxxxxxx>]

Sender: "Richard B Baird" <rbaird@xxxxxxxxxxxxxxxxxxxxx>


Scott,

thanks for being so patient.

you explained a lot of things I already knew, but what brought it all home
to me was:

> If you don't first ask the operating system to allow you to use that
area,
> you'll have problems because that area of memory might be something
that's
> in use for some other purpose.  If this memory happens to be something
> that your job has authority to manipulate, then FTP_list would actually
be
> causing areas of memory to be corrupt.   If it isn't something that your
> job has authority to manipulate, then OS/400 will cause FTPAPI to crash.

this now makes perfect sense.  in other words, if i had described a based
array at 10 x 256, and passed that pointer to ftp_list, asking for 100 file
names, i would be doing 'the big no-no'.   that's dangerous - by not
understanding that one little thing, it could cause some serious problems.

and now another potentially stupid question.

why couldn't ftp_list (or an evil twin) do it's own memory allocation,
dynamically based on number of files found, passing offset and size back to
the caller?  Because once ftp_list (or list2array) is finished, that memory
becomes volatile?

thanks,

rick

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------