Jeff King <peff@xxxxxxxx> writes: > I agree it's not right, though. I think the original is questionable, > too. It takes a pointer into the middle of partial_commit->buffer and > attaches it to a strbuf. That's wrong because: > > 1. It's pointing into the middle of an allocated buffer, not the > beginning. > > 2. We do not own partial_commit->buffer in the first place. > > So any call to strbuf_detach on the result would be disastrous. You are right. Where did this original crap come from X-<... > ... and it > doesn't cause a bug in practice because the only use of the strbuf is to > pass it as a const to create_notes_commit. > > I feel like the most elegant solution is for create_notes_commit to take > a buf/len pair rather than a strbuf, but it unfortunately is just > feeding that to commit_tree. Adjusting that code path would affect quite > a few other spots. > > The other obvious option is actually populating the strbuf, but it feels > ugly to have to make a copy just to satisfy the function interface. > > Maybe a cast and a warning comment are the least evil thing, as below? I > dunno, it feels pretty wrong. Yeah, it does feel wrong wrong wrong. Perhaps this big comment would serve as a marker for a low-hanging fruit for somebody else to fix it, e.g. by using strbuf-add to make a copy, which would be the easiest and safest workaround? > diff --git a/notes-merge.c b/notes-merge.c > index 94a1a8a..1f3b309 100644 > --- a/notes-merge.c > +++ b/notes-merge.c > @@ -671,7 +671,7 @@ int notes_merge_commit(struct notes_merge_options *o, > DIR *dir; > struct dirent *e; > struct strbuf path = STRBUF_INIT; > - char *msg = strstr(partial_commit->buffer, "\n\n"); > + const char *msg = strstr(partial_commit->buffer, "\n\n"); > struct strbuf sb_msg = STRBUF_INIT; > int baselen; > > @@ -719,7 +719,15 @@ int notes_merge_commit(struct notes_merge_options *o, > strbuf_setlen(&path, baselen); > } > > - strbuf_attach(&sb_msg, msg, strlen(msg), strlen(msg) + 1); > + /* > + * This is a bit tricky. We should not be attaching msg, which > + * is not owned by us and is not even the start of a heap buffer, to a > + * strbuf. But the create_notes_commit interface really wants > + * a strbuf, even though it will only ever use it as a buf/len pair and > + * never modify it. So this is tentatively safe as long as nobody ever > + * modifies, detaches, or releases the strbuf. > + */ > + strbuf_attach(&sb_msg, (char *)msg, strlen(msg), strlen(msg) + 1); > create_notes_commit(partial_tree, partial_commit->parents, &sb_msg, > result_sha1); > if (o->verbosity >= 4) > > I'm still confused and disturbed that my gcc is not noticing this > obvious const violation. Hmm, shutting off ccache seems to make it work. > Doubly disturbing. > > -Peff -- 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