> 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.