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

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

Inconsistent...

Started by"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
First post2023-10-30 14:01 -0700
Last post2023-11-10 21:02 -0800
Articles 11 on this page of 71 — 7 participants

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

Contents

  Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-30 14:01 -0700
    Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-30 14:11 -0700
    Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-30 14:30 -0700
      Re: Inconsistent... Richard Harnden <richard.nospam@gmail.invalid> - 2023-10-30 22:01 +0000
        Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-30 15:09 -0700
    Re: Inconsistent... bart <bc@freeuk.com> - 2023-10-30 23:22 +0000
      Re: Inconsistent... bart <bc@freeuk.com> - 2023-10-30 23:44 +0000
      Re: Inconsistent... bart <bc@freeuk.com> - 2023-10-31 02:05 +0000
        Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-31 11:32 +0000
          Re: Inconsistent... bart <bc@freeuk.com> - 2023-10-31 14:16 +0000
            Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-31 16:15 +0000
              Re: Inconsistent... bart <bc@freeuk.com> - 2023-10-31 18:35 +0000
                Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-31 14:05 -0700
                  Re: Inconsistent... bart <bc@freeuk.com> - 2023-10-31 22:29 +0000
                Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 00:39 +0000
                  Re: Inconsistent... bart <bc@freeuk.com> - 2023-11-01 10:35 +0000
                    Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 13:29 +0000
                      Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-01 12:52 -0700
                      Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-01 14:30 -0700
          Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-31 13:37 -0700
            Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 00:44 +0000
              Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-31 20:26 -0700
                Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 11:05 +0000
              Re: Inconsistent... bart <bc@freeuk.com> - 2023-11-01 10:59 +0000
                Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-01 13:01 +0100
                  Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 13:52 +0000
                    Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-01 20:12 +0100
                      Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-01 12:52 -0700
                        Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-02 10:04 +0100
                          Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-02 10:51 -0700
                            Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-02 11:02 -0700
                              Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-02 20:02 +0100
                                Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-02 12:03 -0700
                                Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-03 23:57 -0700
                                  Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-04 00:11 -0700
                            Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-02 20:28 +0000
                              Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-03 10:23 +0100
                                [OT] Encryption (Was: Inconsistent...) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-03 10:10 +0000
                                  Re: [OT] Encryption (Was: Inconsistent...) David Brown <david.brown@hesbynett.no> - 2023-11-03 15:01 +0100
                                    Re: [OT] Encryption (Was: Inconsistent...) scott@slp53.sl.home (Scott Lurndal) - 2023-11-03 16:52 +0000
                                      Re: [OT] Encryption (Was: Inconsistent...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-03 15:12 -0700
                                Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-03 15:11 -0700
                Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 13:43 +0000
                  Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-01 12:53 -0700
                    Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 20:08 +0000
                      Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-01 13:12 -0700
                        Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 21:12 +0000
                          Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-01 14:16 -0700
                            Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 21:43 +0000
                              Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-01 16:02 -0700
                        Re: Inconsistent... bart <bc@freeuk.com> - 2023-11-01 22:59 +0000
    Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-30 23:52 +0000
      Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-31 13:45 -0700
      Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-31 14:29 -0700
      Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-02 10:10 +0100
        Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-02 09:52 +0000
          Re: Inconsistent... bart <bc@freeuk.com> - 2023-11-02 11:31 +0000
            Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-02 13:52 +0100
              Re: Inconsistent... bart <bc@freeuk.com> - 2023-11-02 14:07 +0000
                Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-02 16:53 +0100
                  Re: Inconsistent... bart <bc@freeuk.com> - 2023-11-02 19:15 +0000
                    Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-03 10:33 +0100
            Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-02 20:43 +0000
              Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-02 13:47 -0700
          Re: Inconsistent... David Brown <david.brown@hesbynett.no> - 2023-11-02 13:34 +0100
    Re: Inconsistent... Richard Harnden <richard.nospam@gmail.invalid> - 2023-11-01 20:32 +0000
      Re: Inconsistent... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-11-01 21:36 +0000
        Re: Inconsistent... Richard Harnden <richard.nospam@gmail.invalid> - 2023-11-01 21:54 +0000
        Re: Inconsistent... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-09 15:54 -0800
    Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-09 01:16 -0800
    Re: Inconsistent... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-10 21:02 -0800

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

#379466

Frombart <bc@freeuk.com>
Date2023-11-02 19:15 +0000
Message-ID<ui0shd$3kva7$1@i2pn2.org>
In reply to#379461
On 02/11/2023 15:53, David Brown wrote:
 > On 02/11/2023 15:07, bart wrote:

 >> So what were the reasons for Linux to use 64 bits for int_fast16_t 
and Windows to use 32 bits?
 >>

 >> So for both these cases, Windows' 32 bits make more sense than 64.
 >>
 >
 > People who know far more about this than me, and even more than you 
(I know you are more familiar with the details of x86-64 instructions 
than I am), and who care about efficiency more than Microsoft (for whom 
consistency with old flaws is more important than efficiency of new 
systems), picked 8-byte types for the "fast" types on 64-bit systems.  I 
am confident that they did so on more evidence and technical data than 
we have here.

This is in line with my idea that using a 64-bit 'int' in C would have 
been better, as discussed earlier in the year. As it is, 'int' is 
usually 32 bits, and is still used extensively in programs rather than 
explicitly requesting a 64-bit type.

It would eliminate a lot of problems, and perhaps fixed some of the 
issues in the OP's program.

 >
 > Of course there will be situations when 32-bit types will be faster 
than 64-bit types - such decisions are based on statistical information 
and common patterns, and will never be perfect in all circumstances.
 >
 >> (If I look at the actual stdint.h for mingw, int16_t is just 
'short'. On my WSL, inside /usr/include/stdint.h, it is defined on top 
of long, which may be 32 or 64 bits.)
 >>
 >
 > "int16_t" must be exactly 16 bits, and many <stdint.h> files will 
define it based on "short int".  It will not be based on "long", unless 
using some unusual compiler extensions.  (In the AVR port of gcc, the 
usual <stdint.h> defines all the types as typedefs of "int" with gcc 
attributes to control the size.  I don't know why it does that, and I 
haven't seen it elsewhere.)

Sorry, I meant 'int_fast16_t' was defined as 'short' on mingw and 'long' 
on WSL.

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

#379471

FromDavid Brown <david.brown@hesbynett.no>
Date2023-11-03 10:33 +0100
Message-ID<ui2eq0$2no8u$1@dont-email.me>
In reply to#379466
On 02/11/2023 20:15, bart wrote:
> 
> On 02/11/2023 15:53, David Brown wrote:
>  > On 02/11/2023 15:07, bart wrote:
> 
>  >> So what were the reasons for Linux to use 64 bits for int_fast16_t 
> and Windows to use 32 bits?
>  >>
> 
>  >> So for both these cases, Windows' 32 bits make more sense than 64.
>  >>
>  >
>  > People who know far more about this than me, and even more than you 
> (I know you are more familiar with the details of x86-64 instructions 
> than I am), and who care about efficiency more than Microsoft (for whom 
> consistency with old flaws is more important than efficiency of new 
> systems), picked 8-byte types for the "fast" types on 64-bit systems.  I 
> am confident that they did so on more evidence and technical data than 
> we have here.
> 
> This is in line with my idea that using a 64-bit 'int' in C would have 
> been better, as discussed earlier in the year. As it is, 'int' is 
> usually 32 bits, and is still used extensively in programs rather than 
> explicitly requesting a 64-bit type.
> 

Yes.  I think you have some good arguments for 64-bit "int".  I think, 
however, the need for 8-bit, 16-bit, 32-bit and 64-bit sizes effectively 
rules that out for C - it seems no one wants to add extended integer 
types to make this work.  (I once saw an April Fool's proposal to add 
"long short int", "short long int", and endless combinations to C in 
order to generate types of any sizes.  But I can't find it at the moment.)

> It would eliminate a lot of problems, and perhaps fixed some of the 
> issues in the OP's program.
> 

True, but it would add many other challenges - not least of which no 
mainstream C compiler supports them.  "int64_t" and "uint64_t", however, 
/are/ well supported.

>  >
>  > Of course there will be situations when 32-bit types will be faster 
> than 64-bit types - such decisions are based on statistical information 
> and common patterns, and will never be perfect in all circumstances.
>  >
>  >> (If I look at the actual stdint.h for mingw, int16_t is just 
> 'short'. On my WSL, inside /usr/include/stdint.h, it is defined on top 
> of long, which may be 32 or 64 bits.)
>  >>
>  >
>  > "int16_t" must be exactly 16 bits, and many <stdint.h> files will 
> define it based on "short int".  It will not be based on "long", unless 
> using some unusual compiler extensions.  (In the AVR port of gcc, the 
> usual <stdint.h> defines all the types as typedefs of "int" with gcc 
> attributes to control the size.  I don't know why it does that, and I 
> haven't seen it elsewhere.)
> 
> Sorry, I meant 'int_fast16_t' was defined as 'short' on mingw and 'long' 
> on WSL.
> 

OK.

Of course, the <stdint.h> headers are tied tightly to the 
implementation, and are not intended to be portable across systems - the 
"mingw" folks know the size of "long" on their target and can rely on 
that.  They don't have to be concerned about it being 32-bit on some 
platforms and 64-bit on others.

The smarter thing to do, at least for GCC, is to use the built-in 
pre-defined types like "__INT_FAST16_TYPE__".  These are pre-defined by 
the compiler, precisely to make the implementation of <stdint.h> easy, 
reliable and portable across targets.

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

#379468

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2023-11-02 20:43 +0000
Message-ID<875y2jopi2.fsf@bsb.me.uk>
In reply to#379456
bart <bc@freeuk.com> writes:

> On 02/11/2023 09:52, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>>> On 31/10/2023 00:52, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> This has to be undefined behavior. Check it out:
>>>>>
>>>>> Here is my C code for a fun toy experimental fractal:
>>>>>
>>>>> https://pastebin.com/raw/fcV5YiJH
>>>>> (raw link to text...)
>>>> Ask your compiler for the maximum number of warnings and you should see
>>>> lots.  For some reason you are mixing types in a peculiar way, and since
>>>> some of those types often have different sizes you will get different
>>>> arithmetic results on different systems.
>>>>
>>>>> The cpack is different on the two different compilers. Oh, that is always
>>>>> fun!
>>>> You need to decide what integer types you really want.
>>>
>>> And the sane way to do that is to stick strictly to <stdint.h> types, so
>>> that the sizes are independent of the compiler and platform.
>> Hmm...  I would not want to say that exactly.  Firstly, it perpetuates
>> the misconception that stdint.h only defines the exact-width types
>> helping the world to forget about the [u]int_(least|fast)N_t types!
>
> Is that a bad thing?

Yes.

> I mean, which other current languages, other than C++, that have
> size-specific integer types, also have a set of 'least' and 'fast'
> versions?
>
> It doesn't seem to [be] something that the creators of other languages
> lose sleep over.

They don't seem to, no.  I wonder if the fact that C remains one of the
most widely used programming languages is in any way related to that.

> Those types appear to be relevant only to unusual architectures that only C
> bothers with.
>
>> Secondly, lots of algorithms can be written perfectly well using C's
>> ordinary types.  The key is to know what the type names mean.
>
> Not this one.

I am 100% sure that you don't know that to be the case.  Why?  Because I
am 100% sure that not even Chris knows what the actual algorithm is.
You may be right, and if anyone ever specifies the algorithm we may even
be able to determine the facts of the matter, but we can't do so now.

-- 
Ben.

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

#379469

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2023-11-02 13:47 -0700
Message-ID<ui11sr$2csu7$1@dont-email.me>
In reply to#379468
On 11/2/2023 1:43 PM, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
> 
>> On 02/11/2023 09:52, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 31/10/2023 00:52, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> This has to be undefined behavior. Check it out:
>>>>>>
>>>>>> Here is my C code for a fun toy experimental fractal:
>>>>>>
>>>>>> https://pastebin.com/raw/fcV5YiJH
>>>>>> (raw link to text...)
>>>>> Ask your compiler for the maximum number of warnings and you should see
>>>>> lots.  For some reason you are mixing types in a peculiar way, and since
>>>>> some of those types often have different sizes you will get different
>>>>> arithmetic results on different systems.
>>>>>
>>>>>> The cpack is different on the two different compilers. Oh, that is always
>>>>>> fun!
>>>>> You need to decide what integer types you really want.
>>>>
>>>> And the sane way to do that is to stick strictly to <stdint.h> types, so
>>>> that the sizes are independent of the compiler and platform.
>>> Hmm...  I would not want to say that exactly.  Firstly, it perpetuates
>>> the misconception that stdint.h only defines the exact-width types
>>> helping the world to forget about the [u]int_(least|fast)N_t types!
>>
>> Is that a bad thing?
> 
> Yes.
> 
>> I mean, which other current languages, other than C++, that have
>> size-specific integer types, also have a set of 'least' and 'fast'
>> versions?
>>
>> It doesn't seem to [be] something that the creators of other languages
>> lose sleep over.
> 
> They don't seem to, no.  I wonder if the fact that C remains one of the
> most widely used programming languages is in any way related to that.
> 
>> Those types appear to be relevant only to unusual architectures that only C
>> bothers with.
>>
>>> Secondly, lots of algorithms can be written perfectly well using C's
>>> ordinary types.  The key is to know what the type names mean.
>>
>> Not this one.
> 
> I am 100% sure that you don't know that to be the case.  Why?  Because I
> am 100% sure that not even Chris knows what the actual algorithm is.

Basically, my Funny Fractal Encryption is based on Julia sets. I was 
just poking around having fun wrt trying to use an escape time version 
as a form of encryption. So, there is no set algorithm. You are 
basically right.


http://funwithfractals.atspace.cc/ffe/

0.23046159622517684 0.3470667287528152
0.25771116242735903 0.10157512574580697

45 2F 4D 81 0F 38 05 2A 4C 8D A2 CB E8 4C 07 99 2A 82 CD CB 36 E6 E3 16 
7C 69 87 C3 81 2B E3 B6 76 C5 5B 7D F4 8E D0 23 8D 68 3E B4 49 FD FB 00 
95 2A 92 3F 48 F3 5C 36 F9 38 9D 72 4E 1E 06 32 0D 93 27 36 5A A0 C9 64 
86 71 DA CA 78 E3 02 71 B7 D0 39 18 77 59 E1 E1 EF 6D F1 4E AA 8C CE EE 
AC A0 CB 34 77 94 20 F6 0C 18 C5 A0 CF FE 1C E0 49 1E C8 92 6F B2 B3 42 
20 AD 7F 40 27 84 0C 40 80 75 D2 68 6E B7 89 3C D7 7C 7C D8 6C 84 3E 6C 
4D A3 0B 74 18 FC CE 09 91 54 86 F8 21 F9 00 68 B1 B7 67 29 4E 4A CD 16 
CF 1E 74 0E EF 79 FD 07 83 E1 93 0E 97 19 B6 64 85 C2 98 52 3D FA 71 DF 
61 DA 4E 7E 43 B0 17 E8 A1 07 9A 04 2E C5 B4 87 36 63 68 FE BC 35 82 77 
F5 30 B1 4C



> You may be right, and if anyone ever specifies the algorithm we may even
> be able to determine the facts of the matter, but we can't do so now.
>

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

#379458

FromDavid Brown <david.brown@hesbynett.no>
Date2023-11-02 13:34 +0100
Message-ID<ui050n$26ite$1@dont-email.me>
In reply to#379455
On 02/11/2023 10:52, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 31/10/2023 00:52, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> This has to be undefined behavior. Check it out:
>>>>
>>>> Here is my C code for a fun toy experimental fractal:
>>>>
>>>> https://pastebin.com/raw/fcV5YiJH
>>>> (raw link to text...)
>>> Ask your compiler for the maximum number of warnings and you should see
>>> lots.  For some reason you are mixing types in a peculiar way, and since
>>> some of those types often have different sizes you will get different
>>> arithmetic results on different systems.
>>>
>>>> The cpack is different on the two different compilers. Oh, that is always
>>>> fun!
>>> You need to decide what integer types you really want.
>>
>> And the sane way to do that is to stick strictly to <stdint.h> types, so
>> that the sizes are independent of the compiler and platform.
> 
> Hmm...  I would not want to say that exactly.  Firstly, it perpetuates
> the misconception that stdint.h only defines the exact-width types
> helping the world to forget about the [u]int_(least|fast)N_t types!

These could well have some use for code such as this (without having 
studied the code in detail).  Sometimes it makes sense to use the "fast" 
types for intermediary calculations - on x86-64 (at least on Linux), for 
example, the "int_fast32_t" type is 64 bit and can give noticeably more 
efficient code than "int32_t" or "int".

So I would not want to dismiss the "fast" types even though I think the 
main point here is to use the unsigned size-specific types to get the 
desired modulo effects in a platform-independent way.

(The "least" types are, I think, less useful for most code - they are 
only needed if you are targeting systems that might not have 8-bit or 
other power-of-two sized types, and even then they are only needed for 
arrays or larger storages.)

> Secondly, lots of algorithms can be written perfectly well using C's
> ordinary types.  The key is to know what the type names mean.
> 

You can always get by without the explicitly sized types.  But you'll 
typically either need to use explicit masks (like using "unsigned long" 
and masking with 0xffffffff to get the 32-bit modulo effects you want), 
or you'll end up duplicating the <stdint.h> exact size types using 
<limits.h>, conditional compilation and typedefs.  Your results will not 
be more portable (since any C compiler that supports "long long" will at 
least partially support C99, and it will have <stdint.h>).  The code 
will not be simpler or clearer, but will be inevitably be messier, and 
have a greater risk of errors (as seen in Chris' code).  And the code 
will not be more efficient, but could easily be less efficient - you can 
manually create the fixed-size types, assuming the platform supports 
them, but you can't create the "fast" types.

Of course you can do a lot of coding with the standard integer types, 
and of course knowing what the types mean is vital to this, especially 
for portable code.  But sometimes the <stdint.h> types are simply much 
better for the task in hand.

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

#379443

FromRichard Harnden <richard.nospam@gmail.invalid>
Date2023-11-01 20:32 +0000
Message-ID<uhuckk$1p9g6$1@dont-email.me>
In reply to#379401
On 30/10/2023 21:01, Chris M. Thomasson wrote:
> This has to be undefined behavior. Check it out:
> 
> Here is my C code for a fun toy experimental fractal:
> 
> https://pastebin.com/raw/fcV5YiJH
> (raw link to text...)
> 

Here's some clang weirdness ...

$ gcc --version
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: arm64-apple-darwin23.0.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

and:

$ gcc -std=c99 -pedantic -W -Wall -fsanitize=undefined -O2 -lm ffe.c
ffe.c:305:18: warning: taking the absolute value of unsigned type 
'unsigned int' has no effect [-Wabsolute-value]
             ec = abs(icount - ec);
                  ^
ffe.c:305:18: note: remove the call to 'abs' since unsigned values 
cannot be negative
             ec = abs(icount - ec);
                  ^~~
1 warning generated.

If you follow that advise, then it doesn't decrypt.

In fact, it doesn't decrypt in differennt ways depending on -On used.

(gcc proper doesn't complain about the abs)

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

#379447

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2023-11-01 21:36 +0000
Message-ID<87ttq5nokm.fsf@bsb.me.uk>
In reply to#379443
Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>> This has to be undefined behavior. Check it out:
>> Here is my C code for a fun toy experimental fractal:
>> https://pastebin.com/raw/fcV5YiJH
>> (raw link to text...)
>> 
>
> Here's some clang weirdness ...
>
> $ gcc --version
> Apple clang version 15.0.0 (clang-1500.0.40.1)
> Target: arm64-apple-darwin23.0.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> and:
>
> $ gcc -std=c99 -pedantic -W -Wall -fsanitize=undefined -O2 -lm ffe.c
> ffe.c:305:18: warning: taking the absolute value of unsigned type 'unsigned
> int' has no effect [-Wabsolute-value]
>             ec = abs(icount - ec);
>                  ^
> ffe.c:305:18: note: remove the call to 'abs' since unsigned values cannot be
> negative
>             ec = abs(icount - ec);
>                  ^~~
> 1 warning generated.
>
> If you follow that advise, then it doesn't decrypt.

That's "compiler" advice!  While icount - ec is indeed unsigned, the
conversion to int (the argument type of abs) is sometimes undefined due
to overflow.  So removing the call is fine in the eyes of a compiler
because the result will be the same in the defined cases and compilers
don't care about the undefined ones.

Apparently, the code relies on the undefined conversion.

> In fact, it doesn't decrypt in differennt ways depending on -On used.
>
> (gcc proper doesn't complain about the abs)

With lots of warnings turned on I get:

  321 |             ec = abs(icount - ec);
      |                             ^
cmt.c:321:18: warning: taking the absolute value of unsigned type ‘unsigned int’ has no effect [-Wabsolute-value]
  321 |             ec = abs(icount - ec);
      |                  ^~~
cmt.c:321:29: warning: conversion to ‘int’ from ‘unsigned int’ may change the sign of the result [-Wsign-conversion]
  321 |             ec = abs(icount - ec);
      |                      ~~~~~~~^~~~

I would have loved to have this level of warning when I was first using
C all those years ago.  And as for valgrind and -fsanitize=undefined, I
could only dream of such things.

-- 
Ben.

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

#379449

FromRichard Harnden <richard.nospam@gmail.invalid>
Date2023-11-01 21:54 +0000
Message-ID<uhuhf3$1q4ha$1@dont-email.me>
In reply to#379447
On 01/11/2023 21:36, Ben Bacarisse wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
> 
>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>>> This has to be undefined behavior. Check it out:
>>> Here is my C code for a fun toy experimental fractal:
>>> https://pastebin.com/raw/fcV5YiJH
>>> (raw link to text...)
>>>
>>
>> Here's some clang weirdness ...
>>
>> $ gcc --version
>> Apple clang version 15.0.0 (clang-1500.0.40.1)
>> Target: arm64-apple-darwin23.0.0
>> Thread model: posix
>> InstalledDir:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>>
>> and:
>>
>> $ gcc -std=c99 -pedantic -W -Wall -fsanitize=undefined -O2 -lm ffe.c
>> ffe.c:305:18: warning: taking the absolute value of unsigned type 'unsigned
>> int' has no effect [-Wabsolute-value]
>>              ec = abs(icount - ec);
>>                   ^
>> ffe.c:305:18: note: remove the call to 'abs' since unsigned values cannot be
>> negative
>>              ec = abs(icount - ec);
>>                   ^~~
>> 1 warning generated.
>>
>> If you follow that advise, then it doesn't decrypt.
> 
> That's "compiler" advice!  While icount - ec is indeed unsigned, the
> conversion to int (the argument type of abs) is sometimes undefined due
> to overflow.  So removing the call is fine in the eyes of a compiler
> because the result will be the same in the defined cases and compilers
> don't care about the undefined ones.
> 
> Apparently, the code relies on the undefined conversion.
> 
>> In fact, it doesn't decrypt in differennt ways depending on -On used.
>>
>> (gcc proper doesn't complain about the abs)
> 
> With lots of warnings turned on I get:
> 
>    321 |             ec = abs(icount - ec);
>        |                             ^
> cmt.c:321:18: warning: taking the absolute value of unsigned type ‘unsigned int’ has no effect [-Wabsolute-value]
>    321 |             ec = abs(icount - ec);
>        |                  ^~~
> cmt.c:321:29: warning: conversion to ‘int’ from ‘unsigned int’ may change the sign of the result [-Wsign-conversion]
>    321 |             ec = abs(icount - ec);
>        |                      ~~~~~~~^~~~
> 
> I would have loved to have this level of warning when I was first using
> C all those years ago.  And as for valgrind and -fsanitize=undefined, I
> could only dream of such things.
> 

-fsanitize=undefined has shown some of my 100% perfect programs to, in 
fact, be 99% fluke.

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

#379494

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2023-11-09 15:54 -0800
Message-ID<86r0kyzdm5.fsf@linuxsc.com>
In reply to#379447
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard Harnden <richard.nospam@gmail.invalid> writes:
>
>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>>
>>> https://pastebin.com/raw/fcV5YiJH
>>
>> $ gcc -std=c99 -pedantic -W -Wall -fsanitize=undefined -O2 -lm ffe.c

>> ffe.c:305:18: warning: taking the absolute value of unsigned type
>> 'unsigned int' has no effect [-Wabsolute-value]
>>             ec = abs(icount - ec);
>>                  ^
>> ffe.c:305:18: note:  remove the call to 'abs' since unsigned values
>> cannot be negative
>>             ec = abs(icount - ec);
>>                  ^~~
>> 1 warning generated.
>>
>> If you follow that advise, then it doesn't decrypt.
>
> That's "compiler" advice!  While icount - ec is indeed unsigned,
> the conversion to int (the argument type of abs) is sometimes
> undefined due to overflow.

Converting an unsigned int to int is implementation-defined, not
undefined.  (The C standard also allows an implementation-defined
signal to be raised, but it's unlikely either gcc or clang does
so.)

> So removing the call is fine in the eyes of a compiler because the
> result will be the same in the defined cases and compilers don't
> care about the undefined ones.

The compiler is giving stupid advice.  The result is defined in
all cases, except for when the (post-conversion) argument value
happens to be INT_MIN.  Unless the implementation-defined rule
for converting an unsigned int to an int is very strange,
removing the call changes the program's semantics.

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

#379492

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2023-11-09 01:16 -0800
Message-ID<uii823$24dtg$3@dont-email.me>
In reply to#379401
On 10/30/2023 2:01 PM, Chris M. Thomasson wrote:
> This has to be undefined behavior. Check it out:
> 
> Here is my C code for a fun toy experimental fractal:
> 
> https://pastebin.com/raw/fcV5YiJH
> (raw link to text...)[...]

I will get back into this, got caught up with some other work right now.

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

#379500

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2023-11-10 21:02 -0800
Message-ID<uin1sv$39gsb$1@dont-email.me>
In reply to#379401
On 10/30/2023 2:01 PM, Chris M. Thomasson wrote:
> This has to be undefined behavior. Check it out:
> 
> Here is my C code for a fun toy experimental fractal:
> 
> https://pastebin.com/raw/fcV5YiJH
> (raw link to text...)
[...]

I want to mix this into:

https://groups.google.com/g/comp.lang.c++/c/bB1wA4wvoFc/m/GdzmMd41AQAJ

Humm...

[toc] | [prev] | [standalone]

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

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

csiph-web