Similar and from an example of usage,

Safer Range Access
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2955r1.html

How about 2 attributes?
[[safe]]
[[unsafe(reason=["range", "dangling_reference", "reference_invalidation"], alternatives=["function signature", "function signature"])]]

The problem with the NO arguments of linters and static analysis apart from the language is that there are NO standard separate linters and static analyzer tools.

So what is being asked for is for the standard to standardize attributes that could be used by non standard tools.

2nd: For the standard to consider adding separate or [later] built into compiler these tools. There is a tools study group.

The purpose of this is for auditing, documentation and specification purposes.

A tool, if provided, wherever provided, would output a report in a standard easily parsable format such as JSON providing information such as the following:
1) #lines of code before include
2) #lines of code after include
3) how many functions unattributed
4) number of safe calls
5) number of unsafe calls per reason

In short:

This proposal is 0 overhead and doesn't break backwards compatibility because no assembly is generated.
The first phase could be quickly done because how long does it take to standardize 2 documentation attributes.

...
...
...

Other attributes could also be standardized for auditing, documentation and specification purposes at little cost to the current standardization effort. Using the information could come later.

Reference checking
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2878r5.html





On Sun, Nov 5, 2023 at 8:48 AM Yexuan Xiao via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
It is possible to vote on whether to mark a feature as discouraged. C++ didn't invent nullptr to coexist with NULL. If users continue to use old algorithms instead of constrained algorithms year after year, why is the standards committee working on this? linter is also part of the c++ ecosystem, and the committee should respond. C++ has long been plagued by security problems, print is a safe alternative to printf, and continuing to use printf is hastening the death of C++.


From: Jonathan Wakely <cxx@kayari.org>
Sent: Sunday, November 5, 2023 21:05
To: C++ Proposals <std-proposals@lists.isocpp.org>
Cc: Yexuan Xiao <bizwen@nykz.org>
Subject: Re: [std-proposals] Keeping C++ Young: Migrating to Modern C++
 


On Sun, 5 Nov 2023, 12:56 Yexuan Xiao via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
Facilities like printf were meaningless after prinf was added to the standard, but since printf is widely used, deprecateing them is harmful to C++. new is vital to C++, we need its placement version, and deprecateing it harms C++'s ability. NULL, rand, qsort  that should not continue to be used, but they should not be removed either.


Again, this is something better handled by a linter or code analysis tool.

My project might want to replace all uses of rand() but keep using printf. With a third party tool I can select which suggestions to enable/disable for a given project.


--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals