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@lists.isocpp.org
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@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2025/08/1566.php