Re: RFC: obstack_mark() and obstack_release()

[Dimitrios Apostolou <jimis at gmx dot net>]

On Fri, 8 Jun 2012, Roland McGrath wrote:
> I'm quite dubious that the interface complexity of these new functions
> is the wise course.  It seems like quite an arcane solution.  Is the
> situation really so common that it wouldn't be better to do something
> far simpler like using a new obstack for the inner "temporary" uses?

Because the recursion depth is unknown I couldn't figure out a better 
solution. At first I was trying to obstack_alloc() a dummy int object, and 
obstack_free() it later, as I thought it goes without saying that the 
obstack would return to its earlier state. Later I realised that objects 
that were growing would be implicitly finalised (actually lost since the 
call to obstack_finish() was never performed) and new one would start 
growing.

Why is my solution arcane? Would it be better to alter the 
obstack_alloc/free() behaviour to actually restore previous state? I guess 
most (all?) existing uses wouldn't even notice the difference.

> At any rate, I think we need to clean up the maintenance situation
> with the obstack code before we consider any API changes whatsoever.
>
> Despite the comment at the top of the file, GCC people have made
> changes to obstack.[ch] without coordinating with libc.  The gnulib
> version has also diverged, though it is still vastly closer to the
> libc version than the GCC one is.
>
> We need to harmonize all three versions so there is again exactly one
> canonical source, residing in libc.  GCC and gnulib must regain the
> discipline of having all changes made in libc first and just taking
> updates of the verbatim source files (modulo license text).
>
> I realize it's rather far afield from your own work to deal with all
> that, and it's entirely understandable if you don't want to wade into
> the quagmire yourself.  But I don't know who is the best person to
> take that on.

I don't have commit access to the GCC tree. What I can do is cross-post at 
both projects a mail with a brief list of differences. From a quick look, 
GCC's obstack has provisions to build on systems with old libc's, for 
example using bcopy() instead of memcpy() or missing stddef.h. I don't 
think these changes can be backed out.


Thanks,
Dimitris