As you and I have discussed before, in my opinion C is long overdue
gaining language built-ins for array views, UTF-8 string views, arrays
which are not VLAs, and built-in UTF-8 string objects.

However it's an awful lot of work. And only newly written or rewritten
code would benefit.

Niall

On 28/01/2021 07:20, Uecker, Martin via Liaison 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_[hidden]>
> An: sc22wg14_at_[hidden] <sc22wg14_at_[hidden]>
> 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.
>>
>> 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
>