RE: Smatch mailing list archives

> On Fri, May 07, 2021 at 02:22:37PM +0000, Reshetova, Elena wrote:
> > Hi,
> >
> > I have been working for a while now on a new smatch pattern, but
> > would really appreciate additional information points such as past
> > email discussions, etc.
> >
> > So I am wondering if there is a way to browse through
> > the archives of this mailing list in order to try to find the
> > information I need?
> 
> Sorry, I don't think it's archived anywhere.  There isn't a lot of
> traffic on the list.  About three times a year someone reports that
> Smatch is crashing for them.
> 
> I'm always happy to answer questions if there is any way I can help?

Thank you Dan! I am pretty new with smatch so that's why I was
hoping to browse through the existing mails to see if my simple questions
are already answered, but here is my current issue. 

What is the best way to create identifiers for the findings that certain smatch
pattern finds in the kernel? Let's say I have a new pattern that is able to find
different problematic places and report them in usual smatch way: errors and
warnings with file name, line number, function name, etc. 
Now for our pattern in order to be sure that the reported issue exists/does not
exists, somebody needs to go and look at the code manually and make a call. 
After this, it would be nice to mark this place as safe/concern in the report and be
able to transfer these results for kernel versions bumps (5.11->5.12, etc.) as soon as
the code in this function where finding was reported has not changed (and there
might be multiple findings per function).

What is the best way of doing it? 
I was first thinking of using some simple hash for the reported line (lines around, relative
position within the reported function),
but now I think I need also to hash the whole function in addition to the finding itself. 

Then the logic of transferring the result would be:

For each finding calculate: 
 1. finding_line_hash: the hash of the line that resulted in finding (becomes a unique id
     within the function).
2. finding_function_hash: the hash of the function that produced the finding (becomes a
   unique global id within the kernel) and helps to determine if the function has not been
   changed between the kernel versions. 

Logic for the result transfer: 

If both finding_line_hash and finding_function_hash match between the two smatch reports
for two different versions, then it is relatively safe to transfer this concrete smatch finding
and its manual audit result automatically.

Does it make sense overall? If yes, what is the easiest way in smatch to get hash data for 
1 and 2? I.e. get full reported line as a string and full function content as a string? 

Best Regards,
Elena.