Bug 32204
| Summary: | [PATCH] Remove code redundancy in usr.sbin/lpr/common_source/printcap.c | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | mikem <mike_makonnen> | ||||
| Component: | bin | Assignee: | Garance A Drosehn <gad> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Unspecified | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
mikem
2001-11-23 00:40:04 UTC
Responsible Changed From-To: freebsd-bugs->gad Garance. State Changed From-To: open->feedback At 8:48 PM -0800 11/27/01, <gad@FreeBSD.org> wrote: > State-Changed-From-To: open->feedback > State-Changed-By: gad > State-Changed-When: Tue Nov 27 20:43:56 PST 2001 Arg. I started to write something for this PR, went to check something, and somehow managed to change the status without including any reason. So, here's the reason. This patch would change firstprinter so it calls cgetnext without calling cgetfirst. I understand that cgetnext will act like cgetfirst the *first* time it is called, but I do not believe that all callers of 'firstprinter' can safely assume that the call to cgetfirst is not necessary. This is particularly likely in the calls from 'lpc', where we may loop thru all printers (or even "several printers") many times in a single lpc process. I might try this and see if I can come up with an explicit example where skipping the 'cgetfirst' does cause a problem. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosehn@rpi.edu State Changed From-To: feedback->closed While we may do something about this in the future, this specific patch is probably not a good idea. What is there does work OK, so improving it is a lower priority than some other things. |
