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 1 of 2  [1] 2  Next page →

#382344 — strong types in c - (safety samples)

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.

[toc] | [next] | [standalone]

#382345

Em 2/11/2024 4:27 PM, Thiago Adams escreveu:
> 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 also part of "is C prepared to be safer language"?
This can breaks code, or it can be a diagnostic..
If it breaks code it needs to work as "warning profile" where 
programmers can opt in or out.

With "warning profiles" the new semantics can be added without breaking 
compatibility.

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

#382695

Em 2/11/2024 4:43 PM, Thiago Adams escreveu:
> Em 2/11/2024 4:27 PM, Thiago Adams escreveu:
>> 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.



In MISRA the concept is called "essential type"

a == b

The essential type of this expression is boolean.

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

#382712

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.

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

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"?

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

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

#382717

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.

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

#382722

David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.

And then they don't clearly define their own type system, or distinguish
C types from MISRA types.

I suspect it's easy enough to get through the vague wording and figure
out what the guidelines actually mean, but it sounds like the whole
thing would benefit from a rewrite.

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

#382755

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

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

#382800

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

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

#382802

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

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

#382346

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

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

#382348

Em 2/11/2024 5:37 PM, Kaz Kylheku escreveu:
> 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);
> 

In C++ this also compiles without errors.

https://godbolt.org/z/fYz4zqY3Y

(not sure if I understood you)

and

enum E {A};
void f(enum E e);

int main(){
      f(1);
}

it an error in c++.
none in C

https://godbolt.org/z/7fqnv47dM

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

#382351

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 2/11/2024 5:37 PM, Kaz Kylheku escreveu:
>> 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);
>> 
>
> In C++ this also compiles without errors.
>
> https://godbolt.org/z/fYz4zqY3Y
>
> (not sure if I understood you)

C++ has both C-style enums and "enum class" types, that have stricter
type checking (fewer implicit conversions).

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

#382390

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. So they can't be 
treated as entirely opaque and sometimes you do need to manipulate the 
values.

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

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

#382397

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.

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

#382366

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.

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

#382368

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?

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

#382580

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.

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

#382613

Em 2/16/2024 1:23 PM, Tim Rentsch escreveu:
> 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.

Perhaps you got a bad first impression. However, Cake is indeed 100% C. 
The modes I am discussing here have not been implemented yet. Even when 
implemented, they are not fundamentally different from, for instance, 
gcc's -werror option.

I am not pretending Cake is C. I am following the C23 standard and other 
compilers like gcc, clang and msvc. Cake have some extensions, like any 
other C compiler and the extensions are documented.

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

#382388

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!

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

#382775

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web