[9fans] fd2path

[9fans] fd2path

[Boyd Roberts]

I think fd2path's return value should be:

    -1 - error
     0 - pathname returned
    >0 - pathname returned, missing n bytes

In the last case you could loop on calling malloc until
you got the whole thing.  I think all static n byte buffer
writing functions should act like this and all return values
should be nul terminated.  Can't be hard to do and it'd make
life easier; a generic fd2path that uses a dynamically malloc'd
chunk of memory that grows as needs be, returning NULL or
a pointer to the (nul terminated) malloc'd area.

--
Boyd Roberts                               boyd@psycho-basket-case.org

    ``I come over here to kill them cocksuckers, not work for 'em''

          -- Moon Dog, _Pettibone's Law_, John Keene


Sent via Deja.com http://www.deja.com/
Before you buy.

[9fans] Re: fd2path

[Douglas A. Gwyn]

Boyd Roberts wrote:
> In the last case you could loop on calling malloc until
> you got the whole thing.

Um, you really think that is a good design?

Re: [9fans] Re: fd2path

[Boyd Roberts]

Douglas A. Gwyn wrote:
> 
> Boyd Roberts wrote:
> > In the last case you could loop on calling malloc until
> > you got the whole thing.
> 
> Um, you really think that is a good design?

yeah doug, whatcha gonna do when yer char buf[1024]; just ain't
big enough, huh?  upgrade to 5.n BSD?

-- 
    But I doubt if our present system [U.S. Army] will produce such
    an individual.  They are too: _abrasive_, opinionated, undiplomatic,
    nonconformist, and effective.
    
        -- Colonel David H. Hackworth (U.S. Army, Ret.)

Re: [9fans] Re: fd2path

[Douglas A. Gwyn]

Boyd Roberts wrote:
> Douglas A. Gwyn wrote:
> > Boyd Roberts wrote:
> > > In the last case you could loop on calling malloc until
> > > you got the whole thing.
> > Um, you really think that is a good design?
> yeah doug, whatcha gonna do when yer char buf[1024]; just ain't
> big enough, huh?  upgrade to 5.n BSD?

I didn't say anything about char buf[1024].

Russ suggests that the intended change to the interface would
result not just in an indication that the buffer was too small,
but rather in an exact measure of how much too small, so that
looping would not be required (unless perhaps the path was
changing underfoot?).

Of course, the right way in an ideal environment would be for
the service call to return (a handle to, or a capability for)
an object that is already constructed, so your program doesn't
have to help construct it by supplying a buffer etc., but that
isn't built into the Plan9 architecture.

Re: [9fans] Re: fd2path

[Boyd Roberts]

Douglas A. Gwyn wrote:
> 
> Russ suggests that the intended change to the interface would
> result not just in an indication that the buffer was too small,
> but rather in an exact measure of how much too small, so that
> looping would not be required (unless perhaps the path was
> changing underfoot?).
> 

look, when i said 'looping' it's once around, it falls out nicely.

a little bird told me that on inferno fd2path() returns a char *.

> Of course, the right way in an ideal environment would be for
> the service call to return (a handle to, or a capability for)
> an object that is already constructed, so your program doesn't
> have to help construct it by supplying a buffer etc., but that
> isn't built into the Plan9 architecture.

yeah 'persistant objects'.  ken calls them files.

-- 
    But I doubt if our present system [U.S. Army] will produce such
    an individual.  They are too: _abrasive_, opinionated, undiplomatic,
    nonconformist, and effective.
    
        -- Colonel David H. Hackworth (U.S. Army, Ret.)