Re: strong types in c - (safety samples)

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups	comp.lang.c
Subject	Re: strong types in c - (safety samples)
Date	2024-02-19 11:31 -0800
Organization	None to speak of
Message-ID	<877cj05jzs.fsf@nosuchdomain.example.com> (permalink)
References	<uqb741$13gk8$1@dont-email.me> <ur067b$20k5b$1@dont-email.me> <87bk8c5mdk.fsf@nosuchdomain.example.com> <ur08li$20k5b$2@dont-email.me> <ur08rh$20k5b$3@dont-email.me>

Show all headers | View raw

Thiago Adams <thiago.adams@gmail.com> writes:
> On 19/02/2024 16:03, Thiago Adams wrote:
>> On 19/02/2024 15:39, Keith Thompson wrote:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>> On 11/02/2024 16:27, Thiago Adams wrote:
>>>>> Consider:
>>>>> void f(int i);
>>>>> enum E {A};
>>>>> int main(){
>>>>>       f(A); //cake will have a warning here
>>>>> }
>>>>>
>>>>> I will create a diagnostic in cake for this and others.
>>>>> Basically I will respect the standard where it says enumerators are
>>>>> int, but I will create a strict mode where this and other types of
>>>>> conversion happens.
>>>>
>>>> It is interesting to note that treating warnings as errors is not
>>>> something new.
>>>>
>>>>
>>>> "The initial ISO C standard and its 1999 revision removed support for
>>>> many C language features that were widely known as sources of
>>>> application bugs due to accidental misuse. For backwards
>>>> compatibility, GCC 13 and earlier diagnosed use of these features as
>>>> warnings only. Although these warnings have been enabled by default
>>>> for many releases, experience shows that these warnings are easily
>>>> ignored, resulting in difficult to diagnose bugs. In GCC 14, these
>>>> issues are now reported as errors, and no output file is created,
>>>> providing clearer feedback to programmers that something is wrong. "
>>>>
>>>> https://gcc.gnu.org/gcc-14/porting_to.html#c
>>>
>>> I wouldn't call that "treating warnings as errors".  I'd call it "no
>>> longer treating errors[*] as mere warnings".
>>>
>>> [*] The C standard never requires anything other than a #error directive
>>> as a fatal error, but it does define constraints and syntax rules,
>>> violations of which require a diagnostic.  gcc has traditionally treated
>>> certain violations as non-fatal errors by default.  With gcc 14 (not yet
>>> released), they're apparently changing at least some of these from
>>> warnings to fatal errors (which IMHO they should have been already).
>>>
>> The interesting part is that it stop compilation. In this aspect the
>> new compiler is assuming a safer approach.

Yes, that's pretty much what I said.

>> The other approach could be settings then if someone wants to update
>> the compiler and keeps the old code compiler it is just a matter of
>> changing settings. But new compiler has new defaults.
>
> Something related
>
> https://embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/
>
> "Different vendors have different warning sets and warning detection
> logic, even if they support a common array of warning settings (such
> as with GCC and Clang). Code that compiles with one toolchain
> warning-free may not do so with another toolchain. We often see this
> with our open-source projects. We primarily use Clang, and it is a
> common occurrence that our CI server will report a warning when
> compiling our “warning-free” code with GCC."
>
> Safety is not portable.

The problem with -Werror is that it treats *all* warnings as fatal
errors.  (Which an also be an advantage if you're aware of the issues).

But that's not directly related.  The changes in gcc-14 have to do with
treating some constraint violations as fatal errors rather than warnings
by default.  You can use -pedantic-errors to do the same thing.

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

Thread

strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 16:27 -0300
  Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 16:43 -0300
    Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-18 13:49 -0300
      Re: strong types in c - (safety samples) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-18 14:25 -0800
        Re: strong types in c - (safety samples) David Brown <david.brown@hesbynett.no> - 2024-02-18 23:40 +0100
          Re: strong types in c - (safety samples) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-18 14:59 -0800
        Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-19 08:34 -0300
          Re: strong types in c - (safety samples) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-19 21:16 -0800
            Re: strong types in c - (safety samples) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-19 22:23 -0800
  Re: strong types in c - (safety samples) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 20:37 +0000
    Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 18:19 -0300
      Re: strong types in c - (safety samples) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 14:08 -0800
    Re: strong types in c - (safety samples) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-13 09:09 +0000
      Re: strong types in c - (safety samples) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-13 14:04 +0000
  Re: strong types in c - (safety samples) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 20:38 -0800
    Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-12 01:48 -0300
      Re: strong types in c - (safety samples) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-16 08:23 -0800
        Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-17 09:28 -0300
  Re: strong types in c - (safety samples) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-13 07:58 +0000
  Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-19 15:21 -0300
    Re: strong types in c - (safety samples) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-19 10:39 -0800
      Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-19 16:03 -0300
        Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-19 16:06 -0300
          Re: strong types in c - (safety samples) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-19 11:31 -0800
          Re: strong types in c - (safety samples) David Brown <david.brown@hesbynett.no> - 2024-02-19 21:36 +0100
            Re: strong types in c - (safety samples) bart <bc@freeuk.com> - 2024-02-19 22:13 +0000
              Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-19 21:59 -0300
                Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-19 22:03 -0300
              Re: strong types in c - (safety samples) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 02:48 +0000
                Re: strong types in c - (safety samples) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-22 13:00 +0100
              Re: strong types in c - (safety samples) David Brown <david.brown@hesbynett.no> - 2024-02-20 09:43 +0100
        Re: strong types in c - (safety samples) Thiago Adams <thiago.adams@gmail.com> - 2024-02-22 14:39 -0300
    Re: strong types in c - (safety samples) David Brown <david.brown@hesbynett.no> - 2024-02-20 09:37 +0100

csiph-web