linux-kernel - Re: [PATCH] perf stat: fix cvs output format

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Mar 2018 10:57:19 -0800
From:   Andi Kleen <ak@...ux.intel.com>
To:     Arnaldo Carvalho de Melo <acme@...hat.com>
Cc:     Cong Wang <xiyou.wangcong@...il.com>, linux-kernel@...r.kernel.org,
        Jiri Olsa <jolsa@...hat.com>, Ilya Pronin <ipronin@...tter.com>
Subject: Re: [PATCH] perf stat: fix cvs output format

> My understanding was that at some place there is a if/else
> 
> 	if (supported counters)
> 		fprintf_something with N fields, all filled in
>         else
> 		fprintf_empty_fields with != N fields
> 
> So I think this is not about using things like 'a,b,,,,,,' but about
> using different number of commas (fields) for supported/unsupported
> counters, no?

I believe it's only about empty fields at the end. I don't think
we ever get the columns wrong.

The original patch just moved the problem because there are still
cases where we can output different number of columns. 

If a tool looks only at the first row to allocate the number of columns 
it might error out if there are lines with more columns later. 

All outputs have to be padded to the maximum number of columns,
so removing columns is never the right fix.

-Andi