On Wed, Nov 15, 2023 at 21:09:53 +0200, Ville Voutilainen via SG15 wrote:
> I took a look, blanking source information provided by the builtins
> (that are also used by source_location in general)
> based on a command-line flag seems like a flick of the wrist to do. I
> can do that
> for the natural syntax implementation if people want to play with it.
>
> Blanking the source information provided by __FILE__, __LINE__ and
> __func__ takes more than a flick of the wrist,
> mostly because I'm not familiar with GCC's preprocessor
> implementation. I don't suppose there's anything insurmountable
> in it, tho.

Note that the compiler can inject source paths via other mechanisms
(e.g., debug info, though this is trivially stripped today with `strip`)
or via the linker (e.g., object names in static libraries tend to
correlate with their source filenames). The idea behind tooling's vote
(as I understand it) is to say something along the lines of "there exist
sources of de-anonymizing strings from various sources, so let's just
Solve The Problem™ and provide guidance" along the lines of:

1) detecting such information (including common sources or places it
   gets squirreled away)
  a) this includes deterministic derived IDs like `NT_GNU_BUILD_ID`
     where it would allow an adversary to see that some artifact is the
     same as another deployment
  b) embedded timestamps
  c) etc.
2) describing what tools can do to resolve this problem
  a) blanking strings and replacing line/column info with `0`
  b) ID replacement with an output of a lookup from ID to string so that
     reported errors can be more easily useful
  c) something else I haven't thought of

These things are certainly outside of the (language) standard and while
providing mechanisms for language-sourced bits of information like this
*can* be done, I don't think it is Solving The Problem™, but instead
more along the lines of addressing a symptom.

Of course, SG21 can do whatever it wants with source_location use in
contract violation handlers, but I got the sense that SG23 is also more
interested in Solving Problems™ than addressing every instance of a
problem throughout the standard (e.g., see discussion of P2951
addressing one pattern of aliasing causing trouble feeling like (to me
at least) using paper to plug a hole in a dam[1]).

--Ben

[1] And afterwards it occurred to me that we just need a scoped "pragma
poison" to do as well as the proposed shadowing.