Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 04/22/2014 09:07 AM, Matthieu Moy wrote: > > The whole point of the change is to *allow* strbuf to be used in > performance-critical stuff. OK. It should not make the current use of strbuf any harder anyway. >> In your proposal, would STRBUF_OWNS_MEMORY be a constant, or a flag that >> change when the internal buffer needs reallocation? My understanding is >> that it should change (if STRBUF_FIXED_MEMORY is not set), and the >> strbuf wrapping a preallocated buffer would become a "normal" strbuf >> when its internal buffer grows. > > Correct. STRBUF_OWNS_MEMORY itself is of course a constant like 0x02 Yes, I meant "the STRBUF_OWNS_MEMORY flag". > How does the size of this project compare to what you are looking for > for your Ensimag students? I do not yet have applications for this project (it should come within the next few days). It greatly depends on students and team size. I always start with a "warm up patch" (like GSoC's microprojects), and depending on the time taken for it, I direct students to bigger or smaller projects. Your proposal is a bit tricky (it requires a good understanding of C and memory management), but it is a purely local change (i.e. you can take strbuf.[cf] out of Git's source code and hack it as a ~500 LOC project, unit-test and document the result in a self-contained way), so it should be doable. Using the new API features here and there in Git's source code is another story though. I've added the proposal with a link to this discussion here: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Allow_finer_memory_management_in_the_strbuf_API -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html