Am Donnerstag, den 28.01.2021, 09:07 -0800 schrieb JF Bastien:
> On Wed, Jan 27, 2021 at 11:21 PM Uecker, Martin via Liaison <
> liaison_at_[hidden]> wrote:
>
> >
> > Forwarding this to the liaison list, because I would
> > also love to hear opinions about this from the C++ side.
> >
> > Best,
> > Martin
> >
> > -------- Weitergeleitete Nachricht --------
> > Von: "Uecker, Martin" <Martin.Uecker_at_med.uni-goettingen.de>
> > An: sc22wg14_at_open-std.org <sc22wg14_at_open-std.org>
> > Betreff: (SC22WG14.18827) sudo buffer overlow
> > Datum: Wed, 27 Jan 2021 20:33:07 +0000
> >
> > >
> > > And again we have a major security issue due to some
> > > sting handling buffer overflow. Shouldn't we make the
> > > addition of a safe string library a priority for C23?
> > >
> > >
> > > And beyond strings, a general solution for safe
> > > programming with arrays are dependent types.
> > >
> > > https://en.wikipedia.org/wiki/Dependent_type
> > >
> > > We already have these! These are just our
> > > variably modified types. I know there is
> > > some sentiment against them, but I think
> > > it is not justified.
>
> It sounds like you want to standardize an active area of research.
>
> e.g. Checked C uses dependent types:
> https://www.microsoft.com/en-us/research/uploads/prod/2018/09/checkedc-secdev2018-preprint.pdf
>
> Incrementally is important for such approaches, say:
> http://www.cs.umd.edu/~mwh/papers/checkedc-incr.pdf
>
> I know of at least one non-public research-y datapoint which does
> interesting work beyond what Checked C does... but this isn't anything
> concrete that one can take to a standards committee. There's severe
> implications to actually deploying dependent types to existing codebases.
> Performance is a big concern, so is code size, memory usage, and (depending
> on the approach) there's some amount of valid C code which now becomes
> invalid... and IIUC WG14 isn't interested in any code-breaking proposals.
>
> So I don't see what this email is about. Yes dependent types are a thing,
> yes it would be nice for ~people~ to do ~stuff~ with them, particularly to
> solve security problems. But that's really too handwavy to discuss in a
> standards body.
>
> Maybe the intent is to nerd-snipe folks, but then I'd suggest going through
> the active research (as above) to more effectively nerd-snipe people.

I was talking about VLA and variably modified types, which
already exist in practice and can be used for bounds
checking and which *are* dependent types.

I pointed out that they are dependent types because I believe
that not everybody knows and understands this, and some
might think of VLAs as adhoc hack without good type theory.

Variably modified types have currently three problems
which are all fully in the scope of standards bodies:

1. They are optional which makes it impossible to add
safe interfaces using them.

2. They are incompletely specified and not fully
integrated into C as types (e.g. one can not store a
varibaly-modified type in a struct).

3. And finally there is the problem that C++ does not
have them.

Best,
Martin








>
> > Using variably modified types, compilers
> > > can already add run-time bounds checking!
> > >
> > > $ cat x.c
> > > int main()
> > > {
> > > int n = 3;
> > > int x[n];
> > > x[n] = 1;
> > > }
> > > $ gcc -fsanitize=undefined x.c
> > > $ ./a.out
> > > x.c:6:3: runtime error: index 3 out of bounds for type 'int [*]'
> > > $ clang -fsanitize=undefined x.c
> > > $ ./a.out
> > > x.c:6:2: runtime error: index 3 out of bounds for type 'int [n]'
> > >
> > >
> > >
> > > So why not make them mandatory?
> > >
> > > And then add the remaining functionality that is
> > > still missing, i.e. the possibility to store
> > > pointers to VLAs in structs and unions.
> > >
> > >
> > > Best,
> > > Martin
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_[hidden]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2021/01/0253.php
> >