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

The cpack is different on the two different compilers. Oh, that is
always fun! Interesting. Here are some screenshots:

Online:

https://i.ibb.co/7n0wdWv/image.png

Notice cpack at 756768?

And on MSVC ver: 4.8.09032:

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

cpack is at 95375807?

Interesting!

When you get some free time, can you compile and run my C code and
report the output? Thanks everybody.

:^)

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...)
>
> The cpack is different on the two different compilers. Oh, that is
> always fun! Interesting. Here are some screenshots:
>
> Online:
>
> https://i.ibb.co/7n0wdWv/image.png
>
> Notice cpack at 756768?
>
> And on MSVC ver: 4.8.09032:
>
> https://i.ibb.co/Pj0QZLf/image.png
>
> cpack is at 95375807?
>
> Interesting!
>
> When you get some free time, can you compile and run my C code and
> report the output? Thanks everybody.
>
> :^)

Fwiw, here is an online version of it:

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

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...)
>
> The cpack is different on the two different compilers. Oh, that is
> always fun! Interesting. Here are some screenshots:
>
> Online:
>
> https://i.ibb.co/7n0wdWv/image.png
>
> Notice cpack at 756768?
[...]

This is a little bugger!

main.c: In function ‘ct_ffe_gen_private_key’:
main.c:358:22: warning: format ‘%u’ expects argument of type ‘unsigned
int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
358 | printf("cpack = %u\r\n", cpack);

On 30/10/2023 21:30, Chris M. Thomasson wrote:
> 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...)
>>
>> The cpack is different on the two different compilers. Oh, that is
>> always fun! Interesting. Here are some screenshots:
>>
>> Online:
>>
>> https://i.ibb.co/7n0wdWv/image.png
>>
>> Notice cpack at 756768?
> [...]
>
> This is a little bugger!
>
> main.c: In function ‘ct_ffe_gen_private_key’:
> main.c:358:22: warning: format ‘%u’ expects argument of type ‘unsigned
> int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
>   358 |     printf("cpack = %u\r\n", cpack);
>

That's just %lu, surely?

Do you need all those \r\n's? Doesn't the end of line conversion happen
automatically?

On 10/30/2023 3:01 PM, Richard Harnden wrote:
> On 30/10/2023 21:30, Chris M. Thomasson wrote:
>> 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...)
>>>
>>> The cpack is different on the two different compilers. Oh, that is
>>> always fun! Interesting. Here are some screenshots:
>>>
>>> Online:
>>>
>>> https://i.ibb.co/7n0wdWv/image.png
>>>
>>> Notice cpack at 756768?
>> [...]
>>
>> This is a little bugger!
>>
>> main.c: In function ‘ct_ffe_gen_private_key’:
>> main.c:358:22: warning: format ‘%u’ expects argument of type ‘unsigned
>> int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
>>    358 |     printf("cpack = %u\r\n", cpack);
>>
>
> That's just %lu, surely?

Yes. However, I am still getting different cpad results on two different
compilers. So, I need to find some time today or tommorrow to address that.

> Do you need all those \r\n's?  Doesn't the end of line conversion happen
> automatically?

Well, now that I think about this older code, I had HTTP protocol on the
mind during quickly fleshing it out. \r\n\r\n

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...)
>
> The cpack is different on the two different compilers. Oh, that is
> always fun! Interesting. Here are some screenshots:
>
> Online:
>
> https://i.ibb.co/7n0wdWv/image.png
>
> Notice cpack at 756768?
>
> And on MSVC ver: 4.8.09032:
>
> https://i.ibb.co/Pj0QZLf/image.png
>
> cpack is at 95375807?
>
> Interesting!
>
> When you get some free time, can you compile and run my C code and
> report the output? Thanks everybody.
>
> :^)

I tweaked the source code (used explicit assignment to fields of some
structs) to be able to use my compilers.

Then I tried these compilers:

gcc 13.2.0 - this worked. (I assume it is supposed to show some
plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
CAPNKUfB...", then the identical plaintext)

tcc - failed. The encrypted text started
"xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
"dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."

gcc/clang on rextester.com - passed (they share the same encrypted text;
it is different from gcc on my Windows machine, but matches that of gcc
under WSL on my machine.).

mcc (my new compiler) - passed, encrypted text matches gcc's.

bcc (my old compiler) - failed, encrypted text started
"z\n:`#-}9tYq,VcI?4aHN_rgCXhy&A'/:am..."

lccwin32 - the result was ... interesting. The decrypted text matched
the original exactly, which is good. But the encrypted text was
"AAAAAAAAAAAAAAAAA...".

I noticed it uses floating point and sin/cos functions. If I change
double to float, the ones that work still work, but the encrypted data
is different between mcc and gcc. The ones that don't work still don't.

Note: I ran the program in your first link, where the input data is
repetitions of your name. I couldn't see any relevance to your posted
screen shots.

On 30/10/2023 23:22, bart wrote:
> On 30/10/2023 21:01, Chris M. Thomasson wrote:

> gcc/clang on rextester.com - passed (they share the same encrypted text;
> it is different from gcc on my Windows machine, but matches that of gcc
> under WSL on my machine.).

Your (CMT's) code uses 'long' which is 32 bits on Windows and likely 64
bits on Linux.

If I change the type to 'u64', then the encrypted data now matches
between Windows and the presumably Linux system used on rextester.com.

Using float, Windows/Linux gcc/clang encrypted data still match.

Only between gcc/mcc using float is the encrypted data different.

I'll have a look to tomorrow at how practical it is to figure out what's
going on.

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

> When you get some free time, can you compile and run my C code and report
> the output? Thanks everybody.

What will you learn from that? You would be better off asking for the
warnings we get so you can fix the bugs.

--
Ben.

On 30/10/2023 23:22, bart wrote:
> 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...)
>>
>> The cpack is different on the two different compilers. Oh, that is
>> always fun! Interesting. Here are some screenshots:
>>
>> Online:
>>
>> https://i.ibb.co/7n0wdWv/image.png
>>
>> Notice cpack at 756768?
>>
>> And on MSVC ver: 4.8.09032:
>>
>> https://i.ibb.co/Pj0QZLf/image.png
>>
>> cpack is at 95375807?
>>
>> Interesting!
>>
>> When you get some free time, can you compile and run my C code and
>> report the output? Thanks everybody.
>>
>> :^)
>
> I tweaked the source code (used explicit assignment to fields of some
> structs) to be able to use my compilers.
>
> Then I tried these compilers:
>
> gcc 13.2.0 - this worked. (I assume it is supposed to show some
> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
> CAPNKUfB...", then the identical plaintext)
>
> tcc - failed. The encrypted text started
> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
> "dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."

Regarding tcc, a few things differ internally, but I think one clue is here:

#define CT_MBROT_ABET_LOOKUP(mp_char) \
((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)

This is effectively doing the following (to get an offset into the string?):

str("ABC", c) - "ABC";

It is assuming that both string literals have the same address. Clearly
on Tiny C they don't!

If I move that string into a variable, then Tcc starts to work. So does
bcc. lccwin32 still has a problem.

bart <bc@freeuk.com> writes:

> On 30/10/2023 23:22, bart wrote:
>> On 30/10/2023 21:01, Chris M. Thomasson wrote:

>> I tweaked the source code (used explicit assignment to fields of some
>> structs) to be able to use my compilers.
>> Then I tried these compilers:
>> gcc 13.2.0 - this worked. (I assume it is supposed to show some
>> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
>> CAPNKUfB...", then the identical plaintext)
>> tcc - failed. The encrypted text started
>> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
>> "dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
>> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."
>
> Regarding tcc, a few things differ internally, but I think one clue is here:
>
> #define CT_MBROT_ABET_LOOKUP(mp_char) \
> ((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)
>
> This is effectively doing the following (to get an offset into the string?):
>
> str("ABC", c) - "ABC";
>
> It is assuming that both string literals have the same address.

This is an unwarranted assumption.

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.

> If I move that string into a variable, then Tcc starts to work. So does
> bcc.

Saying that tcc starts to work when you fix the bug suggests that tcc
was not working before, but it's the code that was not working. tcc
(and presumably bcc) were working fine all along.

> lccwin32 still has a problem.

What's the problem? Are you sure it's lccwin32 and not the source code
that has the problem?

--
Ben.

[Reposting as the original reply seems to have vanished, but it may
reappear]

On 31/10/2023 11:32, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 30/10/2023 23:22, bart wrote:
>>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>
>>> I tweaked the source code (used explicit assignment to fields of some
>>> structs) to be able to use my compilers.
>>> Then I tried these compilers:
>>> gcc 13.2.0 - this worked. (I assume it is supposed to show some
>>> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
>>> CAPNKUfB...", then the identical plaintext)
>>> tcc - failed. The encrypted text started
>>> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
>>>
"dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
>>> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."
>>
>> Regarding tcc, a few things differ internally, but I think one clue
is here:
>>
>> #define CT_MBROT_ABET_LOOKUP(mp_char) \
>> ((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)
>>
>> This is effectively doing the following (to get an offset into the
string?):
>>
>> str("ABC", c) - "ABC";
>>
>> It is assuming that both string literals have the same address.
>
> This is an unwarranted assumption.
>
> 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.
>
>> If I move that string into a variable, then Tcc starts to work. So does
>> bcc.
>
> Saying that tcc starts to work when you fix the bug suggests that tcc
> was not working before, but it's the code that was not working. tcc
> (and presumably bcc) were working fine all along.
>
>> lccwin32 still has a problem.
>
> What's the problem? Are you sure it's lccwin32 and not the source code
> that has the problem?

When I say that compiler X has a problem, obviously I mean that the
program built with X shows an error. That is, the results are incorrect.

I'm not suggesting the compilers are at fault, although that is a
possibility especially with bcc (however, see below).

Probably this is not what Chris had in mind when he mentioned
inconsistency. But finding out why those compilers are producing the
wrong results I think is a useful first step to find out what is amiss
with this program.

(Throwing loads of -W options at it with gcc didn't show anything that
interesting.)

I next wanted to see next why lccwin32 is producing that data block (the
one output by ct_mbrotplane()) consisting of all 'A' characters, before
looking at that inconsistency issue.

And that does appear to a bug with the 64-bit version of lccwin32,
demonstrated here:

#include <stdio.h>
#include <math.h>

int main(void) {
printf("%f\n", fmod(0.445226, 1.0));
}

This produces an output of 'nan', rather than 0.445226. The program
works (in producing encrypted/decrypted output) with the 32-bit lccwin32.

I suppose what's left is seeing why that data block, regardless of
whether the encrypt/decrypt process appears to work, is why it can vary
across compilers.

Given the amount of floating point, I can't say I'm surprised, but I'd
be interesting in establishing exactly why.

bart <bc@freeuk.com> writes:

> [Reposting as the original reply seems to have vanished, but it may
> reappear]
>
> On 31/10/2023 11:32, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> On 30/10/2023 23:22, bart wrote:
>>>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>>
>>>> I tweaked the source code (used explicit assignment to fields of some
>>>> structs) to be able to use my compilers.
>>>> Then I tried these compilers:
>>>> gcc 13.2.0 - this worked. (I assume it is supposed to show some
>>>> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
>>>> CAPNKUfB...", then the identical plaintext)
>>>> tcc - failed. The encrypted text started
>>>> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
>>>>
> "dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
>>>> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."
>>>
>>> Regarding tcc, a few things differ internally, but I think one clue is
> here:
>>>
>>> #define CT_MBROT_ABET_LOOKUP(mp_char) \
>>> ((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)
>>>
>>> This is effectively doing the following (to get an offset into the
> string?):
>>>
>>> str("ABC", c) - "ABC";
>>>
>>> It is assuming that both string literals have the same address.
>>
>> This is an unwarranted assumption.
>>
>> 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.
>>
>>> If I move that string into a variable, then Tcc starts to work. So does
>>> bcc.
>>
>> Saying that tcc starts to work when you fix the bug suggests that tcc
>> was not working before, but it's the code that was not working. tcc
>> (and presumably bcc) were working fine all along.
>>
>>> lccwin32 still has a problem.
>>
>> What's the problem? Are you sure it's lccwin32 and not the source code
>> that has the problem?
>
> When I say that compiler X has a problem, obviously I mean that the program
> built with X shows an error.

That's a very odd way of putting it. My guess is that the
program has multiple meanings (and in some cases none). The compiler is
(probably) correctly picking one of them.

> That is, the results are incorrect.

Ah, then you know more that I. What are the correct results?

> I'm not suggesting the compilers are at fault, although that is a
> possibility especially with bcc (however, see below).
>
> Probably this is not what Chris had in mind when he mentioned
> inconsistency. But finding out why those compilers are producing the wrong
> results I think is a useful first step to find out what is amiss with this
> program.

The compiler is (probably) not producing the wrong results. The program
is producing results that the author did not intend.

> (Throwing loads of -W options at it with gcc didn't show anything that
> interesting.)

I found the result of carefully chosen -W options to be interesting.
Maybe you should reconsider "throwing" options at the compiler

> And that does appear to a bug with the 64-bit version of lccwin32,
> demonstrated here:
>
> #include <stdio.h>
> #include <math.h>
>
> int main(void) {
> printf("%f\n", fmod(0.445226, 1.0));
> }
>
> This produces an output of 'nan', rather than 0.445226.

Better to say that there is a bug in the implementation. The compiler
might be implementing fmod, but it's likely to be comming from a
library. I think lccwin32 has it's own library, but it's still not
really "the compiler".

> Given the amount of floating point, I can't say I'm surprised, but I'd be
> interesting in establishing exactly why.

Yes, some of it unnecessary. For example:

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

return ret;
}

There is no need for floating point arithmetic here; C's x/2 works fine
when implementing this function.

--
Ben.

[Another repost as i2pn2 not always sending my messges]

On 31/10/2023 16:15, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> [Reposting as the original reply seems to have vanished, but it may
>> reappear]
>>
>> On 31/10/2023 11:32, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> On 30/10/2023 23:22, bart wrote:
>>>>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>>>
>>>>> I tweaked the source code (used explicit assignment to fields of some
>>>>> structs) to be able to use my compilers.
>>>>> Then I tried these compilers:
>>>>> gcc 13.2.0 - this worked. (I assume it is supposed to show some
>>>>> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
>>>>> CAPNKUfB...", then the identical plaintext)
>>>>> tcc - failed. The encrypted text started
>>>>> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
>>>>>
>>
"dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
>>>>> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."
>>>>
>>>> Regarding tcc, a few things differ internally, but I think one clue is
>> here:
>>>>
>>>> #define CT_MBROT_ABET_LOOKUP(mp_char) \
>>>> ((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)
>>>>
>>>> This is effectively doing the following (to get an offset into the
>> string?):
>>>>
>>>> str("ABC", c) - "ABC";
>>>>
>>>> It is assuming that both string literals have the same address.
>>>
>>> This is an unwarranted assumption.
>>>
>>> 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.
>>>
>>>> If I move that string into a variable, then Tcc starts to work. So
does
>>>> bcc.
>>>
>>> Saying that tcc starts to work when you fix the bug suggests that tcc
>>> was not working before, but it's the code that was not working. tcc
>>> (and presumably bcc) were working fine all along.
>>>
>>>> lccwin32 still has a problem.
>>>
>>> What's the problem? Are you sure it's lccwin32 and not the source code
>>> that has the problem?
>>
>> When I say that compiler X has a problem, obviously I mean that the
program
>> built with X shows an error.
>
> That's a very odd way of putting it. My guess is that the
> program has multiple meanings (and in some cases none). The compiler is
> (probably) correctly picking one of them.
>
>> That is, the results are incorrect.
>
> Ah, then you know more that I. What are the correct results?

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.

Another is that encrypted text should be secret, but lccwin32 for
example had that be the same as the plaintext! I assumed that was wrong.

There may be others to do with quality of the encryption, as well as
consistency of the encrpted data across compilers, but those two are
what stood out for me when I ran the program and which seemed obviously
wrong.

On 10/31/2023 4:32 AM, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 30/10/2023 23:22, bart wrote:
>>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>
>>> I tweaked the source code (used explicit assignment to fields of some
>>> structs) to be able to use my compilers.
>>> Then I tried these compilers:
>>> gcc 13.2.0 - this worked. (I assume it is supposed to show some
>>> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
>>> CAPNKUfB...", then the identical plaintext)
>>> tcc - failed. The encrypted text started
>>> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
>>> "dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
>>> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."
>>
>> Regarding tcc, a few things differ internally, but I think one clue is here:
>>
>> #define CT_MBROT_ABET_LOOKUP(mp_char) \
>> ((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)
>>
>> This is effectively doing the following (to get an offset into the string?):
>>
>> str("ABC", c) - "ABC";
>>
>> It is assuming that both string literals have the same address.
>
> This is an unwarranted assumption.
>
> 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.

>
>> If I move that string into a variable, then Tcc starts to work. So does
>> bcc.
>
> Saying that tcc starts to work when you fix the bug suggests that tcc
> was not working before, but it's the code that was not working. tcc
> (and presumably bcc) were working fine all along.
>
>> lccwin32 still has a problem.
>
> What's the problem? Are you sure it's lccwin32 and not the source code
> that has the problem?
>

It almost has to be errors in my code. 99.9...% ;^)

On 10/30/2023 4:52 PM, 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.
>
>> When you get some free time, can you compile and run my C code and report
>> the output? Thanks everybody.
>
> What will you learn from that? You would be better off asking for the
> warnings we get so you can fix the bugs.
>

I can perhaps learn about some interesting output from compilers that I
have never used before? Fair enough?

On 10/31/2023 11:35 AM, bart wrote:
> [Another repost as i2pn2 not always sending my messges]
>
> On 31/10/2023 16:15, Ben Bacarisse wrote:
> > bart <bc@freeuk.com> writes:
> >
> >> [Reposting as the original reply seems to have vanished, but it may
> >> reappear]
> >>
> >> On 31/10/2023 11:32, Ben Bacarisse wrote:
> >>> bart <bc@freeuk.com> writes:
> >>>
> >>>> On 30/10/2023 23:22, bart wrote:
> >>>>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
> >>>
> >>>>> I tweaked the source code (used explicit assignment to fields of
> some
> >>>>> structs) to be able to use my compilers.
> >>>>> Then I tried these compilers:
> >>>>> gcc 13.2.0 - this worked. (I assume it is supposed to show some
> >>>>> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
> >>>>> CAPNKUfB...", then the identical plaintext)
> >>>>> tcc - failed. The encrypted text started
> >>>>> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
> >>>>>
> >>
> "dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
> >>>>> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."
> >>>>
> >>>> Regarding tcc, a few things differ internally, but I think one
> clue is
> >>    here:
> >>>>
> >>>>      #define CT_MBROT_ABET_LOOKUP(mp_char) \
> >>>>       ((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)
> >>>>
> >>>> This is effectively doing the following (to get an offset into the
> >>     string?):
> >>>>
> >>>>       str("ABC", c) - "ABC";
> >>>>
> >>>> It is assuming that both string literals have the same address.
> >>>
> >>> This is an unwarranted assumption.
> >>>
> >>> 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.
> >>>
> >>>> If I move that string into a variable, then Tcc starts to work. So
> does
> >>>> bcc.
> >>>
> >>> Saying that tcc starts to work when you fix the bug suggests that tcc
> >>> was not working before, but it's the code that was not working.  tcc
> >>> (and presumably bcc) were working fine all along.
> >>>
> >>>> lccwin32 still has a problem.
> >>>
> >>> What's the problem?  Are you sure it's lccwin32 and not the source
> code
> >>> that has the problem?
> >>
> >> When I say that compiler X has a problem, obviously I mean that the
> program
> >> built with X shows an error.
> >
> > That's a very odd way of putting it.  My guess is that the
> > program has multiple meanings (and in some cases none).  The compiler is
> > (probably) correctly picking one of them.
> >
> >> That is, the results are incorrect.
> >
> > Ah, then you know more that I.  What are the correct results?
>
> 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.

Indeed. It ideally should work with different compilers, but the
radically infested floating point issues must be an issue. It can act
funny...

>
> Another is that encrypted text should be secret, but lccwin32 for
> example had that be the same as the plaintext! I assumed that was wrong.

Wow! That is really odd to me. Can you drill down on that some more?
Thanks bart.

> There may be others to do with quality of the encryption, as well as
> consistency of the encrpted data across compilers, but those two are
> what stood out for me when I ran the program and which seemed obviously
> wrong.

Take notice of the name... Funny fractal encryption (FFE). So, it is a
fun toy to experiment with, well, imvho that is. :^)

On 10/30/2023 4:52 PM, 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.
>
>> When you get some free time, can you compile and run my C code and report
>> the output? Thanks everybody.
>
> What will you learn from that? You would be better off asking for the
> warnings we get so you can fix the bugs.
>

Fwiw, I fleshed this out back in 2015. I just got recently reminded of it.

On 31/10/2023 21:05, Chris M. Thomasson wrote:
> On 10/31/2023 11:35 AM, bart wrote:

>> Another is that encrypted text should be secret, but lccwin32 for
>> example had that be the same as the plaintext! I assumed that was wrong.
>
> Wow! That is really odd to me. Can you drill down on that some more?
> Thanks bart.

That was an apparent bug in the lccwin32's implementation of fmod(),
which always returned 'nan'. It meant every byte of that data block had
the same value.

bart <bc@freeuk.com> writes:

> [Another repost as i2pn2 not always sending my messges]
>
> On 31/10/2023 16:15, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> [Reposting as the original reply seems to have vanished, but it may
>>> reappear]
>>>
>>> On 31/10/2023 11:32, Ben Bacarisse wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> On 30/10/2023 23:22, bart wrote:
>>>>>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>>>>
>>>>>> I tweaked the source code (used explicit assignment to fields of some
>>>>>> structs) to be able to use my compilers.
>>>>>> Then I tried these compilers:
>>>>>> gcc 13.2.0 - this worked. (I assume it is supposed to show some
>>>>>> plaintext, encrypted text starting "fog.IiQ' U'?zDjP))v$oN)?z<xT
>>>>>> CAPNKUfB...", then the identical plaintext)
>>>>>> tcc - failed. The encrypted text started
>>>>>> "xy,$}lu~@NM*a%^z1YA+'N@9yrV]E...", and the decrypted was:
>>>>>>
>>>
> "dEjtkuXVjq5*uzqpWXE6tkzXVjq5czuqpWXE!t9zX\j35czu30/XE!tkuX\!qocuu3pWXEjtkzXVj3oczuq4WXE!0
>>>>>> kz.Vjqocuu3p/TEj0ku.Vj31cuz3pWXEjtkzXVj3o*uzq4W."
>>>>>
>>>>> Regarding tcc, a few things differ internally, but I think one clue is
>>> here:
>>>>>
>>>>> #define CT_MBROT_ABET_LOOKUP(mp_char) \
>>>>> ((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)
>>>>>
>>>>> This is effectively doing the following (to get an offset into the
>>> string?):
>>>>>
>>>>> str("ABC", c) - "ABC";
>>>>>
>>>>> It is assuming that both string literals have the same address.
>>>>
>>>> This is an unwarranted assumption.
>>>>
>>>> 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.
>>>>
>>>>> If I move that string into a variable, then Tcc starts to work. So does
>>>>> bcc.
>>>>
>>>> Saying that tcc starts to work when you fix the bug suggests that tcc
>>>> was not working before, but it's the code that was not working. tcc
>>>> (and presumably bcc) were working fine all along.
>>>>
>>>>> lccwin32 still has a problem.
>>>>
>>>> What's the problem? Are you sure it's lccwin32 and not the source code
>>>> that has the problem?
>>>
>>> When I say that compiler X has a problem, obviously I mean that the
> program
>>> built with X shows an error.
>>
>> That's a very odd way of putting it. My guess is that the
>> program has multiple meanings (and in some cases none). The compiler is
>> (probably) correctly picking one of them.
>>
>>> That is, the results are incorrect.
>>
>> Ah, then you know more that I. What are the correct results?
>
> 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.

--
Ben.

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

--
Ben.

On 10/31/2023 5:44 PM, 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?
>

No.

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? It produces 4 lots of output:

* A big block of random text

* Some plaintext

* The encrypted text

* The decrypted text

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!

So I don't know what you've seen. 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.

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

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

> On 10/31/2023 5:44 PM, 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?
>
> No.

You had a clue: you print the alphabet length as 93. Including space,
there are 95 "non-control" ASCII characters.

--
Ben.

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.

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