On Wed, Nov 15, 2023 at 9:10 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Wed, 15 Nov 2023 at 16:28, Bret Brown via SG15 <sg15_at_[hidden]>
> wrote:
> >
> > Well, the "compiler vendor" in two major cases are open source projects.
> I don't believe anyone in particular has promised to make sure the quality
> of implementation lives up to our expectations in this specific case. That
> is a matter for faith and clear communication for most of us who are users
> of compilers but not contributors as such.
>
> There's certainly a vendor or two behind one of those projects that
> you can talk to via various channels.
>
> > But from a technical point of view, I haven't heard anyone say we should
> feel concerned about the difficulty in authoring quality implementations at
> some point.
>
> 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.
>

I think if we look at the big picture (as in beyond contracts only) we
would ideally want an opt out to effect strings which conform to *all *of
the following:

   1. May contain sensitive information - e.g. source_location in CCAs (and
   perhaps also in other uses, but that may run afoul of point 3 similarly to
   logs), comment field in CCAs, RTTI.
   2. Are not an intrinsic part of program logic - here for example we
   might have a problem with RTTI and exceptions, although in the case of
   exceptions the point 3 may also apply. Getting rid of something like RTTI
   strings automatically implies disabling the entire feature (as I've
   unfortunately experienced myself) but a better solution would be to find a
   way to implement RTTI without requiring those revealing strings, and that
   may also be worth standardizing.
   3. Are not something that the developer may actually intend to display -
   exception texts may indeed be required to be displayed, or perhaps may be
   opted out as we proposed for CCA strings, assuming that's only diagnostic
   information perhaps not needed in production code. Log messages would also
   likely not be included in such a mechanism, since it's doubtful they can be
   correctly identified, and also they more often than not are actually
   intended to be displayed (therefore other obfuscation mechanisms may be
   applied to them explicitly such as the various hashing options I recently
   mentioned).

So it's not straightforward, and may require multiple opt out flags to
allow the user proper control. But unless implementers say otherwise, I'm
guessing the most difficult part is indeed exploring the various use cases
and defining proper rules, rather than the actual implementation.