[debbugs-tracker] bug#22816: closed (cmp --verbose EOF message could be more verbose)

[GNU bug Tracking System]

Your message dated Thu, 4 May 2017 10:28:51 -0700
with message-id <address@hidden>
and subject line Re: cmp --verbose EOF message could be more verbose
has caused the debbugs.gnu.org bug report #22816,
regarding cmp --verbose EOF message could be more verbose
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
22816: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22816
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> cmp --verbose EOF message could be more verbose
>
>
>
>
> Date: 
>
> Fri, 26 Feb 2016 17:53:07 +0800
>
>
>
>
> One would think the "cmp: EOF on SHORTER-FILE" message
> should at least say what line number if --verbose or --print-bytes is given.
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: cmp --verbose EOF message could be more verbose
>
>
>
>
> Date: 
>
> Thu, 4 May 2017 10:28:51 -0700
>
>
>
>
> tags 22816 + wontfix
> done
>
> Re https://debbugs.gnu.org/22816, I realized that printing any line
> number upon EOF would necessitate counting them from the start, and I
> would rather not do that.
>
> If you encounter EOF in this case and want to know how many newlines
> were in one of those inputs, you can run "wc -l" on that input.
>
> Making cmp perform that task does not seem worthwhile, because one
> would have to choose between always counting newlines (like wc -l
> does), and thus incurring this added cost all the time, or accepting a
> partial (and racy) solution of rereading the regular file upon EOF. I
> say "partial" because if the input is not seekable, that is not even
> possible. And "racy" because once rewound and reread, we may then be
> processing different content.
>
> So I'm closing this as WONTFIX.
>
>
> --- End Message ---