public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Yair Lenga <yair.lenga@gmail.com>
To: gcc@gcc.gnu.org
Subject: [RFC] Support for nonzero attribute
Date: Sat, 4 Jun 2022 06:26:09 -0400	[thread overview]
Message-ID: <CAK3_KpO=VFWmB0AdtNOqNrVjv29pU4jxNgfko14qTWHzYBxivw@mail.gmail.com> (raw)
In-Reply-To: <mailman.2312.1654300374.1672222.gcc@gcc.gnu.org>

Before becoming a "C" programmer, I spent few years building simulations in
Pascal. I still remember (and long for) the ability to define integer with
range constraints:

var foobar: 10..50 ;         // Accept 10, 11, 12, ..., 49, 50

The specific non-zero constraint is a specific implementation of the range
operator (with some exception see below). Wanted to suggest going for
more ambitious goal: add min and max attributes to (integer) types and
variables. This will address the specific case of non-zero, but has a lot
of potential to be built upon: can be used for compile time testing, run
time parameter checking, storage optimization (similar to packed), run time
optimization (e.g. eliminating runtime tests), .... Also expected range
information can have a positive impact on code safety/validation.

typedef int postivieInt __attribute__ (minValue(1), maxValue(INTMAX) ;
typedef int foobar __attribute__ ((minValue(10), maxValue(50)) ;

If this can be implemented, it will provide for much more
flexibility (e.g., ability to specify that any specific parameter must be
non-zero).

int foo (int x __attribute__ (minValue(1)), int y, int z __attribute__
(minValue(1))  ;

int foo (positiveInt x, int y, positiveInt y) ;

Assuming this can be implemented, compile time tests should be automatic,
whenever possible. Run time tests should be enabled with flags (to allow
optimized code to run without expensive run time tests).

Note1:
While for many use cases non-zero (including  forcing ENUM value, and
minValue(1) are the same, the above does not cover the user case where a
signed int does not accept a zero. For this use case, I believe the nonZero
attribute is still needed.

typedef int limitedInt __attribute((minValue(-20)), maxValue(+20), nonZero)

I do recall that few other languages had similar abilities (Ada, Java (via
annotations), ...)

Yair


>
>
>
> ---------- Forwarded message ----------
> From: Miika <nykseli@protonmail.com>
> To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
> Cc:
> Bcc:
> Date: Fri, 03 Jun 2022 16:34:48 +0000
> Subject: [RFC] Support for nonzero attribute
> Hello,
>
> I would like to add support for new attribute: nonzero.
> Nonzero attribute works the same way as nonnull but instead of checking for
> NULL, it checks for integer or enum with value 0.
>
> Nonzero attribute would issue warnings with new compiler flag
> -Wnonzero and -Wnonzero-compare.
>
> Nonzero could be useful when user wants to make sure that for example enum
> with value of 0 is not used or flag argument is not set to 0.
>
>
> For example compiling following code with "gcc -Wnonzero -Wnonzero-compare
> foo.c"
>
> #include <stdio.h>
> enum bar{NONE, SOME};
>
> void foo(int d, enum bar b) __attribute__ ((nonzero (1, 2)));
> void foo(int d, enum bar b) {
>         printf("%d\n", d == 0);
>         printf("%d\n", b == NONE);
> }
>
> int main() {
>         foo(0, NONE);
> }
>
>
> Would give the following error
>
> foo.c: In function 'main':
> foo.c:11:9: warning: zero argument where nonzero required (argument 1)
> [-Wnonzero]
>    11 |         foo(0, NONE);
>       |         ^~~
> ...

       reply	other threads:[~2022-06-04 10:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.2312.1654300374.1672222.gcc@gcc.gnu.org>
2022-06-04 10:26 ` Yair Lenga [this message]
2022-06-04 11:55   ` Miika
2022-06-04 21:29     ` Yair Lenga
2022-06-13  9:49   ` Richard Biener
2022-06-03 16:34 Miika
2022-06-03 16:45 ` Jakub Jelinek
2022-06-04 11:25   ` Miika
2022-06-05 20:09 ` Miika
2022-06-06 18:42   ` Ben Boeckel
2022-06-07 19:39     ` Miika
2022-06-07 19:44       ` Jonathan Wakely
2022-06-07 19:46         ` Jonathan Wakely
2022-06-07 19:56           ` Miika
2022-06-08 17:42   ` Eric Gallager
2022-06-08 20:59     ` Miika
2022-06-09  4:36       ` Eric Gallager
2022-06-09 18:06         ` Miika
2022-06-12  4:25   ` Prathamesh Kulkarni
2022-06-13 12:55     ` Miika
2022-06-13 16:02       ` Martin Sebor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK3_KpO=VFWmB0AdtNOqNrVjv29pU4jxNgfko14qTWHzYBxivw@mail.gmail.com' \
    --to=yair.lenga@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).