bug-gnulib
[Top][All Lists]
Advanced

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

Re: new module: relpath


From: Pádraig Brady
Subject: Re: new module: relpath
Date: Sun, 17 Jun 2012 15:26:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 06/17/2012 10:54 AM, Bruno Haible wrote:
> Hi Pádraig,
> 
>>>   concat-filename
>>>   filename
>>>   filenamecat
>>> It would be good to choose a module name in this spirit.
>>
>> I suppose relname would be most appropriate given that argument,
>> though I think in this case it's slightly better to keep the relpath name
>> so as to align with similar functions elsewhere like
>> os.path.relpath() and relpath(1)?
> 
> GNU != Python, and module names are not restricted to 8 characters in length.
> Why not call the module
>   relative-filename
> or
>   filename-relative (as Akim proposes, for native French speakers)?

Cool, filename-relative sounds good

> 
>>> I find it odd to have a function that produces either a string or
>>> some output (on a fixed stream, that is not even passed as argument).
>>> For a gnulib module it would be more appropriate to have only the string
>>> case. Users who need to output it to stdout can do that after invoking
>>> the function.
>>
>> Well there are 2 uses in coreutils at present.
>> ln wants the string returned, but the realpath command
>> just wants relpath() to output to stdout,
>> to avoid the malloc and data copy overhead.
>> If you wanted to make it a bit more general, I guess you
>> could pass in the stream rather than defaulting to stdout.
> 
> If you pass the stream as argument, the use that wants a stream needs to
> call open_memstream() or fmemopen(), which is not portable. Whereas if
> the function returns a malloc()ed string, it can be used portably in the
> other case.
> 
> Avoiding the "malloc and data overhead" sounds like an over-optimization
> here. malloc() is the normal way to allocate memory for a string. There
> are cases where you might want to avoid it. But here? Can you imagine an
> application where it is important to relativize thousands or millions of
> filenames in very short time? I can't.

OK fair enough.
Since there are lots of appending of strings here,
the approach taken in coreutils so far was
to append in a large buffer allocated up front,
or just to write to stdout.

I guess something in between is more appropriate for a lib.
I.E. efficiently append to a string on the heap.
This is a common operation, so maybe there are routines
in gnulib to use for this? I previously abstracted this operation in:
http://www.pixelbeat.org/libs/sbuf.h
http://www.pixelbeat.org/libs/sbuf.c

cheers,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]