Hi DBJ and JeanHeyd,

On 11/14/21 21:16, DBJ via Std-Proposals wrote:
> "Shows you how little this gets used. And it's not just the fact that
> I'm a C++
> developer primarily -- if I ask my colleagues who code mostly in C, I
> bet you
> they won't know."
>
> This puzzle's me. Provided, I understood it right.
>
> Please see here, for a comprehensive post on this subject:
> https://gustedt.wordpress.com/2011/01/13/vla-as-function-arguments/
> <https://gustedt.wordpress.com/2011/01/13/vla-as-function-arguments/>

Yes, I have read the many posts by Jens Gustedt;
they are quite good.

BTW, I must:

     A: Because we read from top to bottom, left to right.
     Q: Why should I start my reply below the quoted text?

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: The lost context.
     Q: What makes top-posted replies harder to read than bottom-posted?

     A: Yes.
     Q: Should I trim down the quoted part of an email to which I'm
replying?

:)

> On 11/14/21 20:41, Alejandro Colomar (man-pages) wrote:
> > Yup, it's a weird and rarely-used syntax
> > (IMHO, because it's not very well designed,
> > and also because it's ignored by all compilers).
> > Let me clarify it:
> >
> > '[static n]' means that both:
> >
> > - The pointer cannot be NULL.
> > - the array has at least 'n' elements.
> >
> > '[n]' means:
> >
> > - nothing at all. 'n' is ignored.
> >
> > '[restrict n]' means:
> >
> > - 'n' is ignored.
> > - the storage may not overlap any other 'restrict' pointers or
> arrays.
> >
> > '[static restrict n]' means:
> >
> > - The pointer cannot be NULL.
> > - the array has at least 'n' elements.
> AND
> - the storage may not overlap any other 'restrict' pointers or
> arrays.
>
> I missed it.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>

------------------


On 11/14/21 21:26, JeanHeyd Meneide via Std-Proposals wrote:
> This is changing, including in the C Standard itself. The new C
> Standard is going to ship signatures using the static syntax since it
> aids with compile-time QoI errors regarding too-small arrays.

No, it's not. There was a proposal (by Jens Gustedt),
but it wasn't accepted (and I'm happy it wasn't).

See this thread on the linux-man@ mailing list
where I discussed about that with Jens:

<https://lore.kernel.org/linux-man/eebb99c0-dd12-152b-53fc-4ec1326fc29f_at_[hidden]/T/#m820362e6aed9fe57fbb94d53d2f0aef7c5fefc54>

And a reply of mine also there, explaining why I think it would have
been a bad idea:

<https://lore.kernel.org/linux-man/eebb99c0-dd12-152b-53fc-4ec1326fc29f_at_[hidden]/T/#m47df1bbbcfc0bae7c333354a82367b87a59b4961>

> Sanitizers are picking up on pointer-to-VLA (not VLA) definitions now,
> and warning on size arrays. We might also be looking into allowing the
> void[ static n ] syntax so we can start appropriately decorating
> functions like memcpy, memset, and similar.

It's good to know that compilers are picking up. The last time I tried,
was in the times of GCC 6, and it ignored 'static'.

>
> It would be nice to not have to macro-define these things away.

As I said, '[[nonnull]]' should be added to C & C++ (with the meaning of
'[[gnu::nonnull]]'), and it would make 'static' obsolete. If C++ ever
adds 'static' with that meaning, it would be marked as deprecated from
day 0, so I think we better keep it out, and let compilers ignore it as
needed.


Thanks,
Alex