Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #382344 > unrolled thread

strong types in c - (safety samples)

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#382777

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).

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#382778

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.

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.

[toc] | [prev] | [next] | [standalone]

#382779

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.
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#382781

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 */

[toc] | [prev] | [next] | [standalone]

#382782

On 19/02/2024 20:06, Thiago Adams wrote:
> 
> 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 blog's reasoning is flawed.

A project build is dependent on three main things.  The source code is 
one.  The toolchain is another.  And the build instructions - including 
toolchain flags and options, linker scripts, and perhaps things like the 
order of files passed to the linker.  (It may also depend on things like 
the time and day, if you use macros like __DATE__ and __TIME__, which is 
an extraordinarily silly thing to have as a dependency.)

If you are making code that is important enough to be using CI tools, 
and you have random mixtures of toolchains for different developers, 
your CI server, and other parts of the system, then your development 
process is badly broken.  You are doing your CI and testing on a 
different project from the one developers are working on, and the 
projects being shipped to customers can be different again.

It can be a different matter if the deliverable for the project is just 
the source code.  But if it is a binary, then everything that goes into 
the binary is part of the source for it, and needs to be kept under 
tight control in the development process.

You might feel that it is useful to build multiple binaries using 
different toolchains, perhaps to take advantage of static checks that 
are available in a range of tools, or to ensure wider compatibility. 
But then all those toolchains are part of the development process.

If you have not reached the stage of getting reproducible builds that 
give the same binary every build for every developer, you are not ready 
for tools like CI.


This is all IMHO, needless to say.

[toc] | [prev] | [next] | [standalone]

#382783

On 19/02/2024 20:36, David Brown wrote:
> On 19/02/2024 20:06, Thiago Adams wrote:
>>
>> 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 blog's reasoning is flawed.
> 
> A project build is dependent on three main things.  The source code is 
> one.  The toolchain is another.  And the build instructions - including 
> toolchain flags and options, linker scripts, and perhaps things like the 
> order of files passed to the linker.  (It may also depend on things like 
> the time and day, if you use macros like __DATE__ and __TIME__, which is 
> an extraordinarily silly thing to have as a dependency.)

I often use DATE and TIME in my products to help indicate version.

It's not silly at all.

But it means the binary produced will be slightly different to one 
generated 5 minutes earlier.

[toc] | [prev] | [next] | [standalone]

#382785

Em 2/19/2024 7:13 PM, bart escreveu:
> On 19/02/2024 20:36, David Brown wrote:
>> On 19/02/2024 20:06, Thiago Adams wrote:
>>>
>>> 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 blog's reasoning is flawed.
>>
>> A project build is dependent on three main things.  The source code is 
>> one.  The toolchain is another.  And the build instructions - 
>> including toolchain flags and options, linker scripts, and perhaps 
>> things like the order of files passed to the linker.  (It may also 
>> depend on things like the time and day, if you use macros like 
>> __DATE__ and __TIME__, which is an extraordinarily silly thing to have 
>> as a dependency.)
> 
> I often use DATE and TIME in my products to help indicate version.
> 
> It's not silly at all.
> 
> But it means the binary produced will be slightly different to one 
> generated 5 minutes earlier.
> 

I have a better sample

Consider the literal string

u8"maçã"

if the source code is not UTF8 encoded then the result of compilation 
u8"maçã" will depend  where (locale) the source code is compiled because 
the compiler will encode the bytes from the file according with the 
locale. This happens all the time with visual studio where the default 
for new files is not utft8 (fortunately the compiler have a warning now, 
but not default it needs to be added)

for this reason, source code should be standardised to be UTF8. (I guess 
C++ has a proposal for that)

[toc] | [prev] | [next] | [standalone]

#382786

Em 2/19/2024 9:59 PM, Thiago Adams escreveu:
...
> for this reason, source code should be standardised to be UTF8. (I guess 
> C++ has a proposal for that)
> 

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2295r6.pdf

[toc] | [prev] | [next] | [standalone]

#382798

On 2024-02-19, bart <bc@freeuk.com> wrote:
> I often use DATE and TIME in my products to help indicate version.
>
> It's not silly at all.
>
> But it means the binary produced will be slightly different to one 
> generated 5 minutes earlier.

The problem is that it's possible that the only difference is the
date and time. In which case it's the same program. Just the binary is
gratuitously different.

Some GNU/Linux distros nowadays are obsessed with reproducibility:
meaning that whenver the same version of the same thing is built, all
the deliverables such as executables, PDF files or whatever else is bit
for bit identical to the previous runs.

This works even if if __DATE__ and __TIME__ are used; those get frozen.

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

[toc] | [prev] | [next] | [standalone]

#382902

On 20.02.2024 03:48, Kaz Kylheku wrote:
> On 2024-02-19, bart <bc@freeuk.com> wrote:
>> I often use DATE and TIME in my products to help indicate version.
>> It's not silly at all.
>> But it means the binary produced will be slightly different to one 
>> generated 5 minutes earlier.

I recall our configuration management and version control systems
supported variables for release information[*] that got expanded by
the system as part of the defined software development processes...

> 
> The problem is that it's possible that the only difference is the
> date and time. In which case it's the same program. Just the binary is
> gratuitously different.

...and it was a project's decision whether this information had an
accuracy of check-in level ("patch-level"), or minor release level,
or anything else. So binaries could vary in that attribute or not.

> 
> Some GNU/Linux distros nowadays are obsessed with reproducibility:
> meaning that whenver the same version of the same thing is built, all
> the deliverables such as executables, PDF files or whatever else is bit
> for bit identical to the previous runs.
> 
> This works even if if __DATE__ and __TIME__ are used; those get frozen.

Janis

[*] So there was no need to have an own mechanism for every language
or every type of source! - I don't think it's a good idea to have
for every type of item its own distinct and inconsistent mechanism
and format defined to support version and/or time/date information.

[toc] | [prev] | [next] | [standalone]

#382811

On 19/02/2024 23:13, bart wrote:
> On 19/02/2024 20:36, David Brown wrote:
>> On 19/02/2024 20:06, Thiago Adams wrote:
>>>
>>> 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 blog's reasoning is flawed.
>>
>> A project build is dependent on three main things.  The source code is 
>> one.  The toolchain is another.  And the build instructions - 
>> including toolchain flags and options, linker scripts, and perhaps 
>> things like the order of files passed to the linker.  (It may also 
>> depend on things like the time and day, if you use macros like 
>> __DATE__ and __TIME__, which is an extraordinarily silly thing to have 
>> as a dependency.)
> 
> I often use DATE and TIME in my products to help indicate version.
> 
> It's not silly at all.
> 
> But it means the binary produced will be slightly different to one 
> generated 5 minutes earlier.
> 

It is definitely a silly thing to do if you are looking for tight 
control of your builds - precisely because it means your binaries differ 
on different builds.  When you are running a more sophisticated 
development setup - such as one where CI is appropriate - reproducible 
builds are important.  __DATE__ and __TIME__ guarantee that you can't do 
that.

Not all development has to be with such builds, of course, and __DATE__ 
and __TIME__ can be helpful if you are going through a lot of changes 
quickly and want to compare runs.  But it means you can never go back to 
your previous source and get exactly the same binary.

[toc] | [prev] | [next] | [standalone]

#382908

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.
> 
> 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.
> 
> 
> 

I did an experiment where is possible to create "sets" of warnings.


#define SAFE_REGION \
    _Pragma("GCC  diagnostic push") \
    _Pragma("GCC  diagnostic error \"-Wenum-compare\"")\
    _Pragma("GCC  diagnostic error \"-Wparentheses\"")\
    _Pragma("GCC  diagnostic error \"-Wuninitialized\"")

#define RESTORE \
   _Pragma("GCC  diagnostic pop")

enum E1 { A };
enum E2 { B };

SAFE_REGION
int main() {
   int a, b;
   if (a = b){}
   if (A == B){}
}
RESTORE

[toc] | [prev] | [next] | [standalone]

#382810

On 19/02/2024 19:21, Thiago Adams wrote:
> 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
> 
> 

This refers to a small number of specific warnings, not warnings in 
general, and it /is/ new - gcc 14 is not yet released.

It's a good change, IMHO - and long overdue.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web