On Saturday, April 15, 2023 at 3:23:12 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes:
> > Arrays passed as function arguments are pointers in C.
> >
> > For instance, this is valid code
> >
> > void F(int a[2]) {
> > typeof(a) p;
> > static_assert(_Generic(p, int * : 1, default: 0));
> > static_assert(_Generic(a, int * : 1, default: 0));
> > static_assert(sizeof(a) == sizeof(int*));
> > a = 0;
> > a++;
> > a--;
> > }
> Not relevant to your main point, but `a = 0;` makes a null pointer;
> then `a++` has undefined behavior. (I can't persuade gcc to warn
> about that.)
>
yes!

More warnings I would like to have

void F(int a[2]) {
if (a) { } //warning
} because if a should be a reference to something..otherwise better to use pointer.

Arrays passed as function arguments are pointers in C.

For instance, this is valid code

void F(int a[2]) {
typeof(a) p;
static_assert(_Generic(p, int * : 1, default: 0));
static_assert(_Generic(a, int * : 1, default: 0));
static_assert(sizeof(a) == sizeof(int*));
a = 0;
a++;
a--;
}

One thing we can do is:
void F(int a[const 2]) then a = 0; a++; a--; etc will not compile.

What I suggest is just deprecate with warning all of this
(and what I will implement in cake)

void F(int a[2]) {

//warning use typeof(&a[0]) instead
static_assert(_Generic(a, int * : 1, default: 0));

//warning use sizeof(&a[0]) instead
static_assert(sizeof(a) == sizeof(int*));

a = 0; //warning deprecated and may be removed
a++; //warning deprecated and may be removed
a--; //warning deprecated and may be removed
}

Does it make sense for you?

In 20 years we can make sizeof and typeof be array type.

Thiago Adams <thiago.adams@gmail.com> writes:
> Arrays passed as function arguments are pointers in C.
>
> For instance, this is valid code
>
> void F(int a[2]) {
> typeof(a) p;
> static_assert(_Generic(p, int * : 1, default: 0));
> static_assert(_Generic(a, int * : 1, default: 0));
> static_assert(sizeof(a) == sizeof(int*));
> a = 0;
> a++;
> a--;
> }

Not relevant to your main point, but `a = 0;` makes a null pointer;
then `a++` has undefined behavior. (I can't persuade gcc to warn
about that.)

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 15/04/2023 22:10, Thiago Adams wrote:
> On Saturday, April 15, 2023 at 3:23:12 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>> Arrays passed as function arguments are pointers in C.
>>>
>>> For instance, this is valid code
>>>
>>> void F(int a[2]) {
>>> typeof(a) p;
>>> static_assert(_Generic(p, int * : 1, default: 0));
>>> static_assert(_Generic(a, int * : 1, default: 0));
>>> static_assert(sizeof(a) == sizeof(int*));
>>> a = 0;
>>> a++;
>>> a--;
>>> }
>> Not relevant to your main point, but `a = 0;` makes a null pointer;
>> then `a++` has undefined behavior. (I can't persuade gcc to warn
>> about that.)
>>
> yes!
>
> More warnings I would like to have
>
> void F(int a[2]) {
> if (a) { } //warning
> }
> because if a should be a reference to something..otherwise better to use pointer.
>

It may be /better/ to use a pointer argument when it should never be 0,
but the standard is clear that "F(int * a)" and "F(int a[2])" are
identical. The C way to indicate that "a" cannot be a null pointer is
the ugly and unintuitive "F(int a[static 2])" (or whatever size you
want). (There really should be a "[[notnull]]" attribute.)

gcc still doesn't put a warning in your code here if you declare "void
F(int a [static 2])", but at least it will warn if you try to call F
with a null pointer.

Incidentally, on many systems "sizeof(int[2])" always equals
"sizeof(int*)", making your third static assertion a bit pointless. It
would make more sense to use a bigger array, rather than just 2 int's.

On 2023-04-16, David Brown <david.brown@hesbynett.no> wrote:
> It may be /better/ to use a pointer argument when it should never be 0,
> but the standard is clear that "F(int * a)" and "F(int a[2])" are
> identical. The C way to indicate that "a" cannot be a null pointer is
> the ugly and unintuitive "F(int a[static 2])" (or whatever size you
> want). (There really should be a "[[notnull]]" attribute.)

There is in the GCC function attribute syntax:

All pointer args non-null:

void fun(char *str, int *array, size_t) __attribute__((nonnull));

Only the second:

void fun(char *str, int *array, size_t) __attribute__((nonnull, 2));

Use of attributes common in ecosystems built on GCC or Clang.

THus, if/when this appears in the standard language, we can expect it to
be gratuitously different, just for shits and giggles. Or, more
cynically, for the sake of spiting the existing users of the extension.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 4/16/23 17:33, Kaz Kylheku wrote:
> There is in the GCC function attribute syntax:
>
> All pointer args non-null:
>
> void fun(char *str, int *array, size_t) __attribute__((nonnull));
>
> Only the second:
>
> void fun(char *str, int *array, size_t) __attribute__((nonnull(2)));
>
> Use of attributes common in ecosystems built on GCC or Clang.
>
> THus, if/when this appears in the standard language, we can expect it to
> be gratuitously different, just for shits and giggles. Or, more
> cynically, for the sake of spiting the existing users of the extension.
>
​You can also use the standard double-brackets syntax with the attribute
in the gnu:: namespace, e.g.
void fun(char *str, int *array, size_t) [[gnu::nunnull(2)]];
, which will also mean that it will still be accepted (if not
recognized) by other C23 compilers, and it will relieve the issue of
migration to a standard attribute should it be added.
Clang (but not gcc) also allows the potentially-less-confusing syntax of
marking the _arguments_ as nonnull (though confusingly, it still uses
the gnu:: prefix…):
void fun(char *str, int *array [[gnu::nonnull]], size_t);
…and there's also the returns_nonnull attribute:
void *my_malloc(size_t) [[gnu::returns_nonnull]];
/* now, instead of this: */
void *x;
if ((x = my_malloc(0xFF)) != NULL)
fun(str, x, 0xFF);
else
unreachable();
/* you can just do this: */
fun(str, my_malloc(0xFF), 0xFF);
Oh, but of course, it's not a C extension without two completely
different ways to do the same thing, because there's also the _Nonnull
type qualifier.
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't
have shit in Thunderbird 😩

On 16/04/2023 23:33, Kaz Kylheku wrote:
> On 2023-04-16, David Brown <david.brown@hesbynett.no> wrote:
>> It may be /better/ to use a pointer argument when it should never be 0,
>> but the standard is clear that "F(int * a)" and "F(int a[2])" are
>> identical. The C way to indicate that "a" cannot be a null pointer is
>> the ugly and unintuitive "F(int a[static 2])" (or whatever size you
>> want). (There really should be a "[[notnull]]" attribute.)
>
> There is in the GCC function attribute syntax:
>
> All pointer args non-null:
>
> void fun(char *str, int *array, size_t) __attribute__((nonnull));
>
> Only the second:
>
> void fun(char *str, int *array, size_t) __attribute__((nonnull, 2));
>

Sure - but I think the OP was interested in standard C.

> Use of attributes common in ecosystems built on GCC or Clang.
>
> THus, if/when this appears in the standard language, we can expect it to
> be gratuitously different, just for shits and giggles. Or, more
> cynically, for the sake of spiting the existing users of the extension.
>

The standards committee takes inspiration from existing extensions, but
they have to fit them in a wider context. Sometimes gcc (or clang)
extensions are rather weakly specified, or tightly tied to other details
of the compiler, or fail to consider all the edge cases. And often the
choices made by gcc developers decades ago are not ideal in modern
times. And unlike the gcc developers, the standards committee has to
take into account that there are other compilers around - there will be
many compilers that have some way of marking a pointer as non-nullable.

In this case, I'd far rather see an attribute that works more like
"restrict" -

void fun(char * str, int * [[nonnull]] array, size_t);

That would be incompatible with the gcc extension but much better.