On 2024-02-11, Thiago Adams <thiago.adams@gmail.com> wrote:

Consider:

void f(int i);

enum E {A};

int main(){
f(A); //cake will have a warning here
}

Why bother with enums that are stronger than in C++.

Mainly, you don't want this:

void f(enum E);
f(42);

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thiago Adams <thiago.adams@gmail.com> writes:

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.

int main(){
f(true); //cake will have a warning here
f('A'); //not sure this one..
}

the same for enums.

This is comp.lang.c. Please take any discussions of languages
other than C to a venue where those discussions are topical,
such as comp.lang.misc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Clang has an existing system for this with its [[clang::enum_extensibility(open)]] and
[[clang::enum_extensibility(closed)]] attributes.


--
Blue-Maned_Hawk│shortens to Hawk│/ blu.mɛin.dÊ°ak/ │he/him/his/himself/Mr. blue-maned_hawk.srht.site
Looks like it could explode at any moment!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

On 11/02/2024 20:37, Kaz Kylheku wrote:

On 2024-02-11, Thiago Adams <thiago.adams@gmail.com> wrote:

Consider:

void f(int i);

enum E {A};

int main(){
f(A); //cake will have a warning here
}

Why bother with enums that are stronger than in C++.
Mainly, you don't want this:
void f(enum E);
f(42);

The problem is that enums often have to go through things which are
external to the program. For example they might be stored in a database
which is read by a parser which isn't written in C.

That's "a problem" (though not usually a hard one) but it's not got
anything to do with the current discussion about how C does, or should,
limit the use of implicit type conversions for enums.

Typically, "the problem" would be solved by the build system. It would
ensure that the names and values in the DB match (or correspond to)
those used in the C program, probably by generating a header file and/or
a DB table as part of the build.

So they can't be
treated as entirely opaque and sometimes you do need to manipulate the values.

But no one is suggesting that. The discussion is about what implicit
type conversions are, or should, be allowed without any diagnostic.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thiago Adams <thiago.adams@gmail.com> writes:

Em 2/12/2024 1:38 AM, Tim Rentsch escreveu:

Thiago Adams <thiago.adams@gmail.com> writes:

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.


int main(){
f(true); //cake will have a warning here
f('A'); //not sure this one..
}

the same for enums.

This is comp.lang.c. Please take any discussions of languages
other than C to a venue where those discussions are topical,
such as comp.lang.misc.

Not sure what you mean.
This is about C and diagnostics.

For instance:

void f(int i);
int main()
{
f(true);
}

If a compiler emit a diagnostic "warning passing _Bool to integer" do
you think this is not C any more?

The language you're talking about may have the same syntax
as C, but it has different semantic rules, and that is the
point of your discussion. What you're talking about is not
about C. I know you like to pretend that it's the same,
but it isn't.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/02/2024 23: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.

They were £10, last I bought a copy, so it's not /that/ expensive. But
IMHO the "essential type" stuff is not at all good.

(It's available for £15.00 from misra.org.uk. I'm almost, but not
quite, tempted to buy a copy.)

I'll probably buy a current version, because it is somewhat relevant to
my work. (Or I could get the office to buy it.)

There's no C type called "boolean" unless you define it yourself.
The "essential type" they call "boolean" obviously isn't bool or
_Bool. It's not even a type in the C sense. And other posts here
have suggested that MISRA never actually defines what "essential
type" means.

Do the guidelines use the term "essential type" for "types" other
than "boolean"?

Oh, yes. They use it for lots of things, without good definitions,
without accurate consideration for things like integer promotion rules,
and in ways that somewhat differ from the actual C rules.

It just seems that the authors failed to think of the word
"condition", which would be a much clearer and more precise
description of what I presume they're trying to say. For example,
they could have written than any expression used as a condition
shall not be an assignment and shall not have an assignment as
any of its subexpressions, and anyone familiar with C would know
exactly what they mean. (The C standard doesn't define "condition",
but it would be easy to enumerate the contexts in which expressions
are treated as conditions, i.e., where a decision is made based on
whether the expression compares unequal to zero.)

They were trying to think of a way to say that things like the 0 or 1
int result of a comparison is not really the same thing as a normal
"int", and that the enumeration constants for an enumerated type are not
the same "essential type" as "int", and various other such things. They
are trying to invent their own type system that they think is better
than C's (and in some ways it /is/ better), and then say you should
write your C code as though it followed /their/ type system and not C's
type system.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)