On 11/15/23 4:06 PM, Andrei Zissu wrote:
>
> 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.

I suggest you coordinate with René Ferdinand Rivera Morell regarding the
potential for a paper that targets the ecosystem IS. You've got a good
start on things that are worth considering and I think it makes sense to
specify these concerns along with associated recommended practices for
implementors to follow.

Tom.