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

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Sender: Scott Klement <klemscot@xxxxxxxxxxxx>



On Wed, 16 Oct 2002, Richard B Baird wrote:
>
> 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.
>

Glad that explanation helped.


> and now another potentially stupid question.
>

Please stop saying this.  None of your questions are stupid.

> 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?

Well, the answer to that question is that it could've been designed to do
it's own memory allocation, but I decided not to do that.

Here are a few reasons why:

     1) Not everyone is comfortable with pointers and memory allocations.
          By letting the caller supply the memory, the caller can choose
          to use a normal array instead of working with pointers.

     2) Likewise, the caller can choose to use a user space, etc,
          which wouldn't be possible if FTP_list did the allocating.

     3) The calling program would be required to de-alloc the list, or
          else I'd have to supply a subprocedure which would dealloc
          the list, and the caller would be required to call it.
          Again, because not everyone is comfortable with pointers and
          memory allocations, this would make FTP_list seem complicated
          and unwieldy.   With my current strategy, it writes the data
          to an array, which seems "simple" to most people.

     4) For the advanced user, the FTP_listraw routine gives him the
          flexibility to do whatever he wishes as far as options for
          storing the data.   He can do nearly anything he wants to
          do with the filenames without having to understand the
          FTP protocol.

> Because once ftp_list (or list2array) is finished, that memory
> becomes volatile?
>

Allocations made with ALLOC and REALLOC are not placed in automatic
storage, if that's what you're asking.  In other words, they're not
deleted when the subprocedure ends.   Consequently, you have to make
sure that the pointer you're using to track that allocation is also
not going to tbe deleted when the subproc ends.

If that's not what you mean, then I'm not sure what you mean by "volatile."
Usually, when I refer to memory being volatile, I mean that it will
be lost when you turn off the computer.   (In other words, data stored in
an array is volatile, data stored in a file on disk is not.)  But that
doesn't seem to be what you mean, here...

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