On Tue, Jun 10, 2014 at 09:06:35AM -0700, Junio C Hamano wrote:
> > So any call to strbuf_detach on the result would be disastrous.
>
> You are right. Where did this original crap come from X-<...
I do not know if that face means you actually looked at the history, but
in case you did not...
I
Jeff King 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
> beginnin
On Mon, Jun 09, 2014 at 08:02:24PM -0400, Jeff King wrote:
> 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.
Ah, mystery solved. It's a gcc bug:
https://gcc.gnu.org/bugzilla/show_b
On Mon, Jun 09, 2014 at 03:40:57PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > diff --git a/notes-merge.c b/notes-merge.c
> > index 94a1a8a..7885ab2 100644
> > --- a/notes-merge.c
> > +++ b/notes-merge.c
> > @@ -671,7 +671,8 @@ int notes_merge_commit(struct notes_merge_options *o,
> >
Jeff King writes:
> diff --git a/notes-merge.c b/notes-merge.c
> index 94a1a8a..7885ab2 100644
> --- a/notes-merge.c
> +++ b/notes-merge.c
> @@ -671,7 +671,8 @@ int notes_merge_commit(struct notes_merge_options *o,
> DIR *dir;
> struct dirent *e;
> struct strbuf path = STRBUF_IN
Each of these sites assumes that commit->buffer is valid.
Since they would segfault if this was not the case, they are
likely to be correct in practice. However, we can
future-proof them by using get_commit_buffer.
And as a side effect, we abstract away the final bare uses
of commit->buffer.
Sign
6 matches
Mail list logo
