Earlier I pointed out that upstream commit [53cac1d08bba395942df638d74526470c9fc7975] Fix parentheses in cupsdCleanJobs
isn't in buster. I've now given some more thought to the implications of this. In the typical case (default settings) job->history_time is INT_MAX. The misplaced parenthesis makes the code behave as if (1 < JobHistoryUpdate || !JobHistoryUpdate) JobHistoryUpdate = job->history_time; which means JobHistoryUpdate will nearly always be updated. It will therefore most likely (until 2038, anyway) end up with the file_time value of the last job in the array. I haven't checked how the jobs array is sorted; I think the code should avoid relying on a particular ordering. The correct result is of course the earliest file_time value of all jobs in the array, so the misplaced parenthesis could result in cleanup being unduly delayed. By the way, the way in which history_time and file_time are calculated in cupsdLoadJob() and cupsdUpdateJobs() could result in wraparound on platforms with signed 32-bit time_t. For plausible values of PreserveJobHistory and PreserveJobFiles this isn't going to bite until 2038 or maybe late 2037, but what if one now were to test with "1000w" on a 32-bit platform?
