[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: revisiting the ftp_list problem



Sender: Scott Klement <klemscot@xxxxxxxxxxxx>



On Wed, 16 Oct 2002, Richard B Baird wrote:
>
> > It's legal.   The one thing that I do want to clarify, however, is that
> > YOU must allocate the memory that FTP_list will be using.  It does not
> > allocate it for you.
>
> this is where all this stuff get's fuzzy for me.  is it because once the
> procedure is finished, and I haven't allocated it before hand, it becomes
> volitile?

No, FTP_LIST writes the filenames to whatever area of memory you pass to
it as a pointer.  It assumes that you've taken the steps to ensure that
the memory address that's stored in the pointer is something that your
program has been given permission to use.

I'm trying to think of an analogy but having a hard time :)

The contents of a pointer are nothing more than a number that we call an
"address".  That address specifies a position in the computer's main
storage.  The very first byte of RAM byte be called "1", the second "2",
and so on... that's called an address.

Since there are many different processes running on your computer at any
given time, and they can't all use the same area of RAM.  Some central
process has to be in charge of giving programs RAM so that they don't
accidentally pick the same area of memory.   This is a function of the
operating system, and it's called "allocating"

A pointer is nothing but a variable that stores these addresses.  In fact,
on some computers (but not the iSeries) a pointer is nothing more than a
32-bit binary integer  (i.e. a 10U 0 in RPG).  In other words, it's just
a number signifying the "count of bytes" from the start of RAM... (The
term "offset" is often used in place of "count of bytes")

So, when you call FTP_list, you are passing it this "memory address", and
it is writing the file names to that area of memory.

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 is true of all memory used by all programs.  Normally, when you
access memory you declare a variable.  The compiler automatically adds
code to allocate memory for that variable when the program starts, and
automatically deallocates that memory when the program ends.

>
> so, to do it properly, run ftp_list once with a nbr of entries to retrieve
> (y) = 1, just to get the total number of entries found (x), then allocate
> memory for (x * 256) + 2560 (to account for any additional files that might
> have been added at that moment), call again and with y = x + 10 to get the
> actual file names into memory, read them by incrementing my pointer field
> as described before, and when done, DEALLOC the memory.
>
> Right?
>

Yes, it sounds like you understand perfectly.

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