Am Dienstag, dem 12.08.2025 um 08:32 +0200 schrieb Corentin:
>
>
> On Tue, Aug 12, 2025 at 12:07 AM Martin Uecker via Liaison <liaison_at_[hidden]> wrote:
> > Am Montag, dem 11.08.2025 um 23:35 +0200 schrieb Jens Maurer:

...

> >
> > > Should we rather
> > > strive for the attribute annotation syntax that is being
> > > discussed in a parallel thread?
> >
> > The issue is that in C we need a solution also for array
> > sizes, and I am not convinced the solution proposed for
> > the attributes (late parsing) really works well for those
> > too. As soon as put things into the type is is visible
> > from inside the language, so you need to worry about circular
> > dependencies. A late-parsing design was already rejected
> > by Dennis Ritchie for this reason. Another problem is
> > that name lookup becomes more confusing.
> >
> > I wonder how C++ is dealing with this. With the new
> > syntax for template functions it seems you also would
> > have more situations where one might want to refer
> > to other parameters. For example, you can write
> >
> > template<typename B>
> > void foo(char a[sizeof(B)], B b);
> >
> > where typename B forwards declares B, but the following
> > does not work:
> >
> > void foo(char a[sizeof(b)], auto b);
> >
>
>
>
> This has never been an issue in C++ because we use things like std::array, std::vector, std::span
> and otherwise try to avoid interfaces that would be at odds with lookup rules.

My apologies for distracting you with C array, but the fundamental
name lookup issue affects also C++ library types:

template<typename B>
void foo(std::array<float, sizeof(B)>, B x);


And one may also want to access other properties of types, e.g. the
typename of elements or iterators etc. This is not only about sizes.


>
> C++ solutions have a track record of being either safer by construction or are cheaply bound-checked
> which is done across many implementations - and increasingly so.

Grat!

>
> While I appreciate that what you propose would increase compatibility with C,
>

hen let's work on this. Compatibility work can not alwaye be a
one-sided thing. All I am asking is that C++ accepts these prototypes.
It would really help us a lot.


> it would certainly not improve safety.

It certainly does in C:
https://godbolt.org/z/bGPM8K4br

> I think it's fairly important that the syntax remains reflective of semantics.
> C arrays parameters are not a thing,

There are a thing in C. Please stop trying to gaslight me.

Martin

> And if anything, we should deprecate the use of array types as parameter declarations.
>
> Address sanitizers (tripping on access), higher level types with preconditions, or, for C compatibility, bound check annotations
> are less misleading ways to express intent, and less likely to confuse users.
>
>
>
>
>
> >
> >
> > Martin
> >
> >
> >
> > >
> > > 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/1567.php