Any update on getting this committed? Might this make it in for 15-release?

And just as a historical note, this *used* to be very helpful, because we'd have students working on some c-based homework assignment, and they'd cd into the directory holding all the source code and then type lpr * to print the source code .... and the executables produced by that source code.

The basic goal of refusing to print files which will be a problem on the printer is still a valuable one, but this specific and ancient check is serving no purpose. It's fine with me to remove it.

I've already done detailed testing of this, both before and after applying the update. The problem reported did definitely exist before this change, and it's definitely fixed after applying this update. I only tested it on amd64, but it'd be pretty bizarre if this worked on amd64 and didn't work on some other HW.

The problem is fixed by this revision was already fixed back in Jul 28 16:02:30 2016.

Let's see if I can finally figure out how to close this review-request (after almost 3 years...)

Well, I created a new review-entry, D33687

In D33666#761239, @imp wrote:

Isn't there a routine to normalize the tm so that all the edge cases are neatly taken care of?

Hmm. Looks like that wasn't quite right. Let me try another tactic.

And after checking, it is true that the value for tm_year must also be fixed. Also, it's the default entry for /var/log/weekly.log where this issue comes up, not /var/log/weekly.conf . Now let's see if I can remember how to upload a new patch file to review {F34421954}for this. This is a patch based on branch 13-stable, which I assume will work fine for freebsd-current.

In an amazing coincidence, on Nov 30th I fixed a bug in a program of my own (totally unrelated to this) which had a similar bug. But in that case the bug happened only when the program was run during the last hour of a month. That program was eight years old, and it wasn't until Nov 30th 2021 that the bug stung me.

This looks fine to me. Let me know if there's anything else I need to do for it.

In D16518#353086, @markj wrote:

In D16518#352929, @gad wrote:

[...] I'll submit this anyway, if only to prove that I do read my email. 🙂

Does this qualify for a "Reviewed by: gad" in the commit message?

I haven't looked at newsyslog in awhile, but I'm happy to see someone attempting this cleanup.

So, I'm finally getting around to looking at this. The delay was that I didn't have a freebsd-12.current system running. And now that I have a current system to test changes on, it looks like this issue was solved back in revision 303449 by ed, Thu Jul 28 16:02:30 2016 UTC. See revision 303449

(sorry for the late noise. For some odd reason, today is the first day I've been able to connect to this page, although I've tried since last Thursday. I suspect there was a problem in the browser on my machine).

In D9637#283208, @emaste wrote:

Ping @gad

This was handled by the commit which was referenced earlier.

Accepting this, so I can later close it.

Many years ago I did some work on newsyslog. I could handle the review and commit of this update if that's okay with other reviewers.

I'm in the path of the big snowstorm which is supposed to hit tomorrow, so I might not respond to this for a few days. But once we've recovered from that, I'd be willing to commit my other patch for this along with the fix to skimprintcap.c. If nothing else, it shows that I'm still alive and paying (some) attention to lpr & friends.

Hmm. Odd that it didn't build. It did compile on my system, although I didn't do much more than compile it.

Well, I tried to upload my diff as an "update", and that showed up as D9982 .

Hmm. I guess that wasn't the best way to upload an example diff...

[ thanks for contacting me ]