C++ Logo


Advanced search

Re: [wg14/wg21 liaison] (SC22WG14.18841) [Fwd: sudo buffer overlow]

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Sun, 31 Jan 2021 20:29:35 +0000
Am Sonntag, den 31.01.2021, 20:46 +0100 schrieb Jens Gustedt via Liaison:
> Niall,
> on Sun, 31 Jan 2021 17:37:21 +0000 you (Niall Douglas via Liaison
> <liaison_at_lists.isocpp.org>) wrote:
> > Hopefully this made sense to you? Just to be clear, C under this
> > proposal
> this proposal?
> I know that we now have WG14 proposals for integrating lambdas into C
> :-)
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2633.pdf
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2634.pdf
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2635.pdf
> but I wasn't aware that there is one for this:
> > would have most of C++ lambdas, but C's equivalent to
> > std::function<ret(args...)> would probably be something like
> > _Function(ret, args...). i.e. _Function would be a compiler built-in.
> already. I kept these things out for the moment, to ensure
> that WG14 first looks into everything that can be made here without
> ABI changes or additions.
> > I'm not a language person, nor a compiler person, but it seems to me
> > that dynamic runtime types do not easily produce bare metal execution
> > performance. I think indirection of dynamic information whilst
> > keeping the top level of the type system 100% static is a better
> > design approach.
> If you put this in this generality, it immediately sounds like a big
> deal.
> VLA (or VM types for that matter) only have the size (or sizes if
> multidimensional) as dynamic components and are not very difficult,
> neither to implement nor to use. C has them since a long time and they
> work well. And, contrary to the common belief and urban legends, they
> can be used to make programming with large arrays or even matrices
> much safer.
> I would hope that we could go here in a similar way to what I am
> trying to do with lambdas for WG14: take the simple and
> existing things that are well accomplished and mastered in one
> language and pull them into the other language to broaden the
> intersection. VM types here would be important to have for function
> interface compatibility between C and C++.

I agree,

I think a good first step would be simple ignoring the
length in the first level for extern C.

extern "C" void foo(int N, double x[N]);


extern "C" void foo(int N, double x[/* N */]);

for the C++ side. This would already remove most
of the pain for shared headers.

On the other hand, if C++ really does not want VM
types maybe we could define some mapping of C
into C++ types which could be used for extern "C".


Received on 2021-01-31 14:29:40