LCDproc development and user support list

Text archives Help


[Lcdproc] Bug with numeric priorities


Chronological Thread 
  • From: amb at gedanken.demon.co.uk (Andrew M. Bishop)
  • Subject: [Lcdproc] Bug with numeric priorities
  • Date: Sun, 07 Sep 2008 10:11:14 +0100

[Resent after subscribing to the lcdproc list, an older duplicate
message is still waiting for moderator approval]

I have been using LCDproc for a while on Debian (version 0.4.5) and
have just tried updating to version 0.5.2. What I have found during
this changeover is a bug in LCDd that means that the numeric
priorities have never worked since the named priorities were added.

If a numeric priority of 128 is used (for example) then only one
screen will display, they don't rotate like they should (since 128 is
the same as 'info').

Based on the CVS files on SourceForge
http://lcdproc.cvs.sourceforge.net/lcdproc/lcdproc/server/commands/screen_commands.c?view=log
I can see that from revision 1.4 in Feb 2003 that the new code was
added, but it contains a logical error.

This is the code in question:

196 /* Handle the "priority" parameter*/
197 else if (strcmp (p, "priority") == 0) {
198 if (argc > i + 1) {
199 i++;
200 debug (RPT_DEBUG, "screen_set:
priority=\"%s\"", argv[i]);
201
202 /* first try to interpret it as a number */
203 number = atoi (argv[i]);
204 if (number > 0) {
205 if (number <= 64) {
206 s->priority = PRI_FOREGROUND;
207 } else if (number < 192) {
208 s->priority = PRI_INFO;
209 } else {
210 s->priority = PRI_BACKGROUND;
211 }
212 } else {
213 /* Try if it is a priority class */
214 number = screen_pri_name_to_pri
(argv[i]);
215 }
216 if (number >= 0) {
217 s->priority = number;
218 sock_send_string(c->sock,
"success\n");
219 } else {
220 sock_send_string(c->sock, "huh?
invalid argument at -priority\n");
221 }
222 } else {
223 sock_send_string (c->sock, "huh? -priority
requires a parameter\n");
224 }
225 }


If the priority value given is numeric then the variable 'number' will
be given its value on line 203. Line 204 will detect this and the
code from lines 205-211 will correctly decode 'number' into a priority
class and set the priority of the screen. If it is not numeric then
line 214 will convert the string to a priority class and store it in
the variable 'number'. Line 216 detects if a valid priority has been
given and sets the priority of the screen.

The problem is that the numeric value on line 203 in the variable
'number' is unchanged by the code in lines 205-211. In lines 216, 217
the screen priority is set to the original numeric value and not the
priority class. The code in lines 205 to 211 is useless code, the
priority set here is overwritten on line 217.

The change is simple though; on lines 206, 208, 210 's->priority'
should be replaced by 'number'.

The bug can be verified with unmodified code by using priority 2 which
maps to PRI_INFO and the screens rotate. Using priority 128 which
should map to PRI_INFO and only one screen is shown, they don't
rotate.

--
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop amb at gedanken.demon.co.uk
http://www.gedanken.demon.co.uk/




Archive powered by MHonArc 2.6.18.

Top of page