Michael Haggerty <mhag...@alum.mit.edu> 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
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:
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html