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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> Hi Junio,
>
> On Mon, 4 Jan 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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...


--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]