On Wed, Nov 15, 2023 at 9:10 PM Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

On Wed, 15 Nov 2023 at 16:28, Bret Brown via SG15 <sg15@lists.isocpp.org> 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:

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