Date: Wed, 13 Aug 2025 18:11:49 -0400
On 8/11/25 5:35 PM, Jens Maurer via Liaison wrote:
> But time has passed since then, so maybe people would be
> more happy to embrace the function parameter aspect of VLAs
> nowadays. However, it seems a lot of existing functions
> take the length after the pointer, so we have a name lookup
> issue:
>
> char* strncpy(char *dst, const char *src, size_t n);
>
> How would I write this in the new world? Should we rather
> strive for the attribute annotation syntax that is being
> discussed in a parallel thread?
My preference is to use a contracts-like syntax to express this:
char* strncpy(char *dst, const char *src, size_t n)
_Array_bound(dst, n)
_Array_bound(src, strnlen(src, n));
(that might need a tweak since strnlen() doesn't include the null
terminating character if present and strncpy() should be allowed to
access it).
Tom.
>
> Jens
>
>
>
> On 11.08.25 22:43, Martin Uecker via Liaison wrote:
>> Hi all,
>>
>> one of the main annoyances when maintaining C99 or later headers
>> that are also consumed by C++ is that C++ does not support
>> VLA notation for parameter and more generally variably modified types.
>>
>> int foo(int n, char buf[n]);
>> int bar(int a, int b, double (*matrix)[a][b]);
>>
>> In C is partially integrated into BDOS, UBSan and warnings
>> (with varying level of completeness on different compilers),
>> so 'foo' does help find bound errors and 'bar' is also useful
>> for numerical code.
>>
>>
>> Unfortunately, C++ rejects this, so a partial workaround for
>> 'foo' is to hide this behind a macro that expands to nothing
>> in C++.
>>
>> int foo(int n, char buf[_NOCPP(n)]);
>>
>> 'foo' can then be used from C++ (but bounds information and
>> related warnings you would get in C are lost).
>>
>>
>> This works only at the topmost array but not for
>>
>> int bar(int a, int b, double (*matrix)[a][b]);
>>
>> which C++ AFAIK can only express using mdspan.
>>
>>
>> I wonder whether the situation can be improved. At least for 'foo'
>> it would already be a step forward if C++ could simply ignore the
>> size expression in function declarations, maybe only for extern
>> "C".
>>
>> For 'bar' it seems more difficult, but being able to parse these
>> declaration without error would also help a lot. But it would
>> also seem simply enough to allow calling of such function with fixed
>> arrays, i.e. supporting
>>
>> extern "C" int bar(int a, int b, double (*matrix)[a][b]);
>>
>> void g()
>> {
>> double matrix[10][10];
>> bar(10, 10, &matrix);
>> }
>>
>> would only require a very superficial support for this C feature
>> and no type system changes.
>>
>>
>> What do you think?
>>
>>
>> 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/2025/08/1565.php
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post:http://lists.isocpp.org/liaison/2025/08/1566.php
> But time has passed since then, so maybe people would be
> more happy to embrace the function parameter aspect of VLAs
> nowadays. However, it seems a lot of existing functions
> take the length after the pointer, so we have a name lookup
> issue:
>
> char* strncpy(char *dst, const char *src, size_t n);
>
> How would I write this in the new world? Should we rather
> strive for the attribute annotation syntax that is being
> discussed in a parallel thread?
My preference is to use a contracts-like syntax to express this:
char* strncpy(char *dst, const char *src, size_t n)
_Array_bound(dst, n)
_Array_bound(src, strnlen(src, n));
(that might need a tweak since strnlen() doesn't include the null
terminating character if present and strncpy() should be allowed to
access it).
Tom.
>
> Jens
>
>
>
> On 11.08.25 22:43, Martin Uecker via Liaison wrote:
>> Hi all,
>>
>> one of the main annoyances when maintaining C99 or later headers
>> that are also consumed by C++ is that C++ does not support
>> VLA notation for parameter and more generally variably modified types.
>>
>> int foo(int n, char buf[n]);
>> int bar(int a, int b, double (*matrix)[a][b]);
>>
>> In C is partially integrated into BDOS, UBSan and warnings
>> (with varying level of completeness on different compilers),
>> so 'foo' does help find bound errors and 'bar' is also useful
>> for numerical code.
>>
>>
>> Unfortunately, C++ rejects this, so a partial workaround for
>> 'foo' is to hide this behind a macro that expands to nothing
>> in C++.
>>
>> int foo(int n, char buf[_NOCPP(n)]);
>>
>> 'foo' can then be used from C++ (but bounds information and
>> related warnings you would get in C are lost).
>>
>>
>> This works only at the topmost array but not for
>>
>> int bar(int a, int b, double (*matrix)[a][b]);
>>
>> which C++ AFAIK can only express using mdspan.
>>
>>
>> I wonder whether the situation can be improved. At least for 'foo'
>> it would already be a step forward if C++ could simply ignore the
>> size expression in function declarations, maybe only for extern
>> "C".
>>
>> For 'bar' it seems more difficult, but being able to parse these
>> declaration without error would also help a lot. But it would
>> also seem simply enough to allow calling of such function with fixed
>> arrays, i.e. supporting
>>
>> extern "C" int bar(int a, int b, double (*matrix)[a][b]);
>>
>> void g()
>> {
>> double matrix[10][10];
>> bar(10, 10, &matrix);
>> }
>>
>> would only require a very superficial support for this C feature
>> and no type system changes.
>>
>>
>> What do you think?
>>
>>
>> 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/2025/08/1565.php
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post:http://lists.isocpp.org/liaison/2025/08/1566.php
Received on 2025-08-13 22:11:52