Re: [PATCH] commit: ensure correct permissions of the commit message

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Junio,
>
> On Mon, 4 Jan 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> >> I do not know fcreate_or_truncate() is a good name, though.
>> >
>> > So what would be a good name?
>> 
>> Have been thinking about it, but I did not come up with anything.  I
>> just know fcreate_or_truncate() is not a good name for multiple
>> reasons I already explained X-<.  sane_fopen_for_writing() perhaps?
>
> That implies that fopen() is insane, though ;-)

Well, sane_X() does not imply X() is "insane".  The reason why we
introduce sane_X() wrapper often is because X is inconvenient to use
sanely as-is.

Look at sane_istest(), sane_case(), etc.  We have one byte and want
to see if that is space, digit, etc., but we have to cast (possibly
signed) char to unsigned char and always doing so in the callers is
inconvenient.  Look at sane_grep.  We have a string and want to see
that appears in its input, but some implementations of "grep" can
be configured in an inconvenient/unsuitable way to be used in
scripts via environment variables, so we disable it not in the
callers but in a wrapper.

All we want to do here is to get a writable filehandle FILE * for a
path and store the contents we will generate without having to worry
about the possibility that the path is already there and we may have
to first unlink it to use fopen(3) to do so.

So in the sense, fopen(3) is inconvenient to use sanely as-is.  You
can call it insane, too ;-)

If we want to follow the X_or_Y() pattern, fopen_or_create() may
describe what it does better.  I do not have strong preference
either way, but again I am not good at naming things (and I suspect
you aren't either), so...