From 7d827b5cca185b411be3ac9b71834958f4737bdf Mon Sep 17 00:00:00 2001 From: Zach Scott Date: Thu, 19 Sep 2019 17:08:36 +0000 Subject: auxstats: replace /proc ACPI calls with /sys ones (#245) According to , use of `/proc/acpi` to get battery usage is deprecated. This commit replaces the two files from this API with the single file `/sys/class/power_supply/BAT0/capacity`, simultaneously removing the need to calculate battery percentage. --- src/cmd/auxstats/Linux.c | 30 ++++++++---------------------- 1 file changed, 8 insertions(+), 22 deletions(-) (limited to 'src') diff --git a/src/cmd/auxstats/Linux.c b/src/cmd/auxstats/Linux.c index 09ca18f3..64c86a26 100644 --- a/src/cmd/auxstats/Linux.c +++ b/src/cmd/auxstats/Linux.c @@ -26,36 +26,22 @@ void (*statfn[])(int) = void xapm(int first) { - static int fd = -1, fdb = -1; - int i, last = -1, curr = -1; + static int fd = -1; + int curr = -1; if(first){ - fd = open("/proc/acpi/battery/BAT0/info", OREAD); - fdb = open("/proc/acpi/battery/BAT0/state", OREAD); + fd = open("/sys/class/power_supply/BAT0/capacity", OREAD); return; } - if(fd == -1 || fdb == -1) + if(fd == -1) return; readfile(fd); - for(i=0; i Date: Thu, 19 Sep 2019 13:08:54 -0400 Subject: plumber: fix EOF detection on writes to rules file (#257) Instead of checking Fcall.data==nil, check Fcall.count==0. The former check always fails after `gcc -O2` optimizations (gcc version 8.3.0). Also fix an out-of-bound read detected by valgrind: ``` ==31162== Invalid read of size 1 ==31162== at 0x11005E: morerules (rules.c:739) ==31162== by 0x110254: writerules (rules.c:775) ==31162== by 0x10D2FE: fsyswrite (fsys.c:848) ==31162== by 0x10C304: fsysproc (fsys.c:248) ==31162== by 0x112E8C: threadstart (thread.c:96) ==31162== by 0x4A682BF: ??? (in /usr/lib/libc-2.29.so) ==31162== Address 0x4ea984a is 0 bytes after a block of size 250 alloc'd ==31162== at 0x483AD7B: realloc (vg_replace_malloc.c:826) ==31162== by 0x1196F3: p9realloc (malloc.c:53) ==31162== by 0x10BDFD: erealloc (plumber.c:124) ==31162== by 0x10FCD9: concat (rules.c:642) ==31162== by 0x10FCD9: concat (rules.c:635) ==31162== by 0x110230: writerules (rules.c:773) ==31162== by 0x10D2FE: fsyswrite (fsys.c:848) ==31162== by 0x10C304: fsysproc (fsys.c:248) ==31162== by 0x112E8C: threadstart (thread.c:96) ==31162== by 0x4A682BF: ??? (in /usr/lib/libc-2.29.so) ``` Fixes #256 --- src/cmd/plumb/rules.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'src') diff --git a/src/cmd/plumb/rules.c b/src/cmd/plumb/rules.c index 4da4bb23..6e9b2c63 100644 --- a/src/cmd/plumb/rules.c +++ b/src/cmd/plumb/rules.c @@ -736,8 +736,8 @@ morerules(uchar *text, int done) */ endofrule = nil; for(s=text; *s!='\0'; s++) - if(*s=='\n' && *++s=='\n') - endofrule = s+1; + if(*s=='\n' && *(s+1)=='\n') + endofrule = s+2; if(endofrule == nil) return text; input->end = endofrule; @@ -772,7 +772,7 @@ writerules(char *s, int n) tmp = stringof(s, n); text = (uchar*)concat((char*)text, tmp); free(tmp); - text = morerules(text, s==nil); + text = morerules(text, n==0); } if(s == nil){ free(text); -- cgit v1.2.3 From 9389de63d7b0dab99773511f48b2d303e3f957d7 Mon Sep 17 00:00:00 2001 From: telephil Date: Thu, 19 Sep 2019 19:10:09 +0200 Subject: upas/nfs: fix null date when message is sent to plumber (#263) When fetching, messages are sent to plumber as soon as the ENVELOPE part is read. The date field of the message is sent when the INTERNALDATE part is read and there is no guarantee that this will be read before the ENVELOPE. This bug can be observed when using faces(1) which will retrieve messages with a null date and then always display a 'Jan 1' date instead of the correct one. The fix is to simply send the message to plumber after having read all parts, thus ensuring the message is complete. --- src/cmd/upas/nfs/imap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src') diff --git a/src/cmd/upas/nfs/imap.c b/src/cmd/upas/nfs/imap.c index 8d43fe79..ef76487b 100644 --- a/src/cmd/upas/nfs/imap.c +++ b/src/cmd/upas/nfs/imap.c @@ -1468,6 +1468,7 @@ haveuid: if(isatom(sx->sx[i], msgtab[j].name)) msgtab[j].fn(msg, sx->sx[i], sx->sx[i+1]); } + msgplumb(msg, 0); } static void @@ -1549,7 +1550,6 @@ xmsgenvelope(Msg *msg, Sx *k, Sx *v) USED(k); hdrfree(msg->part[0]->hdr); msg->part[0]->hdr = parseenvelope(v); - msgplumb(msg, 0); } static struct { -- cgit v1.2.3 From f1dd3f065a97f57bf59db2e3284868e181734159 Mon Sep 17 00:00:00 2001 From: deepcube Date: Thu, 19 Sep 2019 10:10:28 -0700 Subject: hoc: don't nest calls to follow() when lexing ++/+= and --/-= (#287) The code had a nested use of the follow() function that could cause +=+ and -=- to register as ++ and --. The first follow() to execute could consume a character and match and then the second follow() could consume another character and match. For example i-=-10 would result in a syntax error and i-=- would decrement i. --- src/cmd/hoc/hoc.y | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src') diff --git a/src/cmd/hoc/hoc.y b/src/cmd/hoc/hoc.y index 9c5a02f1..f634e82d 100644 --- a/src/cmd/hoc/hoc.y +++ b/src/cmd/hoc/hoc.y @@ -215,8 +215,8 @@ yylex(void) /* hoc6 */ return STRING; } switch (c) { - case '+': return follow('+', INC, follow('=', ADDEQ, '+')); - case '-': return follow('-', DEC, follow('=', SUBEQ, '-')); + case '+': return follow('+', INC, '+') == INC ? INC : follow('=', ADDEQ, '+'); + case '-': return follow('-', DEC, '-') == DEC ? DEC : follow('=', SUBEQ, '-'); case '*': return follow('=', MULEQ, '*'); case '/': return follow('=', DIVEQ, '/'); case '%': return follow('=', MODEQ, '%'); -- cgit v1.2.3