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

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

On 2/19/2024 3:34 AM, Thiago Adams wrote:
> On 18/02/2024 19:25, Keith Thompson wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>> [...]
>>> In MISRA the concept is called "essential type"
>>>
>>> a == b
>>>
>>> The essential type of this expression is boolean.
>>
>> I don't have access to the MISRA guidelines (they're not free),
>> but if that's what they say, it sounds like they're badly written.
>
> Searching for MISRA "essential type" we can find something.
>
> For instance:
>
> https://stackoverflow.com/questions/44131637/misra-c-2012-rule-10-1-boolean-operand-to-be-used-in-case-where-expression-is-of
>
>

https://www.stroustrup.com/JSF-AV-rules.pdf

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/19/2024 3:34 AM, Thiago Adams wrote:
>> On 18/02/2024 19:25, Keith Thompson wrote:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> [...]
>>>> In MISRA the concept is called "essential type"
>>>>
>>>> a == b
>>>>
>>>> The essential type of this expression is boolean.
>>>
>>> I don't have access to the MISRA guidelines (they're not free),
>>> but if that's what they say, it sounds like they're badly written.
>> Searching for MISRA "essential type" we can find something.
>> For instance:
>> https://stackoverflow.com/questions/44131637/misra-c-2012-rule-10-1-boolean-operand-to-be-used-in-case-where-expression-is-of
>
> https://www.stroustrup.com/JSF-AV-rules.pdf

Can you clarify the relevance? It doesn't say much about bool or
booleans and doesn't mention "essential type" at all.

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

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.

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.

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.

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