Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Bartosz Gołaszewski
2014-07-28 18:48 GMT+02:00 Timo Teras : > > I was taking sizeof of individual element: meminfo[0]. Alternative > would be sizeof *meminfo. I prefer not to expand to the actual type. > It's easier to change if needed, and the correctness more obvious as > you don't need to look what was type of memi

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Timo Teras
On Mon, 28 Jul 2014 17:52:41 +0200 Bartosz Gołaszewski wrote: > 2014-07-28 17:25 GMT+02:00 Timo Teras : > > So something like: > > > > diff --git a/procps/top.c b/procps/top.c > > index 62f9421..119c32b 100644 > > --- a/procps/top.c > > +++ b/procps/top.c > > @@ -536,7 +536,7 @@ static void parse

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Bartosz Gołaszewski
2014-07-28 17:25 GMT+02:00 Timo Teras : > So something like: > > diff --git a/procps/top.c b/procps/top.c > index 62f9421..119c32b 100644 > --- a/procps/top.c > +++ b/procps/top.c > @@ -536,7 +536,7 @@ static void parse_meminfo(unsigned long meminfo[MI_MAX]) > FILE *f; > int i; > >

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Timo Teras
On Mon, 28 Jul 2014 16:27:37 +0200 Ralf Friedl wrote: > Timo Teras wrote: > > On Sun, 27 Jul 2014 21:50:28 +0200 > > Denys Vlasenko wrote: > >> Applied, thanks! > > Thanks, though I noticed now a weirdness that did not happen before. > > > > +static void parse_meminfo(unsigned long meminfo[MI_MA

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Ralf Friedl
Timo Teras wrote: On Sun, 27 Jul 2014 21:50:28 +0200 Denys Vlasenko wrote: Applied, thanks! Thanks, though I noticed now a weirdness that did not happen before. +static void parse_meminfo(unsigned long meminfo[MI_MAX]) +{ ... + memset(meminfo, 0, sizeof(meminfo)); Seems to not work. Th

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Timo Teras
On Sun, 27 Jul 2014 21:50:28 +0200 Denys Vlasenko wrote: > On Mon, Jul 21, 2014 at 1:14 PM, Timo Teräs wrote: > > display_header() code to parse meminfo as is was buggy: > > - uninitialized variables were used if meminfo was not as expected > > - meminfo parsing failed on new kernels (3.14+) as

Re: [PATCH 1/3] tail: turn i to unsigned integer

2014-07-28 Thread Guilherme Maciel Ferreira
Hi, 2014-07-26 15:02 GMT-03:00 walter harms : > what is the advantage ? I think correctness is a good advantage. I mean, why use a signed integer, if this variable works as (and with) unsigned integers only? > > re, > wh > > Am 26.07.2014 19:37, schrieb Guilherme Maciel Ferreira: >> The variabl

Re: [PATCH 2/3] seq: match f's type with strlen() result type

2014-07-28 Thread Guilherme Maciel Ferreira
Hi, 2014-07-26 15:05 GMT-03:00 walter harms : > actually strlen() returns size_t. When you really need this to be "correct" > you should use size_t. I know. I simply didn't see anywhere nearby using size_t, then I assumed unsigned was used instead. But, I'd rather use size_t! > Did you get an er

Re: [PATCH 1/2] find: use sysconf(_SC_ARG_MAX) to determine the command-line size limit

2014-07-28 Thread Bartosz Gołaszewski
2014-07-03 14:27 GMT+02:00 Bartosz Gołaszewski : > Hi Denys, > > have you read my message from June 10th in this thread? Could you > review the patches I attached back then? Busybox still uses ARG_MAX as > default, which is smaller than sysconf(_SC_ARG_MAX) on every system I > checked. In fact comm

Re: Fwd: [PATCH] iproute: support onelink route option and print route flags

2014-07-28 Thread Michael Tokarev
28.07.2014 10:46, Baruch Siach wrote: [] > I received your original post today. It's also on the gmane.org archive at > http://article.gmane.org/gmane.linux.busybox/39641. Oh. I think I know what's going on. The mailing list does not send email to the author if he's already listed in a Cc list.