On Wed, Oct 29, 2014 at 08:35:18PM -0700, Paul Eggert wrote: > Alan Modra wrote: > >It is no longer possible to shrink an obstack with obstack_blank (but > >you can still do that with obstack_blank_fast). > > Ouch, I hadn't noticed that. That's an incompatible change and I expect it > will break real-world usage for no particularly good reason, so we really > need to fix this. How about making the 2nd argument to obstack_blank and > obstack_blank_fast be of type ptrdiff_t rather than size_t?
We could, but.. I expect there is going to be other downstream code breakage anyway. Witness the patches needed to make gcc work with a more modern obstack.h, where a seemingly innocuous change like casting the obstack_base value to void* broke code doing pointer arithmetic, and gcc's use of the internal _obstack_begin function meant that gcc was exposed to the changed chunkfun type. Now if the 2nd arg of obstack_blank changes to type ptrdiff_t, then it becomes an odd case, all the other obstack "functions" taking a size_t. Also, I'd say obstack_blank is the wrong macro to use for shrinking, the most natural one being obstack_blank_fast due to it bypassing the obstack_room check. So there are my reasons for leaving obstack_blank as is. However, if you and others prefer to go with ptrdiff_t I'm happy enough to submit a patch. Oh, and while I'm advocating breakage, the doc for obstack_next_free says it returns a void* but actually returns a char*. Since it was deemed a good idea to similarly correct obstack_base, should we do the same for obstack_next_free? -- Alan Modra Australia Development Lab, IBM
