Many thanks for your response! On 31 October 2015 at 22:19, Paul Smith <psm...@gnu.org> wrote:
> On Thu, 2015-10-29 at 19:02 +0000, Tim Murphy wrote: > > 1) The return value must be allocated by the function, after which > > make copies it into a buffer and deallocates it. [...] It seems as if > > it would be much better to expose GNU make's variable buffer interface > > and cut out the extra memory allocations > > I'm not sure I understand exactly what you have in mind, but you have to > be careful to avoid the "all the world's a POSIX ELF format" syndrome. > In some systems shared libraries cannot free memory allocated in other > dynamic objects. For example in Windows make shouldn't allocate memory > and leave a DLL responsible for freeing it (or vice versa). > > Given that restriction I'm fine with improving the interface. > Hmm, that is a point that I hadn't thought about. I like the interface for the built-in functions quite a lot. As an example: func_strip (char *o, char **argv, const char *funcname UNUSED) This is then written to by calls like so: o = variable_buffer_output (o, word_start, i); To me this seems almost the ideal interface. The implementation is hidden but it lets me cope with output that might be arbitrarily long. AFAICT this doesn't trip over the restriction any more than the current interface does. The only potential improvement would be if I could preallocate some empty space at then end a bit like VARIABLE_BUFFER_ZONE but something that one could specify as a parameter. This would make it possible to write directly into the buffer without any "redundant" use of memcpy. e.g. instead of snprintf()'ing a number into a 10 character buffer and then using variable_buffer_output() to copy that to the output, I would call out = variable_buffer_ensurefree(o, 10); nchars = snprintf(out,10,"%d", number); o = variable_buffer_advance(out, nchars); The point being that at memcpy() is never called by any of these functions. This sort of thing might seem a bit trivial but I would imagine that it has quite an effect on e.g. recursive calls of functions. i.e there are things which one would like to implement in make with "define" and "$(call)" but that end up being very slow when you present a long list of parameters or deep recursion is needed. Anyhow I can see that to get this to happen, I would have to supply some sort of patch and that will have to wait a little while. :-) > 2) There are some functions for seeking tokens in a string that should > > also be exposed - to help functions process lists. > > I agree, although there are too many existing interfaces in make today > that parse tokens. I've wanted to try to wrangle them into some > semblance of order before I try exporting them. > > The one I keep wanting is find_next_token (&text, &len). I don't know the alternatives yet but I thought I might mention that this one seems to be used in functions.c quite a lot and it would suit me. Cheers :-) Tim _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make
