From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 26 Apr 2015 04:29:09 GMT
Subject: Re: [PATCH v4 2/5] setup: sanity check file size in read_gitfile_gently
Message-ID: <xmqqfv7nzf56.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1429984780-22868-1-git-send-email-erik.elfstrom@gmail.com>

Erik Elfström <erik.elfstrom@gmail.com> writes:

> On Sat, Apr 25, 2015 at 6:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I do not think it is wrong per-se, but the changes in this patch
>> shows why hardcoded values assigned to error_code without #define is
>> not a good idea, as these values are now exposed to the callers of
>> the new function.  After we gain a new caller that does care about
>> the exact error code (e.g. to react differently to the reason why we
>> failed to read by giving different error messages) if we decide to
>> revert this step, or if we decide to add a new error type, for
>> whatever reason, this organization forces the caller to be updated.
>
> Yes, it was a bit silly of me not to add that. Would something like
> this be ok?

Yeah, if you used symbolic constants from the get-go, then the
second patch to add the "too-large? it cannot be gitfile" safety
would not have to renumber everything; instead it would be adding a
single constant to the header file and adding a new case to setup.c
that uses the error code.