bart <bc@freeuk.com> writes:

> On 01/11/2023 00:39, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>
>>> No spec is given. But I would say one requirement is that encrypting and
>>> then decrypting a piece of plain text should produce the original
>>> text.
>>
>> I think we've ended up talking about different things. I've not seen
>> such a run. The OP posted two runs that both re-created the original
>> text, but which had different intermediate data.
>>
>
> Have you tried to run this program?

Yes.

> It produces 4 lots of output:
>
> * A big block of random text

I don't think it's random.

> * Some plaintext
>
> * The encrypted text
>
> * The decrypted text

And some other data. One of these is a number he calls cpack.

> The only results posted by the OP were /screenshots/ which showed /part/ of
> that first data block. One also shows a scroll-bar, but you can't click it -
> it's part of the image!

I don't follow links to images. I was going by what he posted here.
Two different run (from two different compilers) showing different value
of "cpack". This is a number that looks certain to depend on the width
of "unsigned long".

> So I don't know what you've seen.

I've seen what was posted here. I've not seen any linked images. I
don't know why people post images of text, but I don't mind because I
ignore such links anyway.

> I've also mentioned several times that I'm
> not just looking at discrepances within that data block across compilers,
> but differences and errors in those 3rd and 4th parts.

Yes, that's how I know were talking about different things.

--
Ben.

bart <bc@freeuk.com> writes:

> On 01/11/2023 00:44, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>
>>>> But the result is also undefined when mp_char does not occur in the
>>>> string which can happen for two printable ASCII characters.
>>>> Chris, you should test your code more thoroughly.
>>>
>>> Yup. This was quickly fleshed out a while back, and I recently got reminded
>>> if it. So, I ran it again, and noticed the inconsistent behavior between the
>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior in
>>> my code. So, yes, I agree with you, Ben. Big time.
>> I don't if you know what I'm talking about. Did you deliberately leave
>> out two printable ASCII characters from the alphabet?
>
> Might be helpful to mention that they are | and ".

Maybe, but the teacher in me won't go away, so I prefer point to the
problem rather than spell it out exactly.

--
Ben.

David Brown <david.brown@hesbynett.no> writes:

> On 01/11/2023 11:59, bart wrote:
>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>
>>>>> But the result is also undefined when mp_char does not occur in the
>>>>> string which can happen for two printable ASCII characters.
>>>>> Chris, you should test your code more thoroughly.
>>>>
>>>> Yup. This was quickly fleshed out a while back, and I recently got
>>>> reminded
>>>> if it. So, I ran it again, and noticed the inconsistent behavior between
>>>> the
>>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior
>>>> in
>>>> my code. So, yes, I agree with you, Ben. Big time.
>>>
>>> I don't if you know what I'm talking about.  Did you deliberately leave
>>> out two printable ASCII characters from the alphabet?
>>>
>> Might be helpful to mention that they are | and ".
>
> | and -, as far as I could see in a quick look at the code.

No, - is there but " is not. It's a slightly more subtle bug than just
"you have missing characters" which is why I wanted Chris to look for
himself.

> It seems bizarre to spell out lists of ASCII characters in the code rather
> than just a simple loop at runtime.

Sometimes the order matters, particularly in cryptological applications.
In this case I don't think is does though.

And if the order does not matter, then even a loop is unnecessary since
the string is used only to generate indexes into it. A simple x - ' '
gives the index of x in the list of "printable" ASCII characters.

--
Ben.

On 01/11/2023 14:52, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 01/11/2023 11:59, bart wrote:
>>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>>
>>>>>> But the result is also undefined when mp_char does not occur in the
>>>>>> string which can happen for two printable ASCII characters.
>>>>>> Chris, you should test your code more thoroughly.
>>>>>
>>>>> Yup. This was quickly fleshed out a while back, and I recently got
>>>>> reminded
>>>>> if it. So, I ran it again, and noticed the inconsistent behavior between
>>>>> the
>>>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior
>>>>> in
>>>>> my code. So, yes, I agree with you, Ben. Big time.
>>>>
>>>> I don't if you know what I'm talking about.  Did you deliberately leave
>>>> out two printable ASCII characters from the alphabet?
>>>>
>>> Might be helpful to mention that they are | and ".
>>
>> | and -, as far as I could see in a quick look at the code.
>
> No, - is there but " is not.

I've looked again, and you and Bart are correct.

> It's a slightly more subtle bug than just
> "you have missing characters" which is why I wanted Chris to look for
> himself.
>
>> It seems bizarre to spell out lists of ASCII characters in the code rather
>> than just a simple loop at runtime.
>
> Sometimes the order matters, particularly in cryptological applications.

I am immediately suspicious of any cryptography that is dependent on a
character set, never mind the order of it - it sounds fragile.
Cryptography that can't deal with arbitrary data hasn't been much use
since WWII.

(Order can matter in other applications.)

> In this case I don't think is does though.
>
> And if the order does not matter, then even a loop is unnecessary since
> the string is used only to generate indexes into it. A simple x - ' '
> gives the index of x in the list of "printable" ASCII characters.
>

I didn't look much at the rest of the code. (And is it turns out, I
didn't look very hard at the character lists either!)

On 11/1/2023 12:12 PM, David Brown wrote:
> On 01/11/2023 14:52, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 01/11/2023 11:59, bart wrote:
>>>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>>>
>>>>>>> But the result is also undefined when mp_char does not occur in the
>>>>>>> string which can happen for two printable ASCII characters.
>>>>>>> Chris, you should test your code more thoroughly.
>>>>>>
>>>>>> Yup. This was quickly fleshed out a while back, and I recently got
>>>>>> reminded
>>>>>> if it. So, I ran it again, and noticed the inconsistent behavior
>>>>>> between
>>>>>> the
>>>>>> two compilers, (MSVC and GCC). This has to be due to undefined
>>>>>> behavior
>>>>>> in
>>>>>> my code. So, yes, I agree with you, Ben. Big time.
>>>>>
>>>>> I don't if you know what I'm talking about.  Did you deliberately
>>>>> leave
>>>>> out two printable ASCII characters from the alphabet?
>>>>>
>>>> Might be helpful to mention that they are | and ".
>>>
>>> | and -, as far as I could see in a quick look at the code.
>>
>> No, - is there but " is not.
>
> I've looked again, and you and Bart are correct.
>
>> It's a slightly more subtle bug than just
>> "you have missing characters" which is why I wanted Chris to look for
>> himself.
>>
>>> It seems bizarre to spell out lists of ASCII characters in the code
>>> rather
>>> than just a simple loop at runtime.
>>
>> Sometimes the order matters, particularly in cryptological applications.
>
> I am immediately suspicious of any cryptography that is dependent on a
> character set, never mind the order of it - it sounds fragile.
> Cryptography that can't deal with arbitrary data hasn't been much use
> since WWII.

Never use this funny toy of mine, (Funny Fractal Encryption (FFE)) as a
real encryption implement, NEVER! It was for fun, not for serious work
at all. Now, I do have an experimental encryption that I think can
potentially be used. Have you seen this before?

https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ

Fwiw, here is a hyper crude write up I did:

http://funwithfractals.atspace.cc/ct_cipher

What do you think? Crap, or kind of crap?

;^)

Fwiw, here is an online version of it:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/

Here is a message encrypted using the default key, for all of us to see:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=38e1fedde4d299752a59ed9d3194cbee57d335ad7f293865db2018c5594f783b087464ab88d3a9db11861ad37eb9f00a6c900a00043348ba7d6ac1d41933c6db0bd53cc0f4b8de9eb589ea745f1639c7358a3e5052c164b7268a31d075f0afb4121ec509

>
> (Order can matter in other applications.)
>
>> In this case I don't think is does though.
>>
>> And if the order does not matter, then even a loop is unnecessary since
>> the string is used only to generate indexes into it.  A simple x - ' '
>> gives the index of x in the list of "printable" ASCII characters.
>>
>
> I didn't look much at the rest of the code.  (And is it turns out, I
> didn't look very hard at the character lists either!)
>

On 11/1/2023 6:29 AM, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 01/11/2023 00:39, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>
>>>> No spec is given. But I would say one requirement is that encrypting and
>>>> then decrypting a piece of plain text should produce the original
>>>> text.
>>>
>>> I think we've ended up talking about different things. I've not seen
>>> such a run. The OP posted two runs that both re-created the original
>>> text, but which had different intermediate data.
>>>
>>
>> Have you tried to run this program?
>
> Yes.
>
>> It produces 4 lots of output:
>>
>> * A big block of random text
>
> I don't think it's random.

It is not random at all! NOPE.

>
>> * Some plaintext
>>
>> * The encrypted text
>>
>> * The decrypted text
>
> And some other data. One of these is a number he calls cpack.
>
>> The only results posted by the OP were /screenshots/ which showed /part/ of
>> that first data block. One also shows a scroll-bar, but you can't click it -
>> it's part of the image!
>
> I don't follow links to images. I was going by what he posted here.
> Two different run (from two different compilers) showing different value
> of "cpack". This is a number that looks certain to depend on the width
> of "unsigned long".
>
>> So I don't know what you've seen.
>
> I've seen what was posted here. I've not seen any linked images. I
> don't know why people post images of text, but I don't mind because I
> ignore such links anyway.
>
>> I've also mentioned several times that I'm
>> not just looking at discrepances within that data block across compilers,
>> but differences and errors in those 3rd and 4th parts.
>
> Yes, that's how I know were talking about different things.
>

On 11/1/2023 6:43 AM, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>
>>>>> But the result is also undefined when mp_char does not occur in the
>>>>> string which can happen for two printable ASCII characters.
>>>>> Chris, you should test your code more thoroughly.
>>>>
>>>> Yup. This was quickly fleshed out a while back, and I recently got reminded
>>>> if it. So, I ran it again, and noticed the inconsistent behavior between the
>>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior in
>>>> my code. So, yes, I agree with you, Ben. Big time.
>>> I don't if you know what I'm talking about. Did you deliberately leave
>>> out two printable ASCII characters from the alphabet?
>>
>> Might be helpful to mention that they are | and ".
>
> Maybe, but the teacher in me won't go away, so I prefer point to the
> problem rather than spell it out exactly.
>

Thank you for the teacher in you. I think this boils down to a floating
point issue in one of my fun toys.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 11/1/2023 6:43 AM, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>>
>>>>>> But the result is also undefined when mp_char does not occur in the
>>>>>> string which can happen for two printable ASCII characters.
>>>>>> Chris, you should test your code more thoroughly.
>>>>>
>>>>> Yup. This was quickly fleshed out a while back, and I recently got reminded
>>>>> if it. So, I ran it again, and noticed the inconsistent behavior between the
>>>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior in
>>>>> my code. So, yes, I agree with you, Ben. Big time.
>>>> I don't if you know what I'm talking about. Did you deliberately leave
>>>> out two printable ASCII characters from the alphabet?
>>>
>>> Might be helpful to mention that they are | and ".
>> Maybe, but the teacher in me won't go away, so I prefer point to the
>> problem rather than spell it out exactly.
>
> Thank you for the teacher in you. I think this boils down to a floating
> point issue in one of my fun toys.

What is "this"? The "this" I am talking about has nothing to do with
floating point arithmetic. It's a simple matter of forgetting about |
and " when you drew up the alphabet.

--
Ben.

On 11/1/2023 1:08 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 11/1/2023 6:43 AM, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>>>
>>>>>>> But the result is also undefined when mp_char does not occur in the
>>>>>>> string which can happen for two printable ASCII characters.
>>>>>>> Chris, you should test your code more thoroughly.
>>>>>>
>>>>>> Yup. This was quickly fleshed out a while back, and I recently got reminded
>>>>>> if it. So, I ran it again, and noticed the inconsistent behavior between the
>>>>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior in
>>>>>> my code. So, yes, I agree with you, Ben. Big time.
>>>>> I don't if you know what I'm talking about. Did you deliberately leave
>>>>> out two printable ASCII characters from the alphabet?
>>>>
>>>> Might be helpful to mention that they are | and ".
>>> Maybe, but the teacher in me won't go away, so I prefer point to the
>>> problem rather than spell it out exactly.
>>
>> Thank you for the teacher in you. I think this boils down to a floating
>> point issue in one of my fun toys.
>
> What is "this"? The "this" I am talking about has nothing to do with
> floating point arithmetic. It's a simple matter of forgetting about |
> and " when you drew up the alphabet.
>

I am still wondering why I get two different cpack outputs using
different compilers (GCC vs. MSVC) with the code as is.

756768

vs:

95375807

Almost has to be a floating point issue? Or some undefined behavior I
overlooked?

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)

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 11/1/2023 1:08 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 11/1/2023 6:43 AM, Ben Bacarisse wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>>
>>>>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>> But the result is also undefined when mp_char does not occur in the
>>>>>>>> string which can happen for two printable ASCII characters.
>>>>>>>> Chris, you should test your code more thoroughly.
>>>>>>>
>>>>>>> Yup. This was quickly fleshed out a while back, and I recently got reminded
>>>>>>> if it. So, I ran it again, and noticed the inconsistent behavior between the
>>>>>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior in
>>>>>>> my code. So, yes, I agree with you, Ben. Big time.
>>>>>> I don't if you know what I'm talking about. Did you deliberately leave
>>>>>> out two printable ASCII characters from the alphabet?
>>>>>
>>>>> Might be helpful to mention that they are | and ".
>>>> Maybe, but the teacher in me won't go away, so I prefer point to the
>>>> problem rather than spell it out exactly.
>>>
>>> Thank you for the teacher in you. I think this boils down to a floating
>>> point issue in one of my fun toys.
>> What is "this"? The "this" I am talking about has nothing to do with
>> floating point arithmetic. It's a simple matter of forgetting about |
>> and " when you drew up the alphabet.
>
> I am still wondering why I get two different cpack outputs using different
> compilers (GCC vs. MSVC) with the code as is.

So talk about that in the sub-thread that is about exactly that topic.
If you post a reply to a message about missing characters -- even if the
wider thread also included talk of other things -- you should be talking
about missing characters.

And, especially, if you use words like "this" and "it" they should
relate to the immediate topic, not something else in previous posts or
other parts of the thread.

> 756768
>
> vs:
>
> 95375807
>
> Almost has to be a floating point issue? Or some undefined behavior I
> overlooked?

Well, in a post in reply to Bart, I gave some information about that so
now I'm going to mess up this sub thread by going back to it...

The code that calculates cpack mixes unsigned int and unsigned long int
arithmetic. On Windows, unsigned long int is 32 bits, but it's usually
64 bits on Linux. There seems to be no logic behind this mixing, but
you won't get the same result with different sized integer types.

The situation is made worse by using floating point to halve an integer
quantity (in cantor_packing). In effect, that introduces a 52-bit
integer type into the mix as well.

To cap it all, CT_FFE_ABET_LOOKUP is of type ptrdiff_t -- a /signed/
integer type whose size can vary between systems.

It would be almost impossible to state, mathematically, what cpack's
value "should" be. The value is derived from a chaotic mix of wrapping
between 32 and sometimes 64 bit values as well as rounding to 52 bits of
accuracy.

Even the simple cantor_packing function relies on wrapping and/or
rounding to give a result that is not mathematically correct.

Since you rely on unsigned arithmetic being modular, the only way you'll
get the same result for cpack on all systems is to specify exactly what
arithmetic you want. The crude way is to use integer types with
specified sizes, avoid signed integer types and replace "0.5*..." with
with ".../2".

--
Ben.

On 11/1/2023 2:12 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 11/1/2023 1:08 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 11/1/2023 6:43 AM, Ben Bacarisse wrote:
>>>>> bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 01/11/2023 00:44, Ben Bacarisse wrote:
>>>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>>>
>>>>>>>> On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>>>> But the result is also undefined when mp_char does not occur in the
>>>>>>>>> string which can happen for two printable ASCII characters.
>>>>>>>>> Chris, you should test your code more thoroughly.
>>>>>>>>
>>>>>>>> Yup. This was quickly fleshed out a while back, and I recently got reminded
>>>>>>>> if it. So, I ran it again, and noticed the inconsistent behavior between the
>>>>>>>> two compilers, (MSVC and GCC). This has to be due to undefined behavior in
>>>>>>>> my code. So, yes, I agree with you, Ben. Big time.
>>>>>>> I don't if you know what I'm talking about. Did you deliberately leave
>>>>>>> out two printable ASCII characters from the alphabet?
>>>>>>
>>>>>> Might be helpful to mention that they are | and ".
>>>>> Maybe, but the teacher in me won't go away, so I prefer point to the
>>>>> problem rather than spell it out exactly.
>>>>
>>>> Thank you for the teacher in you. I think this boils down to a floating
>>>> point issue in one of my fun toys.
>>> What is "this"? The "this" I am talking about has nothing to do with
>>> floating point arithmetic. It's a simple matter of forgetting about |
>>> and " when you drew up the alphabet.
>>
>> I am still wondering why I get two different cpack outputs using different
>> compilers (GCC vs. MSVC) with the code as is.
>
> So talk about that in the sub-thread that is about exactly that topic.
> If you post a reply to a message about missing characters -- even if the
> wider thread also included talk of other things -- you should be talking
> about missing characters.
>
> And, especially, if you use words like "this" and "it" they should
> relate to the immediate topic, not something else in previous posts or
> other parts of the thread.
>
>> 756768
>>
>> vs:
>>
>> 95375807
>>
>> Almost has to be a floating point issue? Or some undefined behavior I
>> overlooked?
>
> Well, in a post in reply to Bart, I gave some information about that so
> now I'm going to mess up this sub thread by going back to it...
>
> The code that calculates cpack mixes unsigned int and unsigned long int
> arithmetic. On Windows, unsigned long int is 32 bits, but it's usually
> 64 bits on Linux. There seems to be no logic behind this mixing, but
> you won't get the same result with different sized integer types.
>
> The situation is made worse by using floating point to halve an integer
> quantity (in cantor_packing). In effect, that introduces a 52-bit
> integer type into the mix as well.
>
> To cap it all, CT_FFE_ABET_LOOKUP is of type ptrdiff_t -- a /signed/
> integer type whose size can vary between systems.
>
> It would be almost impossible to state, mathematically, what cpack's
> value "should" be. The value is derived from a chaotic mix of wrapping
> between 32 and sometimes 64 bit values as well as rounding to 52 bits of
> accuracy.
>
> Even the simple cantor_packing function relies on wrapping and/or
> rounding to give a result that is not mathematically correct.
>
> Since you rely on unsigned arithmetic being modular, the only way you'll
> get the same result for cpack on all systems is to specify exactly what
> arithmetic you want. The crude way is to use integer types with
> specified sizes, avoid signed integer types and replace "0.5*..." with
> with ".../2".
>

Agreed. However, that would take the funny part out of it...

;^)

On 11/1/2023 6:29 AM, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 01/11/2023 00:39, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>
>>>> No spec is given. But I would say one requirement is that encrypting and
>>>> then decrypting a piece of plain text should produce the original
>>>> text.
>>>
>>> I think we've ended up talking about different things. I've not seen
>>> such a run. The OP posted two runs that both re-created the original
>>> text, but which had different intermediate data.
>>>
>>
>> Have you tried to run this program?
>
> Yes.
>
>> It produces 4 lots of output:
>>
>> * A big block of random text
>
> I don't think it's random.
>
>> * Some plaintext
>>
>> * The encrypted text
>>
>> * The decrypted text
>
> And some other data. One of these is a number he calls cpack.
>
>> The only results posted by the OP were /screenshots/ which showed /part/ of
>> that first data block. One also shows a scroll-bar, but you can't click it -
>> it's part of the image!
>
> I don't follow links to images. I was going by what he posted here.
> Two different run (from two different compilers) showing different value
> of "cpack". This is a number that looks certain to depend on the width
> of "unsigned long".
>
>> So I don't know what you've seen.
>
> I've seen what was posted here. I've not seen any linked images. I
> don't know why people post images of text, but I don't mind because I
> ignore such links anyway.
>
>> I've also mentioned several times that I'm
>> not just looking at discrepances within that data block across compilers,
>> but differences and errors in those 3rd and 4th parts.
>
> Yes, that's how I know were talking about different things.
>

Fwiw, here is an fun online version of it:

http://funwithfractals.atspace.cc/ffe

0.3890382556464768 0.4591590239305639
0.2729659079628294 0.2743403616928193

D2 6D 58 D4 6B C8 7D 7E CA B3 68 34 2C A6 23 AB 2F B5 8F 3F 6B 24

Copy and replace the contents of the ciphertext box with the copied
ciphertext in this message, click decrypt. It should work, the funny
part is if it cannot work between certain browsers! lol.

Fwiw, here is a screen shot of what I get:

https://i.ibb.co/jWnb7hp/image.png

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.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

>>> Almost has to be a floating point issue? Or some undefined behavior I
>>> overlooked?
>> Well, in a post in reply to Bart, I gave some information about that so
>> now I'm going to mess up this sub thread by going back to it...
>> The code that calculates cpack mixes unsigned int and unsigned long int
>> arithmetic. On Windows, unsigned long int is 32 bits, but it's usually
>> 64 bits on Linux. There seems to be no logic behind this mixing, but
>> you won't get the same result with different sized integer types.
>> The situation is made worse by using floating point to halve an integer
>> quantity (in cantor_packing). In effect, that introduces a 52-bit
>> integer type into the mix as well.
>> To cap it all, CT_FFE_ABET_LOOKUP is of type ptrdiff_t -- a /signed/
>> integer type whose size can vary between systems.
>> It would be almost impossible to state, mathematically, what cpack's
>> value "should" be. The value is derived from a chaotic mix of wrapping
>> between 32 and sometimes 64 bit values as well as rounding to 52 bits of
>> accuracy.
>> Even the simple cantor_packing function relies on wrapping and/or
>> rounding to give a result that is not mathematically correct.
>> Since you rely on unsigned arithmetic being modular, the only way you'll
>> get the same result for cpack on all systems is to specify exactly what
>> arithmetic you want. The crude way is to use integer types with
>> specified sizes, avoid signed integer types and replace "0.5*..." with
>> with ".../2".
>
> Agreed. However, that would take the funny part out of it...
>
> ;^)

Ah, sorry. I thought you wanted to fix the code. I'll stick to
answering your questions literally!

>>> Almost has to be a floating point issue?

No, not here.

>>> Or some undefined behavior I overlooked?

No, not here, though there is plenty of undefined behaviour elsewhere.

--
Ben.

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.

On 01/11/2023 20:12, Chris M. Thomasson wrote:
> On 11/1/2023 1:08 PM, Ben Bacarisse wrote:

> I am still wondering why I get two different cpack outputs using
different compilers (GCC vs. MSVC) with the code as is.
>
> 756768
>
> vs:
>
> 95375807
>
> Almost has to be a floating point issue? Or some undefined behavior I
overlooked?

I had trouble getting four compilers to give different cpack values,
although they sometimes diverged later especially using float rather
than double.

I did see a consistent difference on cpack with lccwin32 (32-bits)
though. (Note that at this point I am using u64 not 'unsigned long'.)

Tracing it through, the culprit is likely to be the cantor_packing
function. If I extract into this test program:

#include <stdio.h>

typedef unsigned long long u64;

u64 cantor_packing(unsigned int n0, unsigned int n1) {
u64 ret = 0.5 * (n0 + n1) * (n0 + n1 + 1) + n1;

printf("%f\n", (double)(n0+n1));
printf("%f\n", 0.5*(n0+n1));
printf("%f\n", 0.5*(n0+n1)*(n0+n1+1));
printf("%f\n", 0.5*(n0+n1)*(n0+n1+1)+n1);

return ret;
}

int main(void) {
u64 a;

a=cantor_packing(3557082894, 3037);
printf("%llu", a);
}

Then, ignoring those first printfs for now, all 4 compilers give the
same final result execpt lccwin32. But with those printfs in place,
there is some divergence:

c:\c>mcc d.c && d
Compiling d.c to d.exe
3557085931.000000
1778542965.500000
6326430162037611500.000000
6326430162037614600.000000
6326430162037614592

c:\c>tcc d.c && d
3557085931.000000
1778542965.500000
6326430162037611500.000000
6326430162037614600.000000
6326430162037614592

c:\c>gcc d.c && a
3557085931.000000
1778542965.500000
6326430162037611520.000000
6326430162037614592.000000
6326430162037614592

c:\c>\lcc\bin\lc d.c && d
3557085931.000000
1778542965.500000
6326430162037611500.000000
6326430162037614600.000000
6326430162037614383

Based on the last value, 1,2,3 give the same result and 4 is different.
Based on those intermediates, 1,2 and 4 are the same, and 3 is different.

So the interaction between the 0.5 (which presumably is 'double'), and
those u32 values and u64 result causes problems.

I don't know whether f64*u32*u32 does f64*u32 first or u32*u32. But I
think that either way, the 52-bit integer accuracy of f64 may be
breached at some point.

The funny thing is, the exact result of tha expression inside
cantor_packing using the given values is:

6326430162037614383

(About 1000 times bigger than 52 bits). Only lccwin32 gets it exactly
right, all the others get it wrong!

If I change the function to avoid floating point:

#include <stdio.h>

typedef unsigned long long u64;

u64 cantor_packing(unsigned int n0, unsigned int n1) {
u64 ret = (n0 + n1) * (n0 + n1 + 1)/2 + n1;
return ret;
}

int main(void) {
u64 a;

a=cantor_packing(3557082894, 3037);
printf("%llu", a);
}

Then the behaviour is more consistent:

c:\c>mcc d.c && d
Compiling d.c to d.exe
680634159

c:\c>tcc d.c && d
680634159

c:\c>gcc d.c && a
680634159

c:\c>\lcc\bin\lc d.c && d
680634159

However the result is 'wrong' as evaluation is done as u32 not u64.
Changing the parameters to u64 (why does anyone still bother with 32
bits?) yields the above result of 6326430162037614383 in all four cases.

On 11/1/2023 2:43 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>>>> Almost has to be a floating point issue? Or some undefined behavior I
>>>> overlooked?
>>> Well, in a post in reply to Bart, I gave some information about that so
>>> now I'm going to mess up this sub thread by going back to it...
>>> The code that calculates cpack mixes unsigned int and unsigned long int
>>> arithmetic. On Windows, unsigned long int is 32 bits, but it's usually
>>> 64 bits on Linux. There seems to be no logic behind this mixing, but
>>> you won't get the same result with different sized integer types.
>>> The situation is made worse by using floating point to halve an integer
>>> quantity (in cantor_packing). In effect, that introduces a 52-bit
>>> integer type into the mix as well.
>>> To cap it all, CT_FFE_ABET_LOOKUP is of type ptrdiff_t -- a /signed/
>>> integer type whose size can vary between systems.
>>> It would be almost impossible to state, mathematically, what cpack's
>>> value "should" be. The value is derived from a chaotic mix of wrapping
>>> between 32 and sometimes 64 bit values as well as rounding to 52 bits of
>>> accuracy.
>>> Even the simple cantor_packing function relies on wrapping and/or
>>> rounding to give a result that is not mathematically correct.
>>> Since you rely on unsigned arithmetic being modular, the only way you'll
>>> get the same result for cpack on all systems is to specify exactly what
>>> arithmetic you want. The crude way is to use integer types with
>>> specified sizes, avoid signed integer types and replace "0.5*..." with
>>> with ".../2".
>>
>> Agreed. However, that would take the funny part out of it...
>>
>> ;^)
>
> Ah, sorry. I thought you wanted to fix the code. I'll stick to
> answering your questions literally!

I might have some time tonight to work on it again.

>
>>>> Almost has to be a floating point issue?
>
> No, not here.
>
>>>> Or some undefined behavior I overlooked?
>
> No, not here, though there is plenty of undefined behaviour elsewhere.
>

On 01/11/2023 20:52, Chris M. Thomasson wrote:
> On 11/1/2023 12:12 PM, David Brown wrote:

>> I am immediately suspicious of any cryptography that is dependent on a
>> character set, never mind the order of it - it sounds fragile.
>> Cryptography that can't deal with arbitrary data hasn't been much use
>> since WWII.
>
> Never use this funny toy of mine, (Funny Fractal Encryption (FFE)) as a
> real encryption implement, NEVER! It was for fun, not for serious work
> at all. Now, I do have an experimental encryption that I think can
> potentially be used. Have you seen this before?
>
> https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ
>
> Fwiw, here is a hyper crude write up I did:
>
> http://funwithfractals.atspace.cc/ct_cipher
>
> What do you think? Crap, or kind of crap?
>
> ;^)
>

I am not a cryptography expert, but I am leaning towards the first
choice :-) I realise it is "pre-alpha version 0.0.0", and more playing
with ideas than serious encryption. But I can give you a couple of
points and suggestions, which might be of use to you.

First, cryptography is mathematics. It makes things clearer if your
algorithms are written mathematically. The algorithms are not code -
they are maths, and good typography and good naming in maths is
different from good layout and good naming in programming. And clear
expressions are much better than descriptions in text.

So don't write
Set I_P is used as an index for P, set it to zero.

Prefer
iₚ ← 0

(Use the best layout tools you are familiar with - raw html, LaTeX,
LibreOffice's formula editors, whatever.)

Don't think in C - think in mathematics. So don't invent arrays and
variables and change them, but write expressions and name them - then
leave them unchanged. Rather than "Prepend R to P", write "Pʹ ← R ++ P"
and introduce a new name. It is /hugely/ easier to comprehend the
algorithm, and prove its correctness and other features, when you do this.

Then there are some basic cryptography rules. Your main hash algorithm
has a certain size of output, such as 32-byte (for SHA-256). There is
then no point in using a key that has more than 256 bits of entropy, nor
is there any point in using random salt with more entropy than that -
you are simply guaranteeing duplications. If the key is expected to be
plain text that people can remember, then it needs to be much longer to
get 256 bits of entropy (you use a long low-entropy text, then run it
though a secure hash to get a condensed key with high relative entropy).

As far as I can tell, the guts of your idea is that you are doing a
sliding xor encryption but changing that encryption key as you go along,
based on feeding the message into a hash function. It's an interesting
idea, but I don't think it is actually a good thing - I suspect it
actually decreases the effectiveness of the encryption, and my gut
feeling is that carefully crafted plain texts can be used as an attack
to get the encryption key out. But you'd be better asking a real
cryptologist about that.

Don't let that stop you playing around with these, however - there's
always fun to be had with this kind of thing.

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.

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!
Secondly, lots of algorithms can be written perfectly well using C's
ordinary types. The key is to know what the type names mean.

--
Ben.

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?

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 something that the creators of other languages lose
sleep over.

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. 'int' might be 16 bits or 32 bits or 64 or anything above
16, but is likely to be 32 bits or typical platforms.

'long' might be 32 bits or more, and /is/ commonly either 32 bits or 64
bits even on Linux.

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.

On 02/11/2023 12:31, bart wrote:
> 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?
>
> 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 something that the creators of other languages lose
> sleep over.
>
> Those types appear to be relevant only to unusual architectures that
> only C bothers with.
>

Like x86-64 ?

I don't see any use of the "least" types, except on unusual
architectures that don't support all of the common 8-bit, 16-bit, 32-bit
and 64-bit types. It's a good thing that C supports these
architectures, because while some of these are outdated and of
historical interest only, others are valid, active and popular within
their niche markets. It is understandable that most languages don't
support them, but good that C does.

The "fast" types are more useful. They can be very helpful when making
code that works well across different target sizes, as is very common in
libraries for embedded development, reducing or avoiding the mess of
"port" includes and library-specific type names. And on bigger systems,
such as normal PC's, they give you more efficient code while saying
explicitly what you are looking for in the type.

So on x86-64 for Linux, "int_fast16_t" and "int_fast32_t" are both
64-bit. On x86-64 for Windows, since Windows always likes to be
different from everyone else, "int_fast16_t" and "int_fast32_t" are both
32-bit. "int8_t" is 8-bit on both systems.

>> 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. 'int' might be 16 bits or 32 bits or 64 or anything above
> 16, but is likely to be 32 bits or typical platforms.
>
> 'long' might be 32 bits or more, and /is/ commonly either 32 bits or 64
> bits even on Linux.
>

On 02/11/2023 12:52, David Brown wrote:
> On 02/11/2023 12:31, bart wrote:

>> Is that a bad thing?
>>
>> 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 something that the creators of other languages
lose sleep over.
>>
>> Those types appear to be relevant only to unusual architectures that
only C bothers with.
>>
>
> Like x86-64 ?
>
> I don't see any use of the "least" types, except on unusual
architectures that don't support all of the common 8-bit, 16-bit, 32-bit
and 64-bit types. It's a good thing that C supports these
architectures, because while some of these are outdated and of
historical interest only, others are valid, active and popular within
their niche markets. It is understandable that most languages don't
support them, but good that C does.
>
> The "fast" types are more useful. They can be very helpful when
making code that works well across different target sizes, as is very
common in libraries for embedded development, reducing or avoiding the
mess of "port" includes and library-specific type names. And on bigger
systems, such as normal PC's, they give you more efficient code while
saying explicitly what you are looking for in the type.
>
> So on x86-64 for Linux, "int_fast16_t" and "int_fast32_t" are both
64-bit. On x86-64 for Windows, since Windows always likes to be
different from everyone else, "int_fast16_t" and "int_fast32_t" are both
32-bit.

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

If I wanted an array of 100M int_fast16_t types, I would guess that an
actual 16-bit type is faster than either 32 or 64 bits because it uses a
lot less memory.

But for individual calculations, both 16-bit and 64-bit instructions
frequently need an extra prefix byte over 32 bits. This is not
necessarily faster, but overall there will be less code.

So for both these cases, Windows' 32 bits make more sense than 64.

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