These functions could benefit from the added compile-time
safety of having the compiler check printf arguments.
Unfortunately, we also sometimes pass an empty format string,
which will cause false positives with -Wformat-zero-length.
In this case, that warning is wrong because our function is
not
Jeff King writes:
> These functions could benefit from the added compile-time
> safety of having the compiler check printf arguments.
>
> Unfortunately, we also sometimes pass an empty format string,
> which will cause false positives with -Wformat-zero-length.
> In this case, that warning is wro
On Tue, Jul 09, 2013 at 10:26:04PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > These functions could benefit from the added compile-time
> > safety of having the compiler check printf arguments.
> >
> > Unfortunately, we also sometimes pass an empty format string,
> > which will cause
Jeff King writes:
> On Tue, Jul 09, 2013 at 10:26:04PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > These functions could benefit from the added compile-time
>> > safety of having the compiler check printf arguments.
>> >
>> > Unfortunately, we also sometimes pass an empty format
On Tue, Jul 09, 2013 at 10:35:25PM -0700, Junio C Hamano wrote:
> > You can "fix" it with -Wno-zero-format-length, so the hassle is not
> > huge.
>
> Yes, or just do func(..., "%s", "") perhaps? That also sound iffy.
I imagine that is the method intended by upstream (though who
knows...the who
Jeff King writes:
> On Tue, Jul 09, 2013 at 10:35:25PM -0700, Junio C Hamano wrote:
>
>> > You can "fix" it with -Wno-zero-format-length, so the hassle is not
>> > huge.
>>
>> Yes, or just do func(..., "%s", "") perhaps? That also sound iffy.
>
> I imagine that is the method intended by upstre
On Tue, Jul 09, 2013 at 10:52:55PM -0700, Junio C Hamano wrote:
> > The patch to do it is below, but I actually think an explicit blank-line
> > function like:
> >
> > status_print_empty_line(s, color);
> >
> > would be more obvious to a reader.
>
> I noticed that all but one can be dealt with
Jeff King writes:
> If you want to keep refactoring this, I don't mind, but I kind of feel
> like we are going down a rabbit hole for very little gain.
Right, and right. The rewrite to move _ln to "\n" was wrong, and
this is too much hassle for too little gain. If we were to do
something, I ag
Jeff King writes:
> On Tue, Jul 09, 2013 at 10:26:04PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>> ...
>> > I'm torn on this one. It really does provide us with more compile-time
>> > safety checks, but it's annoying that "-Wall -Werror" will no longer
>> > work out of the box.
>>
>>
On Fri, Jul 12, 2013 at 09:10:30AM -0700, Junio C Hamano wrote:
> > You can "fix" it with -Wno-zero-format-length, so the hassle is not
> > huge. But I am also inclined to just drop this one. We have lived
> > without the extra safety for a long time, and list review does tend to
> > catch such pr
10 matches
Mail list logo
