Subject: Re: [PATCH v4 2/5] setup: sanity check file size in read_gitfile_gently

From: Junio C Hamano <[email-masked]>
Date: Sat, 25 Apr 2015 21:29:09 -0700

Erik Elfström <[email-masked]> writes:

> On Sat, Apr 25, 2015 at 6:47 PM, Junio C Hamano <[email-masked]> 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.