I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

My code works fine locally (prints the correct solution to the console),
but when I submit the .c file the auto-tester flags it with 'runtime
error' and says the output is empty.

------------------------------------------------------------
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// n = 3: output is 3 10 5 16 8 4 2 1


#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
    int n = atoi(argv[1]);
    int len = 0;
    char result[10000] = "";
    sprintf(result, "%d ", n);

    while(1) {
if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if(n != 1)
{
len = strlen(result);
sprintf(result + len, "%d ", n);
}
else
break;
    }

    len = strlen(result);
    sprintf(result + len, "1 ");
    printf("%s\n",result);

    return 0;
}
------------------------------------------------------------

Any ideas?
Thanks

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

On 3/18/2025 10:05 PM, Keith Thompson wrote:

DFS <nospam@dfs.com> writes:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

My code works fine locally (prints the correct solution to the
console), but when I submit the .c file the auto-tester flags it with
'runtime error' and says the output is empty.

------------------------------------------------------------
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// n = 3: output is 3 10 5 16 8 4 2 1


#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
    int n = atoi(argv[1]);
    int len = 0;
    char result[10000] = "";
    sprintf(result, "%d ", n);

    while(1) {
if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if(n != 1)
{
len = strlen(result);
sprintf(result + len, "%d ", n);
}
else
break;
    }

    len = strlen(result);
    sprintf(result + len, "1 ");
    printf("%s\n",result);

    return 0;
}
------------------------------------------------------------

I don't see any problem with the code, and neither does gcc on
my system.

It also compiles cleanly on theirs.

But the code you posted contains a number of NO-BREAK
SPACE characters (0xa0). "clang -Wno-unicode-whitespace" accepts
those characters without complaint, and gives non-fatal warnings
without that option. gcc treats them as a fatal error.

Those were probably added by one of our newsreaders.

Here's what it looks like on Notepad++ (showing end of line symbols)

https://imgur.com/DTX9fZG

A minor point: You print a trailing space. I don't know whether
the auto-tester will accept that.

I removed that, and no such luck.


Thanks for looking at it.

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

DFS <nospam@dfs.com> writes:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

My code works fine locally (prints the correct solution to the
console), but when I submit the .c file the auto-tester flags it with
runtime error' and says the output is empty.

------------------------------------------------------------
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// n = 3: output is 3 10 5 16 8 4 2 1

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
int n = atoi(argv[1]);
int len = 0;
char result[10000] = "";
sprintf(result, "%d ", n);

while(1) {
if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if(n != 1)
{
len = strlen(result);
sprintf(result + len, "%d ", n);
}
else
break;
}

len = strlen(result);
sprintf(result + len, "1 ");
printf("%s\n",result);

return 0;
}
------------------------------------------------------------

Any ideas?

Have you thought about how large the value of 'n' can
become inside the while() loop?

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

On 19/03/2025 03:34, DFS wrote:

<snip>

But my main concern right now is getting my submission to work
with their auto-tester.  All it says is 'runtime error' and
'empty output'.

Any ideas what I might be doing wrong?

$ file post.txt
post.txt: news, Unicode text, UTF-8 text

That's not going to help.

$ hexdump post.txt | cut -b 9-48 | grep " [89a-f][0-9a-f]"
5d5b 0a29 0a7b c320 2082 82c3 c320 2082
7261 7667 315b 295d 0a3b c320 2082 82c3
c320 2082 82c3 6920 746e 6c20 6e65 3d20
3020 0a3b c320 2082 82c3 c320 2082 82c3
3030 205d 203d 2222 0a3b c320 2082 82c3
c320 2082 82c3 7320 7270 6e69 6674 7228
0a3b 200a 82c3 c320 2082 82c3 c320 2082
6220 6572 6b61 0a3b c320 2082 82c3 c320
2082 82c3 7d20 0a0a c320 2082 82c3 c320
2082 82c3 6c20 6e65 3d20 7320 7274 656c
286e 6572 7573 746c 3b29 200a 82c3 c320
2082 82c3 c320 2082 7073 6972 746e 2866
2220 3b29 200a 82c3 c320 2082 82c3 c320
6572 7573 746c 3b29 0a0a c320 2082 82c3
c320 2082 82c3 7220 7465 7275 206e 3b30

ASCII is a 7-bit code. You have a fair bit of 8-bit noise mixed
in. That will probably have to go.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

DFS <nospam@dfs.com> writes:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

My code works fine locally (prints the correct solution to the
console), but when I submit the .c file the auto-tester flags it with
runtime error' and says the output is empty.

------------------------------------------------------------
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// n = 3: output is 3 10 5 16 8 4 2 1


#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
int n = atoi(argv[1]);
int len = 0;
char result[10000] = "";
sprintf(result, "%d ", n);

while(1) {
if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if(n != 1)
{
len = strlen(result);
sprintf(result + len, "%d ", n);
}
else
break;
}

len = strlen(result);
sprintf(result + len, "1 ");
printf("%s\n",result);

return 0;
}
------------------------------------------------------------

Any ideas?

Have you thought about how large the value of 'n' can
become inside the while() loop?

Each algorithm problem has a constraint you're supposed to consider
(which I figure is the largest value they test for).

For this 'weird algorithm' problem, the constraint is 1 <= n <= 10^6.

The output of n = 999999 is:

999999 2999998 1499999 4499998 2249999 6749998 3374999 10124998 5062499 15187498 7593749 22781248 11390624 5695312 2847656 1423828 711914 355957 1067872 533936 266968 133484 66742 33371 100114 50057 150172 75086 37543
112630 56315 168946 84473 253420 126710 63355 190066 95033 285100 142550
71275 213826 106913 320740 160370 80185 240556 120278 60139 180418 90209
270628 135314 67657 202972 101486 50743 152230 76115 228346 114173
342520 171260 85630 42815 128446 64223 192670 96335 289006 144503 433510
216755 650266 325133 975400 487700 243850 121925 365776 182888 91444
45722 22861 68584 34292 17146 8573 25720 12860 6430 3215 9646 4823 14470
7235 21706 10853 32560 16280 8140 4070 2035 6106 3053 9160 4580 2290
1145 3436 1718 859 2578 1289 3868 1934 967 2902 1451 4354 2177 6532 3266
1633 4900 2450 1225 3676 1838 919 2758 1379 4138 2069 6208 3104 1552 776
388 194 97 292 146 73 220 110 55 166 83 250 125 376 188 94 47 142 71 214
107 322 161 484 242 121 364 182 91 274 137 412 206 103 310 155 466 233
700 350 175 526 263 790 395 1186 593 1780 890 445 1336 668 334 167 502
251 754 377 1132 566 283 850 425 1276 638 319 958 479 1438 719 2158 1079
3238 1619 4858 2429 7288 3644 1822 911 2734 1367 4102 2051 6154 3077
9232 4616 2308 1154 577 1732 866 433 1300 650 325 976 488 244 122 61 184
92 46 23 70 35 106 53 160 80 40 20 10 5 16 8 4 2 1

The largest n in there is 22781248.


So my variables are plenty big enough to handle the constraint and output.

But my main concern right now is getting my submission to work with
their auto-tester. All it says is 'runtime error' and 'empty output'.

Any ideas what I might be doing wrong?

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

On 3/18/2025 11:26 PM, Keith Thompson wrote:

DFS <nospam@dfs.com> writes:

There's your problem.

https://cses.fi/problemset/text/2433

"In all problems you should read input from standard input and write
output to standard output."

ha! It usually helps to read the instructions first.

The autotester expects your program to read arguments from stdin, not
from command line arguments.

It probably passes no arguments to your program, so argv[1] is a null pointer. It's likely your program compiles (assuming the NBSP
characters were added during posting) and crashes at runtime, producing
no output.

I KNEW clc would come through!

Pretty easy fixes:

1 use scanf()
2 update int to long
3 handle special case of n = 1
4 instead of collecting the results in a char variable, I print
them as they're calculated

The algorithm part was very simple and correct. Later ones won't be so
easy. I coded 4 so far (but just submitted this one here), and plan on
doing all 300.

https://imgur.com/bq0pKIw

Did you hear a boom?

Thanks again!


updated code that passes: ===============================================================
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// example: the sequence for n=3 is 3 10 5 16 8 4 2 1

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
long n = 0;
scanf("%ld", &n);
printf("%ld ",n);
while(1) {
if(n==1) {exit(0);}

if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if(n != 1)
{printf("%ld ",n);}
else
break;
}
printf("1\n");
return 0;
}
===============================================================

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

On 19/03/2025 04:42, DFS wrote:

Pretty easy fixes:

1 use scanf()
2 update int to long
3 handle special case of n = 1
4 instead of collecting the results in a char variable, I print
  them as they're calculated

You've also fixed another glitch which may or may not have been
significant:

$ file post2.txt
post2.txt: news, ASCII text

So wherever that UTF-8 came from, it's gone now.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 3/19/2025 12:51 AM, Richard Heathfield wrote:

On 19/03/2025 04:42, DFS wrote:

Pretty easy fixes:

1 use scanf()
2 update int to long
3 handle special case of n = 1
4 instead of collecting the results in a char variable, I print
   them as they're calculated

You've also fixed another glitch which may or may not have been
significant:

$ file post2.txt
post2.txt: news, ASCII text

So wherever that UTF-8 came from, it's gone now.

Cool. Thanks for looking at it.

Hey, how are your C book (from 2000) sales? Thought about a new edition?

https://www.amazon.com/C-Unleashed-Richard-Heathfield/dp/0672318962

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

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. After Keith pointed out I needed to
read from stdin, I submitted the code again and it passed some tests but
failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

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

On 19/03/2025 05:02, DFS wrote:

On 3/19/2025 12:51 AM, Richard Heathfield wrote:

On 19/03/2025 04:42, DFS wrote:

Pretty easy fixes:

1 use scanf()
2 update int to long
3 handle special case of n = 1
4 instead of collecting the results in a char variable, I print
   them as they're calculated

You've also fixed another glitch which may or may not have been
significant:

$ file post2.txt
post2.txt: news, ASCII text

So wherever that UTF-8 came from, it's gone now.

Cool.  Thanks for looking at it.

Hey, how are your C book (from 2000) sales?  Thought about a new
edition?

I'm not sure a new edition is necessary, but if it is to be
written it would be better served by someone like Keith or Tim,
both of whom have (as I have not) kept up with the
million-and-one changes that appear to have assailed the simple
language I once enjoyed.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

DFS <nospam@dfs.com> writes:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. [...]

Yes, I knew that already. Did you think I asked the question
without having first investigated the problem?

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

On 2025-03-19, DFS <nospam@dfs.com> wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

My code works fine locally (prints the correct solution to the console),
but when I submit the .c file the auto-tester flags it with 'runtime
error' and says the output is empty.

------------------------------------------------------------
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// n = 3: output is 3 10 5 16 8 4 2 1

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
    int n = atoi(argv[1]);
    int len = 0;
    char result[10000] = "";
    sprintf(result, "%d ", n);

    while(1) {
if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if(n != 1)
{
len = strlen(result);
sprintf(result + len, "%d ", n);
}
else
break;
    }

    len = strlen(result);
    sprintf(result + len, "1 ");
    printf("%s\n",result);

    return 0;
}
------------------------------------------------------------

Any ideas?

What happens if the input is a negative number?

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

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. After Keith pointed out I needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment
(supposedly, x86-64 Linux) used both by yourself and by the server that
tests results.
In more general case, 'long' is not guaranteed to handle numbers in
range up to 18,997,161,173 that can happen in this test.
Something like int64_t would be safer.

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

On Tue, 18 Mar 2025 21:38:55 -0400
DFS <nospam@dfs.com> wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

It is not an interesting programming exercise. But it looks to me as a challenging math exercise. I mean, how could we give a not too
pessimistic estimate for upper bound of length of the sequence that
starts at given n without running a full sequence? Or estimate for
maximal value in the sequence?
So far, I found no answers.

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

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

                len = strlen(result);
                sprintf(result + len, "%d ", n);

And what's odd here is collating the results in a string (especially
when the possible number of steps is unknown). Why not just print it
straight to the console?

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

On Wed, 19 Mar 2025 10:15:58 +0000
bart <bc@freeuk.com> wrote:

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

Thank you. Wikipedia article about Collatz Conjecture is a good reading.

                len = strlen(result);
                sprintf(result + len, "%d ", n);

And what's odd here is collating the results in a string (especially
when the possible number of steps is unknown). Why not just print it straight to the console?

OP got it further down the thread.

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

On 3/19/2025 6:15 AM, bart wrote:

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

I wouldn't have known it was a famous math conjecture, but no doubt the
author of the problem did.

                 len = strlen(result);
                 sprintf(result + len, "%d ", n);

And what's odd here is collating the results in a string (especially
when the possible number of steps is unknown). Why not just print it
straight to the console?

My initial submission used straight to console. It was rejected for
untold reasons, so I tried a variety of changes, including collating.

I went back to printing to console, and along with the other fixes the
code was finally accepted.

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

On 3/19/2025 6:36 AM, Michael S wrote:

On Tue, 18 Mar 2025 21:38:55 -0400
DFS <nospam@dfs.com> wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

It is not an interesting programming exercise.

The early problems are easy. I plan on doing (or giving a good shot at)
all 300.

But it looks to me as a
challenging math exercise. I mean, how could we give a not too
pessimistic estimate for upper bound of length of the sequence that
starts at given n without running a full sequence? Or estimate for
maximal value in the sequence?
So far, I found no answers.

If you do find a proof, you'll get a blue ribbon and a free dinner (and
your own Wikipedia entry).

https://en.wikipedia.org/wiki/Collatz_conjecture

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

On Wed, 19 Mar 2025 09:03:33 -0400
DFS <nospam@dfs.com> wibbled:

On 3/19/2025 6:15 AM, bart wrote:

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

I wouldn't have known it was a famous math conjecture, but no doubt the >author of the problem did.

Reading wikipedia it looks like one of those dull problems mathematicians think up when they've got too much free time on their hands.

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

On Wed, 19 Mar 2025 14:40:38 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

Reading wikipedia it looks like one of those dull problems
mathematicians think up when they've got too much free time on their
hands.

Yeah, one of those dull problems that most of the times remain obscure,
but occasionally end up providing the rest of world with things like
public-key cryptography.

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

On Wed, 19 Mar 2025 17:39:38 +0200
Michael S <already5chosen@yahoo.com> wibbled:

On Wed, 19 Mar 2025 14:40:38 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

Reading wikipedia it looks like one of those dull problems
mathematicians think up when they've got too much free time on their
hands.

Yeah, one of those dull problems that most of the times remain obscure,
but occasionally end up providing the rest of world with things like >public-key cryptography.

But 99.99% of the time doesn't.

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

On 3/19/2025 3:16 AM, Ike Naar wrote:

On 2025-03-19, DFS <nospam@dfs.com> wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

What happens if the input is a negative number?

crash boom bang

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

On 19/03/2025 11:40, Michael S wrote:

On Wed, 19 Mar 2025 10:15:58 +0000
bart <bc@freeuk.com> wrote:

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

Thank you. Wikipedia article about Collatz Conjecture is a good reading.

There's a nice Veritasium video on it, at <https://www.youtube.com/watch?v=094y1Z2wpJg>.

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

On 19/03/2025 17:23, DFS wrote:

On 3/19/2025 5:55 AM, Michael S wrote:

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply.  After Keith pointed out I
needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment
(supposedly, x86-64 Linux) used both by yourself and by the
server that
tests results.
In more general case, 'long' is not guaranteed to handle
numbers in
range up to 18,997,161,173 that can happen in this test.

How did you determine that?

By the language definition.


++++++++++++++++++++++++++++++++++++++++++++++

5.2.4.2.1 Sizes of integer types <limits.h>

[...]

— minimum value for an object of type long int
LONG_MIN
-2147483647 // −(231 − 1)

— maximum value for an object of type long int
LONG_MAX
+2147483647 // 231 − 1

++++++++++++++++++++++++++++++++++++++++++++++

That is, the long int type is required to have a sign bit and at
least 31 value bits, giving a guaranteed minimum range of
-2147483647 to 2147483647. That's 2 thou mill.

You can squeeze another bit out of it by going unsigned: 0 to
4294967295. That's 4 thou mill.

From C99 onwards you can use long long int to give you 63 (or 64
for unsigned) value bits - printf with %lld or %llu. Roughly 9
mill mill mill and 18 mill mill mill respectively.


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 3/19/25 13:23, DFS wrote:
...

    int64_t n = 0, max = 0, thismax = 0;

...

    printf("\nmax n = %lld reached at input = %d\n", max, input);

...

You'll get compilation warnings about the printf specifier used with
int64_t.

Not if you use the correct specifier:
#include <inttypes.h>
printf("\nmax n = %" PRId64 " reached at input = %d\n", max, input);

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

On 3/19/2025 5:55 AM, Michael S wrote:

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. After Keith pointed out I needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment (supposedly, x86-64 Linux) used both by yourself and by the server that
tests results.
In more general case, 'long' is not guaranteed to handle numbers in
range up to 18,997,161,173 that can happen in this test.

How did you determine that?

I ran the program for inputs 1 to 10^6 (1 million):

Windows11, Tiny C compiler
$ ptime weird 1 1000000
max n = 56991483520 reached at input = 704511
Execution time: 0.559 s

Kali Linux (Windows WSL), gcc
$ time ./weird 1 1000000
max n = 56991483520 reached at input = 704511
real 0m0.330s

(56,991,483,520)

Something like int64_t would be safer.

Indeed. My code bombed using long when the input n = 151177.

Used int64_t and it didn't bomb.


Thanks

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

On 3/19/2025 1:27 AM, Tim Rentsch wrote:

DFS <nospam@dfs.com> writes:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. [...]

Yes, I knew that already. Did you think I asked the question
without having first investigated the problem?

I wouldn't presume.

Did you investigate first?

I just now did:

gcc on Kali Linux (in Windows WSL)

run it: $ ./weird start stop

$time ./weird 1 1000000
<1000000 lines will be output>
max n = 56991483520 reached at input = 704511

real 0m5.792s



code
-----------------------------------------------------------------
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// example: the sequence for n=3 is 3 10 5 16 8 4 2 1

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    int steps, input;
    int startN = atoi(argv[1]);
    int stopN = atoi(argv[2]);
    int64_t n = 0, max = 0, thismax = 0;

    for (int i = startN; i <= stopN; i++) {

n = i;
steps = 1;
thismax = n;
while(1) {

if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if (n > max) {max = n; input = i;}
if (n > thismax) {thismax = n;}
steps++;

if (i == 1) {
printf("input 1, max n = 1, steps = 1\n");
break;
}

if(n == 1) {
printf("input %d, max n = %6lld, steps = %4d\n", i,
thismax, steps);
break;
}
}


    }
    printf("\nmax n = %lld reached at input = %d\n", max, input);
    return 0;
}

-----------------------------------------------------------------

You'll get compilation warnings about the printf specifier used with
int64_t.

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

On Wed, 19 Mar 2025 17:38:12 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:

On 19/03/2025 17:23, DFS wrote:

On 3/19/2025 5:55 AM, Michael S wrote:

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply.  After Keith pointed out I
needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment
(supposedly, x86-64 Linux) used both by yourself and by the
server that
tests results.
In more general case, 'long' is not guaranteed to handle
numbers in
range up to 18,997,161,173 that can happen in this test.

How did you determine that?

By the language definition.

Well, not exactly.
I never read C Standard docs except the very first one that I read more
that I read more than 33 years ago, so not very likely to remember it literally.
Let's say that I know this particular bit of trivia from 1st hand
experience and from reading few ABI definitions.

++++++++++++++++++++++++++++++++++++++++++++++

5.2.4.2.1 Sizes of integer types <limits.h>

[...]

— minimum value for an object of type long int
LONG_MIN
-2147483647 // −(231 − 1)

— maximum value for an object of type long int
LONG_MAX
+2147483647 // 231 − 1

++++++++++++++++++++++++++++++++++++++++++++++

That is, the long int type is required to have a sign bit and at
least 31 value bits, giving a guaranteed minimum range of
-2147483647 to 2147483647. That's 2 thou mill.

You can squeeze another bit out of it by going unsigned: 0 to
4294967295. That's 4 thou mill.

From C99 onwards you can use long long int to give you 63 (or 64
for unsigned) value bits - printf with %lld or %llu. Roughly 9
mill mill mill and 18 mill mill mill respectively.

I suspected that, but was not sure, so suggested to DFS a type that I am
sure about.
In my own test program I used 'long long', because I knew that on my
system it is 64-bit. I tend to know such things about systems, I use.
More interesting question is "How do *you* know about this newfangled gibberish?" :-)

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

On 19/03/2025 18:19, Michael S wrote:

More interesting question is "How do*you* know about this newfangled gibberish?" :-)

<g> I discovered Usenet in either 1998 or perhaps more likely
1999. Back then, this newfangled gibberish was all clc ever
talked about. That and FAQ 1.22, which is a real doozy.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 3/19/2025 1:40 PM, James Kuyper wrote:

On 3/19/25 13:23, DFS wrote:
...

    int64_t n = 0, max = 0, thismax = 0;

...

    printf("\nmax n = %lld reached at input = %d\n", max, input);

...

You'll get compilation warnings about the printf specifier used with
int64_t.

Not if you use the correct specifier:
#include <inttypes.h>
printf("\nmax n = %" PRId64 " reached at input = %d\n", max, input);

I saw that online, but didn't want to add another include.

But it does make the code slightly more portable - with those changes
the code now compiles and runs cleanly under Windows tcc and Linux gcc.

Thanks.

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

DFS <nospam@dfs.com> writes:

On 3/19/2025 1:27 AM, Tim Rentsch wrote:

DFS <nospam@dfs.com> writes:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. [...]

Yes, I knew that already. Did you think I asked the question
without having first investigated the problem?

I wouldn't presume.

Did you investigate first?

Of course.

I just now did:

gcc on Kali Linux (in Windows WSL)

run it: $ ./weird start stop

$time ./weird 1 1000000
<1000000 lines will be output>
max n = 56991483520 reached at input = 704511

real 0m5.792s

code
-----------------------------------------------------------------
// If n is even, divide it by two.
// If n is odd, multiply it by three and add one.
// Repeat until n is one.
// example: the sequence for n=3 is 3 10 5 16 8 4 2 1

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
int steps, input;
int startN = atoi(argv[1]);
int stopN = atoi(argv[2]);
int64_t n = 0, max = 0, thismax = 0;

for (int i = startN; i <= stopN; i++) {

n = i;
steps = 1;
thismax = n;
while(1) {

if((n % 2) == 0)
{n /= 2;}
else
{n = (n * 3) + 1;}

if (n > max) {max = n; input = i;}
if (n > thismax) {thismax = n;}
steps++;

if (i == 1) {
printf("input 1, max n = 1, steps = 1\n");
break;
}

if(n == 1) {
printf("input %d, max n = %6lld, steps = %4d\n",
i, thismax, steps);
break;
}
}

}
printf("\nmax n = %lld reached at input = %d\n", max, input);
return 0;
}

-----------------------------------------------------------------

You'll get compilation warnings about the printf specifier used with
int64_t.

I recommend using unsigned long long rather than int64_t. After
all, all values reached are guaranteed to be non-negative. And
there is no confusion or uncertainty about what conversion sequence
to use in the call to printf().

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

Michael S <already5chosen@yahoo.com> writes:

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. After Keith pointed out I needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment (supposedly, x86-64 Linux) used both by yourself and by the server that
tests results.
In more general case, 'long' is not guaranteed to handle numbers in
range up to 18,997,161,173 that can happen in this test.

The number 18997161173 is odd. The largest value reached is three
times that, plus 1, which is 56991483520.

Something like int64_t would be safer.

Using unsigned long long is safer still, and easier, because there
is no need for hoop-jumping to print them out with printx.

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

On Wed, 19 Mar 2025 12:59:13 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. After Keith pointed out I needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment (supposedly, x86-64 Linux) used both by yourself and by the server
that tests results.
In more general case, 'long' is not guaranteed to handle numbers in
range up to 18,997,161,173 that can happen in this test.

The number 18997161173 is odd. The largest value reached is three
times that, plus 1, which is 56991483520.

Yes, my mistake.
I only looked for maximal odd number in the sequence. Forgot about
even numbers.

Something like int64_t would be safer.

Using unsigned long long is safer still, and easier, because there
is no need for hoop-jumping to print them out with printx.

I explained the reason in the reply to Richard Heathfield.

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

Muttley@DastardlyHQ.org writes:

On Wed, 19 Mar 2025 09:03:33 -0400
DFS <nospam@dfs.com> wibbled:

On 3/19/2025 6:15 AM, bart wrote:

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

I wouldn't have known it was a famous math conjecture, but no
doubt the author of the problem did.

Reading wikipedia it looks like one of those dull problems
mathematicians think up when they've got too much free time on
their hands.

The 3n+1 problem, as it is sometimes called, is interesting
because it is easy to state and easy to understand, even without
any mathematical training beyond grade school, and yet has
resisted the efforts of many of the best mathematicians in the
world to try to prove it. It seems like it should be easy, but
it is in fact incredibly difficult, based on almost 100 years of
experience.

If you try looking at it and see if you can make some sort of
dent in the problem you may find it more interesting than your
initial impression suggests.

Related problem: consider a class of analogous problems, where
instead of 3n+1 we use 3n+k, for k positive and odd. Question:
for which values of k does the 3n+k algorithm have multiple loops
rather than just one?

(I acknowledge the above posting to be off topic, and ask the
group for forgiveness for this transgression.)

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

On 3/19/2025 4:53 AM, Keith Thompson wrote:

Ike Naar <ike@sdf.org> writes:

On 2025-03-19, DFS <nospam@dfs.com> wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

I've been playing with some of these myself.

Are you just looking for ones you find interesting?

I'm starting at the top and going down 1 by 1, no matter how simple.

I'm actually using
scanf() for integer input, something I wouldn't do in normal code
(because the behavior is undefined if the scanned value is out
of range). This is a rare case where it's safe to assume that
stdin has nothing harmful.

My very 1st submission for 'Missing Number' was accepted, but each use
of scanf() generated a warning:

warning: ignoring return value of 'scanf' declared with attribute 'warn_unused_result' [-Wunused-result]
30 | scanf("%d", &nums[i]);


spoiler: code below



























===============================================================
//identify the missing number in a set of consecutive integers

#include <stdio.h>
#include <stdlib.h>

//comparator function used with qsort
int compareint (const void * a, const void * b)
{
if (*(int*)a > *(int*)b) return 1;
else if (*(int*)a < *(int*)b) return -1;
else return 0;
}

int main(int argc, char *argv[])
{
//vars
int i = 0, N = 0;

//line 1 from stdin: number of elements + 1
scanf("%d", &N);
int *nums = malloc(N * sizeof(int));

//line 2 from stdin: list of elements
for (i = 0; i < N-1; i++) {
scanf("%d", &nums[i]);
}

//sort the array
qsort(nums, N, sizeof(int), compareint);

//identify missing number
int missing = N;
for(i = 0; i < N; i++) {
if(nums[i+1] - nums[i] > 1) {
missing = nums[i] + 1;
break;
}
}

//print solution
printf("%d\n", missing);

//free and end
free(nums);
return 0;
}
===============================================================

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

On 19/03/2025 20:45, DFS wrote:

On 3/19/2025 4:53 AM, Keith Thompson wrote:

<snip>

I'm actually using
scanf() for integer input, something I wouldn't do in normal code
(because the behavior is undefined if the scanned value is out
of range).  This is a rare case where it's safe to assume that
stdin has nothing harmful.

My very 1st submission for 'Missing Number' was accepted, but
each use of scanf() generated a warning:

Like Keith, I don't usually use scanf.

My preference is to read the number into a text buffer using
fgets, and then convert it using strtoul if I can, or strtol if I
have to allow for negatives.

//identify the missing number in a set of consecutive integers

Not sure why you're sorting and malloc-ing.

Loop through the input, adding as you go.
Let the first number be x.
Let the last number be y.
Let the total of all numbers be t.
Let m = ((y*(y+1))-(x*(x+1)))/2 - t;

"The missing number is: %lld\n", m

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 19/03/2025 21:21, Richard Heathfield wrote:

On 19/03/2025 20:45, DFS wrote:

On 3/19/2025 4:53 AM, Keith Thompson wrote:

<snip>

I'm actually using
scanf() for integer input, something I wouldn't do in normal code
(because the behavior is undefined if the scanned value is out
of range).  This is a rare case where it's safe to assume that
stdin has nothing harmful.

My very 1st submission for 'Missing Number' was accepted, but
each use of scanf() generated a warning:

Like Keith, I don't usually use scanf.

My preference is to read the number into a text buffer using
fgets, and then convert it using strtoul if I can, or strtol if I
have to allow for negatives.

//identify the missing number in a set of consecutive integers

Not sure why you're sorting and malloc-ing.

Loop through the input, adding as you go.
Let the first number be x.
Let the last number be y.
Let the total of all numbers be t.
Let m = ((y*(y+1))-(x*(x+1)))/2 - t;

"The missing number is: %lld\n", m

It occurs to me now that maybe you're sorting in case the numbers
aren't as consecutive as they're supposed to be, in which case it
can still be done without sorting, but it's very, /very/ slightly
harder because you have to keep track of the lowest and highest
seen so far:

Loop through the input, adding as you go and remembering your two
extreme values.
Let the lowest number be x.
Let the highest number be y.
Let the total of all numbers be t.
Let m = ((y*(y+1))-(x*(x+1)))/2 - t;

"The missing number is: %lld\n", m

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 3/19/2025 5:56 PM, Keith Thompson wrote:

DFS <nospam@dfs.com> writes:

On 3/19/2025 4:53 AM, Keith Thompson wrote:

I used a different approach. I'll encode the description of the
solution using rot13.

The program is given an integer n and a list of n-1 integers, not
necessarily ordered.

The task is to determine which number is missing from the list.

Gurer'f n jryy xabja sbezhyn sbe gur fhz bs nyy a ahzoref sebz bar
gb a. Pbzchgr gur rkcrpgrq fhz, gura fhogenpg gur fhz bs gur ahzoref
tvira ba gur frpbaq vachg yvar. Gur qvssrerapr vf gur zvffvat ahzore.

That's dead simple! It works because the input numbers start with 1.

I'll give it a quick try.

edit: my attempt passed 9 of 14 tests, but fails on large N because
it's not calculating sum(1..N) correctly. Line 10. See anything?


//identify the missing number in a set of otherwise consecutive integers #include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
int i = 0, N = 0, temp = 0;
int64_t totN = 0, totInputs = 0;
scanf("%d", &N); //number of elements
for (i = 0; i < N-1; i++) { //list of elements
scanf("%d", &temp); //to temp var
totInputs += temp; //running total
}
totN = (N * (N + 1)) / 2; //sum of numbers 1 to N
printf("N %lld\n",N);
printf("tot N %lld\n",totN);
printf("tot inputs %lld\n",totInputs);
printf("%d\n", totN - totInputs); //solution
return 0;
}


sample output
N 50000
tot N -897458648 FAIL (should be 1250025000)
tot inputs 1250017374 GOOD
-2147476022 FAIL (should be 7626)

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

On Wed, 19 Mar 2025 13:13:45 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wibbled:

Muttley@DastardlyHQ.org writes:

On Wed, 19 Mar 2025 09:03:33 -0400
DFS <nospam@dfs.com> wibbled:

On 3/19/2025 6:15 AM, bart wrote:

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

I wouldn't have known it was a famous math conjecture, but no
doubt the author of the problem did.

Reading wikipedia it looks like one of those dull problems
mathematicians think up when they've got too much free time on
their hands.

The 3n+1 problem, as it is sometimes called, is interesting
because it is easy to state and easy to understand, even without
any mathematical training beyond grade school, and yet has
resisted the efforts of many of the best mathematicians in the
world to try to prove it. It seems like it should be easy, but
it is in fact incredibly difficult, based on almost 100 years of
experience.

I guess some maths problems can't be proven directly, they have to be - for want of a better word - run. A bit like the halting problem in CS.

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

Michael S <already5chosen@yahoo.com> writes:

On Wed, 19 Mar 2025 17:38:12 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:

On 19/03/2025 17:23, DFS wrote:

On 3/19/2025 5:55 AM, Michael S wrote:

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. After Keith pointed out I
needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment
(supposedly, x86-64 Linux) used both by yourself and by the
server that
tests results.
In more general case, 'long' is not guaranteed to handle
numbers in
range up to 18,997,161,173 that can happen in this test.

How did you determine that?

By the language definition.

Well, not exactly.
I never read C Standard docs except the very first one that I read
more that I read more than 33 years ago, so not very likely to
remember it literally.
Let's say that I know this particular bit of trivia from 1st hand
experience and from reading few ABI definitions.

++++++++++++++++++++++++++++++++++++++++++++++

5.2.4.2.1 Sizes of integer types <limits.h>

[...]

? minimum value for an object of type long int
LONG_MIN
-2147483647 // ?(231 ? 1)

? maximum value for an object of type long int
LONG_MAX
+2147483647 // 231 ? 1

++++++++++++++++++++++++++++++++++++++++++++++

That is, the long int type is required to have a sign bit and at
least 31 value bits, giving a guaranteed minimum range of
-2147483647 to 2147483647. That's 2 thou mill.

You can squeeze another bit out of it by going unsigned: 0 to
4294967295. That's 4 thou mill.

From C99 onwards you can use long long int to give you 63 (or 64
for unsigned) value bits - printf with %lld or %llu. Roughly 9
mill mill mill and 18 mill mill mill respectively.

I suspected that, but was not sure, so suggested to DFS a type that I am
sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

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

Muttley@DastardlyHQ.org writes:

On Wed, 19 Mar 2025 13:13:45 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wibbled:

Muttley@DastardlyHQ.org writes:

On Wed, 19 Mar 2025 09:03:33 -0400
DFS <nospam@dfs.com> wibbled:

On 3/19/2025 6:15 AM, bart wrote:

On 19/03/2025 01:38, DFS wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

This is related to the Collatz Conjecture. What's weird is not
mentioning it.

I wouldn't have known it was a famous math conjecture, but no
doubt the author of the problem did.

Reading wikipedia it looks like one of those dull problems
mathematicians think up when they've got too much free time on
their hands.

The 3n+1 problem, as it is sometimes called, is interesting
because it is easy to state and easy to understand, even without
any mathematical training beyond grade school, and yet has
resisted the efforts of many of the best mathematicians in the
world to try to prove it. It seems like it should be easy, but
it is in fact incredibly difficult, based on almost 100 years of
experience.

I guess some maths problems can't be proven directly, they have to
be - for want of a better word - run. A bit like the halting
problem in CS.

Indeed it is the case that some statements are not provable, even
though they may still be true. But the 3n+1 problem is unlikely to
be in that category; it is just very hard to prove.

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

Richard Heathfield <rjh@cpax.org.uk> writes:

On 19/03/2025 05:02, DFS wrote:

On 3/19/2025 12:51 AM, Richard Heathfield wrote:

On 19/03/2025 04:42, DFS wrote:

Pretty easy fixes:

1 use scanf()
2 update int to long
3 handle special case of n = 1
4 instead of collecting the results in a char variable, I print
them as they're calculated

You've also fixed another glitch which may or may not have been
significant:

$ file post2.txt
post2.txt: news, ASCII text

So wherever that UTF-8 came from, it's gone now.

Cool. Thanks for looking at it.

Hey, how are your C book (from 2000) sales? Thought about a new
edition?

I'm not sure a new edition is necessary, but if it is to be
written it would be better served by someone like Keith or Tim,
both of whom have (as I have not) kept up with the million-and-one
changes that appear to have assailed the simple language I once
enjoyed.

The C99 standard has a list of 54 what it calls "major changes",
although IMO many or most of those are fairly minor. There are also
other differences relative to C90, but most of them are simply
clarifications or slight changes in wording.

I went through the list of major changes and selected out the items
I consider the most significant. Here they are, organized into
several related areas.

Language constructs taken out from C90:
REMOVED: implicit int
REMOVED: implicit function declaration

Comments:
// comments are now allowed

Preprocessor:
empty macro arguments
macros with variable number of arguments

Lexical:
improved lower bounds for identifier length -
went from 6 and 31 (for global and non-global) in C90
to 31 and 63 in C99

Types added:
boolean type _Bool
complex numbers
long long and unsigned long long

New language constructs:
more general initialization for aggregates and unions
compound literals
designated initializers
mixing of declarations and code (including in for() initializers)

Array related:
arrays and array types with non-constant extents, aka
VLA, for variable length arrays, and
VMT, for variably modified type
flexible array members (recognizing the "struct hack")

Miscellaneous:
'inline' functions
return with expression now disallowed in void function,
and vice versa

I included the "array related" items, and also complex numbers, as
significant items, even though they aren't used very often. I think
it's important to know about these features, despite their
infrequent use. (Incidentally, both complex numbers and VLA/VMT
were made optional in C11.)

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

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am
sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why
not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values,
then it's surprisingly rare in source code.

In practice, most code now assumes that 'int' is 32 bits, and 'long' is inadvisedly used for 64 bits, since its actual width is typically:

long

Windows 32-bit 32 bits
Windows 64-bit 32 bits
Linux 32-bit 32 bits
Linux 64-bit 64 bits

My suggestion for writing code that is not going to run on 16-bit or
lesser (or unusual) hardware is to assume:

char 8 bits
short 16 bits
int 32 bits
long long 64 bits

and to forget 'long'.

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

Michael S <already5chosen@yahoo.com> writes:

On Wed, 19 Mar 2025 12:59:13 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Wed, 19 Mar 2025 00:38:44 -0400
DFS <nospam@dfs.com> wrote:

On 3/18/2025 11:07 PM, Tim Rentsch wrote:

Have you thought about how large the value of 'n' can
become inside the while() loop?

I was too smug in my first reply. After Keith pointed out I needed
to read from stdin, I submitted the code again and it passed some
tests but failed with 'OUTPUT LIMIT EXCEEDED' when n = 159487.

Updating int to long worked, and now I'm bona fide!

So thanks.

What you did happens to be sufficient for a particular environment
(supposedly, x86-64 Linux) used both by yourself and by the server
that tests results.
In more general case, 'long' is not guaranteed to handle numbers in
range up to 18,997,161,173 that can happen in this test.

The number 18997161173 is odd. The largest value reached is three
times that, plus 1, which is 56991483520.

Yes, my mistake.
I only looked for maximal odd number in the sequence. Forgot about
even numbers.

Yes, I realized that, after the fact.

Something like int64_t would be safer.

Using unsigned long long is safer still, and easier, because there
is no need for hoop-jumping to print them out with printx.

I explained the reason in the reply to Richard Heathfield.

Yes I saw that. Part of my motivation for the comment is to
augment the knowledge of those who aren't sure.

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

Michael S <already5chosen@yahoo.com> writes:

On Tue, 18 Mar 2025 21:38:55 -0400
DFS <nospam@dfs.com> wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

It is not an interesting programming exercise. But it looks to me as a challenging math exercise. I mean, how could we give a not too
pessimistic estimate for upper bound of length of the sequence that
starts at given n without running a full sequence? Or estimate for
maximal value in the sequence?
So far, I found no answers.

You may console yourself with the knowledge that no one else
has either, even some of the most brilliant mathematicians
of the last hundred years. In fact it isn't even known that
all starting points eventually terminate; as far as what has
been proven goes, some starting points might just keep going
up forever.

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

On 20/03/2025 13:36, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am >>>> sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why
not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values,
then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
on 64-bit ones.

So long can't be used in programs intended to be portable to
other operating systems.

As defined by Unix/Linux, long is not portable between different
Unix/Linux OSes if they run on a different architecture.

As defined by Microsoft, long is portable between Windows OSes even on different architectures.

'long long' is defined as a 64-bit

type in both Windows and Linux.

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular implementation. No useful implementation would fail to define
uint64_t in these modern times.

The point was made earlier on that int64_t types are awkward to work
with; they need that stdint.h header to even exist, and they need those
ugly macros in inttypes.h to print out their values.

This is why it popular to just do:

typedef long long int i64;

and to use %lld to print, and -LL on literals to force a 64-bit type.

stdint.h et al are just ungainly bolt-ons, not fully supported by the
language.

The problem with 'long' manifests itself there too, since on Linux,
'int64_t' appears to be commonly defined on top of 'long' for 32-bit
systems, and 'long long' for 64-bit ones.

So somebody eschewing those ugly macros and using "%ld" to print an
'int64_t' type, will find it doesn't work when run on a 64-bit system,
where "%lld" is needed. Same problem with using '1L' to define an
int64_t literal.

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

On 20/03/2025 13:06, Tim Rentsch wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

<snip>

I'm not sure a new edition is necessary, but if it is to be
written it would be better served by someone like Keith or Tim,
both of whom have (as I have not) kept up with the million-and-one
changes that appear to have assailed the simple language I once
enjoyed.

The C99 standard has a list of 54 what it calls "major changes",
although IMO many or most of those are fairly minor. There are also
other differences relative to C90, but most of them are simply
clarifications or slight changes in wording.

Those I largely recall from discussions at the time, but I dare
to conclude that your lack of a reference to C11, C17, and C23
means that they had a lesser effect on the language than I'd feared.

I see now from casual research that C17 was predominantly a bug
fix, but that C11 and C23 were somewhat busier.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am >>> sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why
not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values,
then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

So long can't be used in programs intended to be portable to
other operating systems. 'long long' is defined as a 64-bit
type in both Windows and Linux.

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular implementation. No useful implementation would fail to define
uint64_t in these modern times.

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

On Thu, 20 Mar 2025 13:36:43 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type
that I am sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then
why not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values,
then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

So long can't be used in programs intended to be portable to
other operating systems. 'long long' is defined as a 64-bit
type in both Windows and Linux.

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular implementation. No useful implementation would fail to define
uint64_t in these modern times.

Unfortunately, gcc people made a mess out of it as well, defining (on
64-bit Linux platforms) int64_t/uint64_t as aliases to respective 'long'
types instead of aliasing them to 'long long', to be the same on all
platforms that matter.
I'd guess they were afraid of being accused of being sensible.

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

bart <bc@freeuk.com> writes:

On 20/03/2025 13:36, Scott Lurndal wrote:

then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
on 64-bit ones.

That's what I said. Thanks for the confirmation. It doesn't change
the fact that Microsoft didn't define long as 64-bit on 64-bit architectures, creating incompatibilities that didn't exist in the 32-bit world
between the two dominant operating systems.

Remainder of bart's typical windows-centric complaints elided.

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

On Thu, 20 Mar 2025 13:36:43 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am >>>> sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why
not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values,
then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux

Probably for backwards compatibility with 32 bit code that did bit twiddling with longs.

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

On Thu, 20 Mar 2025 13:27:36 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:

I see now from casual research that C17 was predominantly a bug
fix, but that C11 and C23 were somewhat busier.

As far as basic language is concerned, the biggest change in C23 is
the meaning of declaration 'bar_t foo()'. In C23 it is an equivalent of
'bar_t foo(void)', like in C++.

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

On Thu, 20 Mar 2025 14:00:29 +0000
bart <bc@freeuk.com> wibbled:

On 20/03/2025 13:36, Scott Lurndal wrote:

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular
implementation. No useful implementation would fail to define
uint64_t in these modern times.

The point was made earlier on that int64_t types are awkward to work
with; they need that stdint.h header to even exist, and they need those
ugly macros in inttypes.h to print out their values.

I've never found them awkward to work with and every *nix I've ever developed on had stdint.h. If Windows doesn't thats Window's problem.

This is why it popular to just do:

typedef long long int i64;

Popular maybe in WindowsWorld. Why as a unix dev would I do that when
standard typedefs already exist for this exact purpose?

stdint.h et al are just ungainly bolt-ons, not fully supported by the >language.

Whats that supposed to mean? The core language itself supports very little.
Do you not use libraries at all?

So somebody eschewing those ugly macros and using "%ld" to print an

What makes you think they're macros?

MacOS:
stdint.h
_types/_uint64_t.h
typedef unsigned long long uint64_t;
Linux:
stdint.h
#if __WORDSIZE == 64
typedef unsigned long int uint64_t;
#else
__extension__
typedef unsigned long long int uint64_t;
#endif

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

On Thu, 20 Mar 2025 14:50:25 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

What makes you think they're macros?

PRIu64 and PRId64 are macros. They are ugly.
I don't agree with people that call int64_t ugly, but PRIxN is
different.

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

On 20/03/2025 14:32, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 13:36, Scott Lurndal wrote:

then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
on 64-bit ones.

That's what I said. Thanks for the confirmation. It doesn't change
the fact that Microsoft didn't define long as 64-bit on 64-bit architectures, creating incompatibilities that didn't exist in the 32-bit world
between the two dominant operating systems.

Remainder of bart's typical windows-centric complaints elided.

But your typical anti-Microsoft remarks are fine? Since you called it a 'mistake' to keep 'long' the same between 32/64-bit machines, even
though both OSes kept 'int' the same.

It was just a choice.

Actually, my remarks didn't criticise either MS or Linux; just stated
some facts. I did criticise STDINT types.

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

On Thu, 20 Mar 2025 16:59:14 +0200
Michael S <already5chosen@yahoo.com> wibbled:

On Thu, 20 Mar 2025 14:50:25 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

What makes you think they're macros?

PRIu64 and PRId64 are macros. They are ugly.

Never even heard of them. Looking them up I can't see much use for them
frankly except if you're starting out on an unknown system and can't find out the info any other way which would be ... odd.

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

On Thu, 20 Mar 2025 15:16:05 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

On Thu, 20 Mar 2025 16:59:14 +0200
Michael S <already5chosen@yahoo.com> wibbled:

On Thu, 20 Mar 2025 14:50:25 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

What makes you think they're macros?

PRIu64 and PRId64 are macros. They are ugly.

Never even heard of them. Looking them up I can't see much use for
them frankly except if you're starting out on an unknown system and
can't find out the info any other way which would be ... odd.

Then how exactly do you printf value of type int64_t in a code that
expected to pass [gcc] compilation with no warnings on two platforms,
one of which is 64-bit Unix/Linux and another is just about anything
else?

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

On 20/03/2025 14:50, Muttley@DastardlyHQ.org wrote:

On Thu, 20 Mar 2025 14:00:29 +0000
bart <bc@freeuk.com> wibbled:

On 20/03/2025 13:36, Scott Lurndal wrote:

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular
implementation. No useful implementation would fail to define
uint64_t in these modern times.

The point was made earlier on that int64_t types are awkward to work
with; they need that stdint.h header to even exist, and they need those
ugly macros in inttypes.h to print out their values.

I've never found them awkward to work with and every *nix I've ever developed on had stdint.h. If Windows doesn't thats Window's problem.

stdint.h is part of a C compiler; it's nothing to do with Windows. My
remark was about having to write '#include <stdio.h>' on each one of the
100 modules of your project if you want tto use basic language data types.

That's unusual among mainstream languages.

This is why it popular to just do:

typedef long long int i64;

Popular maybe in WindowsWorld. Why as a unix dev would I do that when standard typedefs already exist for this exact purpose?

They're popular everywhere:

typedef uint32_t Uint32; // from SDL2

typedef unsigned int GLuint; // from OpenGL

typedef unsigned int l_uint32; // from Lua

typedef unsigned int mz_uint32; // from MiniZ compression lib

typedef uint32_t stbi__uint32; // from STB image library

typedef uint8_t byte; // from arduino.h

#ifndef UINT32_TYPE // from SQLite3
# ifdef HAVE_UINT32_T
# define UINT32_TYPE uint32_t
# else
# define UINT32_TYPE unsigned int
# endif
#endif

While GTK2 uses guint32 instead of uin32_t (sorry I didn't have time to
locate the correct header out of the nearly 700; this is from: https://docs.gtk.org/glib/types.html#guint32)

Pretty much every other open source project I look likes to define their
own types!

So I have to ask, why do think they do that?

stdint.h et al are just ungainly bolt-ons, not fully supported by the
language

Whats that supposed to mean? The core language itself supports very little. Do you not use libraries at all?

Literal suffixes such as -L and -ULL are in the core language, and each
'L' refers to 'long'.

While printf format modifers such as "l"s in "%lld" are well-established
in those sets of library routines. They do not directly supported stdint
types (I think C23 may do something about that).

Lots of horrible-looking macros that few even know about are supposed to
be used. So people instead use l/ll or L/LL and cross their fingers.

So somebody eschewing those ugly macros and using "%ld" to print an

What makes you think they're macros?

MacOS:
stdint.h
_types/_uint64_t.h
typedef unsigned long long uint64_t;

I didn't say they're macros. I said the types are defined on top the
regular types, and macros are needed to print their values.

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

On Thu, 20 Mar 2025 17:29:22 +0200
Michael S <already5chosen@yahoo.com> wibbled:

On Thu, 20 Mar 2025 15:16:05 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

On Thu, 20 Mar 2025 16:59:14 +0200
Michael S <already5chosen@yahoo.com> wibbled:

On Thu, 20 Mar 2025 14:50:25 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

What makes you think they're macros?

PRIu64 and PRId64 are macros. They are ugly.

Never even heard of them. Looking them up I can't see much use for
them frankly except if you're starting out on an unknown system and
can't find out the info any other way which would be ... odd.

Then how exactly do you printf value of type int64_t in a code that
expected to pass [gcc] compilation with no warnings on two platforms,
one of which is 64-bit Unix/Linux and another is just about anything
else?

Just use %llu everywhere. Warnings only matter if they're important ones.

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

On Thu, 20 Mar 2025 15:40:20 +0000
bart <bc@freeuk.com> wibbled:

On 20/03/2025 14:50, Muttley@DastardlyHQ.org wrote:

On Thu, 20 Mar 2025 14:00:29 +0000
bart <bc@freeuk.com> wibbled:

On 20/03/2025 13:36, Scott Lurndal wrote:

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular
implementation. No useful implementation would fail to define
uint64_t in these modern times.

The point was made earlier on that int64_t types are awkward to work
with; they need that stdint.h header to even exist, and they need those
ugly macros in inttypes.h to print out their values.

I've never found them awkward to work with and every *nix I've ever developed

on had stdint.h. If Windows doesn't thats Window's problem.

stdint.h is part of a C compiler; it's nothing to do with Windows. My
remark was about having to write '#include <stdio.h>' on each one of the
100 modules of your project if you want tto use basic language data types.

Or you could just include your own header that pulls in all the system ones
and has all your own definitions too. Thats what most people do.

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

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

I guess some maths problems can't be proven directly, they have to be - for want of a better word - run. A bit like the halting problem in CS.

The halting problem is a perfect example of a problem which *cannot* be
proven by running anything.

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

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

On Thu, 20 Mar 2025 16:14:54 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

I guess some maths problems can't be proven directly, they have to be - for >> want of a better word - run. A bit like the halting problem in CS.

The halting problem is a perfect example of a problem which *cannot* be >proven by running anything.

So if you run the program and it halts that doesn't prove that it will halt? Umm, ok.

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

On 2025-03-20, Scott Lurndal <scott@slp53.sl.home> wrote:

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

long was once useful for avoiding the predicament int is as few as
16 bits wide on some systems.

This is an almost entirely obsolete concern.

In code that assumes int >= 32 bits, but is otherwise intended
to be portable, long serves no purpose.

In comp.lang.c, we use long for anything that needs to go
beyond 32767, but not beyond 2147483647. :)

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

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

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

On Thu, 20 Mar 2025 16:14:54 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

I guess some maths problems can't be proven directly, they have to be - for >>> want of a better word - run. A bit like the halting problem in CS.

The halting problem is a perfect example of a problem which *cannot* be >>proven by running anything.

So if you run the program and it halts that doesn't prove that it will halt? Umm, ok.

If you run a program and it has NOT halted so far, you don't know
whether or not it halts. If it doesn't halt, you will wait forever. To
figure that out, you have to resort to proof techniques, not just more
waiting.

Determining whether one program halts or not is not even the Halting
Problem. The Halting Problem consists of the question: is there an
algorithm which can decide, for any <P, I> (program, input) pairs from
the universe of all possible programs and inputs, whether P(I) halts.

The accepted result is that, no, there is no such decision algorithm.
In short, the halting question is called undecidable.

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

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

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am >>> sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect.

To me it does not. The table lists minimum values for all
implementations, and not the most common values for typical
implementations.

If 'int' doesn't need to store values beyond 16 bits, then
why not use 'short'?

I expect any developer who has spent even a fairly short time
learning C and writing C code knows the answer to this question,
and does not need to consult the table shown above to make an
appropriate choice between 'int' and 'short' in each of the
circumstances where the question may occur.

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

Richard Heathfield <rjh@cpax.org.uk> writes:

On 20/03/2025 13:06, Tim Rentsch wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

<snip>

I'm not sure a new edition is necessary, but if it is to be
written it would be better served by someone like Keith or Tim,
both of whom have (as I have not) kept up with the million-and-one
changes that appear to have assailed the simple language I once
enjoyed.

The C99 standard has a list of 54 what it calls "major changes",
although IMO many or most of those are fairly minor. There are also
other differences relative to C90, but most of them are simply
clarifications or slight changes in wording.

Those I largely recall from discussions at the time, but I dare to
conclude that your lack of a reference to C11, C17, and C23 means that
they had a lesser effect on the language than I'd feared.

I chose C99 (and C99 only) because it is the first step after C90,
and because I think C99 is more common than any other variant.
There is also the question of how much material to present, and how
much time would be needed to prepare a faithful summary. I didn't
want to overwhelm people, and I didn't want to be overwhelmed
myself, not because of how many changes are involved, but due to the
effort need to sift through and organize them. I didn't look at the
C11 standard, nor any subsequent versions of the standard, before
making the decision to do just C99.

As it turn out, the C11 standard lists only 15 "major changes" (if
my quick counting is correct), so your conclusion that later
versions have had a lesser effect appears to be correct, at least as
far as C11 goes. If I have time I may post again on this topic,
doing for the C11 standard what I did for the C99 standard.

I see now from casual research that C17 was predominantly a bug fix,
but that C11 and C23 were somewhat busier.

Looking quickly over the listed changes in C11, I count only six or
seven that I would put on the same level as the ones I gave for C99.

My understanding of what was done in the C17 standard agrees with
your casual research, except I might have said "almost entirely"
rather than "predominantly".

I have not spent nearly as much time looking at the C23, especially
in comparison with C99 or C11. Based on what little I do know about
C23, I consider that version of C to be one best avoided, for at
least a decade and perhaps more. I may have more to say about that
at some point in the future but do not have anything right now.

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

On Thu, 20 Mar 2025 15:40:20 +0000
bart <bc@freeuk.com> wrote:

Pretty much every other open source project I look likes to define
their own types!

So I have to ask, why do think they do that?

Most likely mindless parroting of 40 y.o. examples.

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

On 20/03/2025 18:24, Tim Rentsch wrote:

<snip>

My understanding of what was done in the C17 standard agrees with
your casual research, except I might have said "almost entirely"
rather than "predominantly".

I have not spent nearly as much time looking at the C23, especially
in comparison with C99 or C11. Based on what little I do know about
C23, I consider that version of C to be one best avoided, for at
least a decade and perhaps more. I may have more to say about that
at some point in the future but do not have anything right now.

Thank you for your reply, which as ever was cogent and highly
informative.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

Michael S <already5chosen@yahoo.com> writes:

On Thu, 20 Mar 2025 15:16:05 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

On Thu, 20 Mar 2025 16:59:14 +0200
Michael S <already5chosen@yahoo.com> wibbled:

On Thu, 20 Mar 2025 14:50:25 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

What makes you think they're macros?

PRIu64 and PRId64 are macros. They are ugly.

Never even heard of them. Looking them up I can't see much use for
them frankly except if you're starting out on an unknown system and
can't find out the info any other way which would be ... odd.

Then how exactly do you printf value of type int64_t in a code that
expected to pass [gcc] compilation with no warnings on two platforms,
one of which is 64-bit Unix/Linux and another is just about anything
else?

If I needed to print such a value using printf(), I would most
likely do something like this:

typedef signed long long SLL;
typedef unsigned long long ULL;

...

printf( " the value of x64 is: %lld\n", (SLL){ x64 } );

and avoid the use of the <inttypes.h> macros altogether (not
to mention making the code more resilient against changes in
the type of x64).

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

On 20/03/2025 18:46, Michael S wrote:

On Thu, 20 Mar 2025 15:40:20 +0000
bart <bc@freeuk.com> wrote:

Pretty much every other open source project I look likes to define
their own types!

So I have to ask, why do think they do that?

Most likely mindless parroting of 40 y.o. examples.

I don't think so. Where such sets of types exist, they tend to be
defined on top of long long too, or even on top of stdint.h types.

Look at this one for example:

typedef uint8_t byte; // from arduino.h

I can only one of reason this exists, which is that 'byte' is a far
nicer denotation.

You might also consider why such examples existed even 40 years ago.

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

On 2025-03-20, bart <bc@freeuk.com> wrote:

On 20/03/2025 18:46, Michael S wrote:

On Thu, 20 Mar 2025 15:40:20 +0000
bart <bc@freeuk.com> wrote:

Pretty much every other open source project I look likes to define
their own types!

So I have to ask, why do think they do that?

Most likely mindless parroting of 40 y.o. examples.

I don't think so. Where such sets of types exist, they tend to be
defined on top of long long too, or even on top of stdint.h types.

Look at this one for example:

typedef uint8_t byte; // from arduino.h

I can only one of reason this exists, which is that 'byte' is a far
nicer denotation.

That's actually a bad way to define byte. You want

typedef unsigned char byte;

That's because "unsigned char" is blessed by the language spec with
certain properties that it behooves you to confer onto your "byte".

You can alias an object with an arrays of unsigned char, and
certain things hold, which do not hold if you use uint8_t.
uint8_t is subject to strict aliasing rules.

(Under the hood, an implementation may just have uint8_t as a typedef
for unsigned char, but that's not required.)

You might also consider why such examples existed even 40 years ago.

Mostly it's poor programmers who can't wrap their head around using
a type whose exact size is not known.

If you're not programming hardware or conforming to external storage
or packet formats, you don't need crap like int32 or uint64.

It's an embarrassing blemish on Rust that they made their principal
integer types like this; it makes all Rust code look idiotically
hardware dependent. You can't code an abstract algorithm out of
Sedgewick, Knuth or Cormen in Rust without peppering the code with
distracting 32's and 64's.



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

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

On Thu, 20 Mar 2025 19:58:37 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

It's an embarrassing blemish on Rust that they made their principal
integer types like this; it makes all Rust code look idiotically
hardware dependent. You can't code an abstract algorithm out of
Sedgewick, Knuth or Cormen in Rust without peppering the code with distracting 32's and 64's.

If size suffixes make you nervous, Rust has equivalents of size_t and ptrdiff_t. Named, respectively, usize and isize.
But you probably know it.

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

On 20/03/2025 19:10, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

This is why it popular to just do:

typedef long long int i64;

and to use %lld to print, and -LL on literals to force a 64-bit type.

Is it? I don't recall seeing anyone other than you do that.

stdint.h et al are just ungainly bolt-ons, not fully supported by the
language.

No, they're fully supported by the language. They've been in the ISO standard since 1999.

I don't think so. They are add-ons that could have been created in
user-code even prior to C99 (user-defined typedefs for 64 bits would
'need long long').

All that's happened is that 'stdint.h' has been blessed.

You wouldn't, in user-code, be able to invent new literal suffixes like
-LL but for those new types.

And you wouldn't be able to get the *printf functions of your standard
library to accept new format codes corresponding to those stdint types.

And in fact you can do neither of those things now; ergo they're not
fully supported in the same way that 'char short int long' are.

The problem with 'long' manifests itself there too, since on Linux,
'int64_t' appears to be commonly defined on top of 'long' for 32-bit
systems, and 'long long' for 64-bit ones.

If you're writing code for which that's a problem, you probably need to
fix your code.

So somebody eschewing those ugly macros and using "%ld" to print an
'int64_t' type, will find it doesn't work when run on a 64-bit system,
where "%lld" is needed. Same problem with using '1L' to define an
int64_t literal.

Somebody writing blatantly non-portable code will run into problems when
they try to port it.

I understand that you dislike <stdint.h>. That's both perfectly
acceptable and not very interesting.

I dislike it because this stuff it is not hard to do in a language with
full support, but C always seems to make a dog's dinner of it:

C Other (example)

Declare uint64_t x; u64 x
Literal UINT64_C(123); 123
Print printf(PRI64d, x); print x
(Alt?) printf("I64d", x);
Max of type UINT64_MAX u64.max
Max of expr (1) x.max
Read scanf(SCNd64...) read x

Requires: stdio.h (for printf/scanf)
stdint.h (for uint64_t/UINT64_C)
inttypes.h (for PRI64d/SCNd64)

((1) I believe not possible without using 'typeof' and _Generic to emulate)

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

On 2025-03-20, Michael S <already5chosen@yahoo.com> wrote:

On Thu, 20 Mar 2025 19:58:37 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

It's an embarrassing blemish on Rust that they made their principal
integer types like this; it makes all Rust code look idiotically
hardware dependent. You can't code an abstract algorithm out of
Sedgewick, Knuth or Cormen in Rust without peppering the code with
distracting 32's and 64's.

If size suffixes make you nervous, Rust has equivalents of size_t and ptrdiff_t. Named, respectively, usize and isize.
But you probably know it.

I do, and I've seen code using size and usize for quantities that are
not sizes of any kind. While it's better than a hardware depenendcy
like i64, it's terrible naming. Make an alias called "int"
for "size" and you're there.

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

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

On 20/03/2025 23:18, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 19:10, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

[...]

stdint.h et al are just ungainly bolt-ons, not fully supported by the
language.

No, they're fully supported by the language. They've been in the ISO
standard since 1999.

I don't think so. They are add-ons that could have been created in
user-code even prior to C99 (user-defined typedefs for 64 bits would
'need long long').

Sure, they could; see Doug Gwyn's q8, for example.

Isn't that what I said? However I've just looked at this 700-line header:

https://www.lysator.liu.se/c/q8/stdint.h

Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types. (And if this is for a multitude of
targets, then there should be a dedicated header per target).

GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
of the core language, it would be zero lines.

All that's happened is that 'stdint.h' has been blessed.

I.e., it was made part of the language, specifically the standard
library that's part of the language standard. Which is what I said,
but for some reason you disagreed.

It's not tied into the core language which has char/short/int and
controls integer width with 'longs', in denotations, suffixes and format specifier codes.

Yes, the format specifiers are a bit awkward. Boo hoo.

They're a lot awkward. They're awkward enough for the built-in types,
and it gets worse for the bolted-on types.

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

Richard Heathfield <rjh@cpax.org.uk> writes:

On 20/03/2025 18:24, Tim Rentsch wrote:

<snip>

My understanding of what was done in the C17 standard agrees with
your casual research, except I might have said "almost entirely"
rather than "predominantly".

I have not spent nearly as much time looking at the C23, especially
in comparison with C99 or C11. Based on what little I do know about
C23, I consider that version of C to be one best avoided, for at
least a decade and perhaps more. I may have more to say about that
at some point in the future but do not have anything right now.

Thank you for your reply, which as ever was cogent and highly
informative.

Just be thankful my response wasn't typed during a full moon. ;)

(More seriously: I appreciate the compliment.)

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

On 2025-03-20, bart <bc@freeuk.com> wrote:

On 20/03/2025 23:18, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 19:10, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

[...]

stdint.h et al are just ungainly bolt-ons, not fully supported by the >>>>> language.

No, they're fully supported by the language. They've been in the ISO
standard since 1999.

I don't think so. They are add-ons that could have been created in
user-code even prior to C99 (user-defined typedefs for 64 bits would
'need long long').

Sure, they could; see Doug Gwyn's q8, for example.

Isn't that what I said? However I've just looked at this 700-line header:

https://www.lysator.liu.se/c/q8/stdint.h

Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types.

That's not all that is needed; the material in Q8defs.h is required
to make the material in the above file work.

It's not just the types, but all the standard-required identifiers.

I feel that this Q8 could probably have been organized a little
differently to make it more compact.

The Q8defs.h header already has conditionals for platforms.
Then Q8's inttypes.h still has to switch on some more abstract
conditions in the preprocessor to select the types.

This two layer business could just be one, more or less.
Q8defs.h could just define, for instance, q8_uintptr_t,
for each platform, and then inttypes just has to expose it under the
standard name:

typedef q8_uintptr_t uintptr_t;

(And if this is for a multitude of
targets, then there should be a dedicated header per target).

What? That would pretty much defeat the whole point of this Q8 library.

What would would select which file to use where?

You drop those files into your C90, and then you have a facsimile
of C99 compatibility, on all the platforms supported by Q8.

GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part

Q8 tries to add the C99 stuff for something like 7 implementations
or implementation familes. GCC is one implementation, but with
many targets.

of the core language, it would be zero lines.

This kind of argumentation is really not of good quality.

A feature requires lines of code. If those lines are not in some
satellite file like a C header, then they are elsewhere, like in the
compiler source code.

It's not "zero lines" because you hid it in the compiler.

Shoving into a compiler that which can very well live outside of it
isn't even categorically a good idea.

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

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

On 21/03/2025 00:46, Kaz Kylheku wrote:

On 2025-03-20, bart <bc@freeuk.com> wrote:

On 20/03/2025 23:18, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 19:10, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

[...]

stdint.h et al are just ungainly bolt-ons, not fully supported by the >>>>>> language.

No, they're fully supported by the language. They've been in the ISO >>>>> standard since 1999.

I don't think so. They are add-ons that could have been created in
user-code even prior to C99 (user-defined typedefs for 64 bits would
'need long long').

Sure, they could; see Doug Gwyn's q8, for example.

Isn't that what I said? However I've just looked at this 700-line header:

https://www.lysator.liu.se/c/q8/stdint.h

Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types.

That's not all that is needed; the material in Q8defs.h is required
to make the material in the above file work.

It's not just the types, but all the standard-required identifiers.

I feel that this Q8 could probably have been organized a little
differently to make it more compact.

The Q8defs.h header already has conditionals for platforms.
Then Q8's inttypes.h still has to switch on some more abstract
conditions in the preprocessor to select the types.

This two layer business could just be one, more or less.
Q8defs.h could just define, for instance, q8_uintptr_t,
for each platform, and then inttypes just has to expose it under the
standard name:

typedef q8_uintptr_t uintptr_t;

(And if this is for a multitude of
targets, then there should be a dedicated header per target).

What? That would pretty much defeat the whole point of this Q8 library.

What would would select which file to use where?

You drop those files into your C90, and then you have a facsimile
of C99 compatibility, on all the platforms supported by Q8.

GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part

Q8 tries to add the C99 stuff for something like 7 implementations
or implementation familes. GCC is one implementation, but with
many targets.

I just tried to compile it; it needs an extra q8defs.h file (600 more
lines), but it fails: "CPU not recognised" (it might have a point if
this was from the 1990s!).

gcc just gives lots of errors. To me it's all an ugly lot of code which
reminds me of what system headers looked like: a messy, fragile
patchwork of #ifdef blocks.

of the core language, it would be zero lines.

This kind of argumentation is really not of good quality.

A feature requires lines of code. If those lines are not in some
satellite file like a C header, then they are elsewhere, like in the
compiler source code.

Doing stuff the C way requires LOTs of lines of code. Look at all those
MIN/MAX macros, the PRINT/SCAN macros; there's hundreds of them!

In the compiler it can be compact (and faster, not having to parse such
headers millions and millions of times), and if the language was done
properly, much of it is not needed. For example I showed in another post
that all MIN/MAX macros can be replaced with T.min and T.max, or
equivalent syntax.

It's not "zero lines" because you hid it in the compiler.

The compile has to cope with fundamental types anyway; there's a limit
to what headers can do: they have to build on something.

This is about defining fixed-width types on top of the
implementation-defined 'char short int long' types.

I've done this and it's usually a dozen lines. If it takes 1300 lines,
then you need to look again:

typedef signed char i8;
typedef short i16;
typedef int i32;
typedef long long i64;

typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
typedef unsigned long long u64;

typedef unsigned char byte;

typedef float r32;
typedef double r64;

(This is used at the top of generated code, to keep the rest of it
somewhat more compact and readable. Such a file actually uses zero
headers including no standard headers.)

I don't bother with LEAST/FAST types, whatever those mean. Where did
that all come from anyway? I've never seen those used.

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Michael S <already5chosen@yahoo.com> writes:

On Tue, 18 Mar 2025 21:38:55 -0400
DFS <nospam@dfs.com> wrote:

I'm doing these algorithm problems at
https://cses.fi/problemset/list/

For instance: Weird Algorithm
https://cses.fi/problemset/task/1068

It is not an interesting programming exercise. But it looks to me
as a challenging math exercise. I mean, how could we give a not
too pessimistic estimate for upper bound of length of the sequence
that starts at given n without running a full sequence? Or
estimate for maximal value in the sequence? So far, I found no
answers.

You may console yourself with the knowledge that no one else
has either, even some of the most brilliant mathematicians
of the last hundred years. In fact it isn't even known that
all starting points eventually terminate; as far as what has
been proven goes, some starting points might just keep going
up forever.

I think someone has mentioned that this is called the Collatz
Conjecture. According to Wikipedia, it's been shown to hold for
all positive integers up to 2.95e20 (which is just under 2**68).

Yes it is sometimes called the Collatz Conjecture, and sometimes
called the 3n+1 problem, and also is known by several other names.
I first heard the problem in the early 1980s (at that time it was
known as the (3n+1)/2 problem), and worked on it on and off for ten
years or so. I would be astonished if anyone disproved it.

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

On 21/03/2025 07:05, Tim Rentsch wrote:

I would be astonished if anyone disproved it.

If anyone does, my money's on Noam Elkies.

<https://blog.computationalcomplexity.org/2003/04/counterexample-to-fermats-last-theorem.html>


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On Thu, 20 Mar 2025 16:49:10 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

On Thu, 20 Mar 2025 16:14:54 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

I guess some maths problems can't be proven directly, they have to be - >for
want of a better word - run. A bit like the halting problem in CS.

The halting problem is a perfect example of a problem which *cannot* be >>>proven by running anything.

So if you run the program and it halts that doesn't prove that it will halt? >> Umm, ok.

If you run a program and it has NOT halted so far, you don't know
whether or not it halts. If it doesn't halt, you will wait forever. To

True, but you said it cannot be proven. What you meant was it cannot *always* be proven to halt.

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

On 21/03/2025 01:47, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

You're complaining about how much work it is. All that work
has been done for you by the implementers. Decades ago.

We are talking about defining types like 'int32' on top of 'char short
int long', yes? Then how difficult could it possibly be?

I just
did a quick test comparing complation times for an empty program
with no #include directives and an empty program with #include
directives for <stdint.h> and <inttypes.h>. The difference was
about 3 milliseconds. I quite literally could not care care less.

I'm sorry but that's a really poor attitude, with bad consequences.
You're saying it doesn't matter how complex a header or set of headers
is, even when out of proportion to the task.

But this is why we end up with such complicated headers.

Take the GTK2 library with hundreds of header files. The compiler has to process all that, for each module that includes GTK (specifically,
350Kloc across 550 unique headers via ~1000 #includes).

That's a lot of work, and leads to poor solutions like PCH, which are
specific to certain compilers.

But I happen to know that all those declarations could be flattened into
a single 25Kloc header file (I don't mean just using -E; all #defines
are retained for example).

While the 75 headers and 50K lines of SDL2 reduce to one 3Kloc header.
Much easier to manage one interface file! And quicker to compile.

So, why isn't that routinely done by the purveyors of libraries? (Or is everyone who downloads the GTK /headers/ for example keen to do their
own development!)

The user of the ONE library doesn't care about the internal structure of
the header files.

I think your response clarifies matters. Nobody cares, even as compilers
grind to a halt under all preprocessing.

Doing stuff the C way requires LOTs of lines of code. Look at all
those MIN/MAX macros, the PRINT/SCAN macros; there's hundreds of them!

So what? I don't have to read those lines of code. All I have to read
is the standard (or some other document) that tells me how to use it.

It is crass. But it also affects the programmer because they have to
explicitly include that specific header and then remember the dedicated
MIN/MAX macros for the specific type. And they have to /know/ the type.

If the type is opaque, or is an alias, then they won't know the name of
the macro. If the typedef is 'T' for example, then what's the macro for
its MAX value? Which header will they need?

In a certain language I use, it will be T.max (and there are no
headers). I'm not suggesting that C turns into that language, only that somebody acknowledges the downsides of using C's approach, since again
nobody cares.

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

On 2025-03-21, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

On Thu, 20 Mar 2025 16:49:10 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:

On Thu, 20 Mar 2025 16:14:54 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:

On 2025-03-20, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote: >>>>> I guess some maths problems can't be proven directly, they have to be - >>for

want of a better word - run. A bit like the halting problem in CS.

The halting problem is a perfect example of a problem which *cannot* be >>>>proven by running anything.

So if you run the program and it halts that doesn't prove that it will halt?
Umm, ok.

If you run a program and it has NOT halted so far, you don't know
whether or not it halts. If it doesn't halt, you will wait forever. To

True, but you said it cannot be proven. What you meant was it cannot *always* be proven to halt.

Running a program can only prove those programs which terminate
within a time period you're willing to wait. For all others, this
approach produces no answer: it remains undecided.

You don't seem to know what is the Halting Problem in CS; it is
the informal name for the question whether there exists an
algorithm which can prove that any program operating on any
input (i.e. any Turing computation) will halt or not.

The question "will this small C program halt, which obviously contains
no loops or recursion, so we know that it does" is not an instance of
the Halting Problem. (It is one input case in the Halting Problem,
among an infinity of cases.)

Running programs is not a decision procedure that solves the Halting
Problem.

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

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

bart <bc@freeuk.com> wrote:

On 20/03/2025 13:36, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am >>>>> sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why
not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values,
then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
on 64-bit ones.

So long can't be used in programs intended to be portable to
other operating systems.

As defined by Unix/Linux, long is not portable between different
Unix/Linux OSes if they run on a different architecture.

It portably between 32 and 64 bit machines gives word-sized
integer type.

As defined by Microsoft, long is portable between Windows OSes even on different architectures.

It gives 'long' different meaning than it had previously. And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.

'long long' is defined as a 64-bit

type in both Windows and Linux.

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular
implementation. No useful implementation would fail to define
uint64_t in these modern times.

<snip>

The problem with 'long' manifests itself there too, since on Linux,
'int64_t' appears to be commonly defined on top of 'long' for 32-bit
systems, and 'long long' for 64-bit ones.

You mixed up this: 'int64_t' is defined as 'long long' for 32-bit
systems and as 'long' for 64-bit ones. Doing it as you wrote
would give you variable length type. Of course, if you need
word-sized integer in Windows you may define it as 'long' for 32-bit
Windows and as 'long long' for 64-bit ones.

--
Waldek Hebisch

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

On 2025-03-21, Waldek Hebisch <antispam@fricas.org> wrote:

bart <bc@freeuk.com> wrote:

On 20/03/2025 13:36, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am >>>>>> sure about.

The width of char and [un]signed char must be at least 8 bits.
The width of [un]signed short must be at least 16 bits.
The width of [un]signed int must be at least 16 bits.
The width of [un]signed long must be at least 32 bits.
The width of [un]signed long long must be at least 64 bits.

That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why >>>> not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values,
then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
on 64-bit ones.

So long can't be used in programs intended to be portable to
other operating systems.

As defined by Unix/Linux, long is not portable between different
Unix/Linux OSes if they run on a different architecture.

It portably between 32 and 64 bit machines gives word-sized
integer type.

The bitness of modern mainstream machines is their address size.

C99 gaves us address-sized integers: intptr_t and uintptr_t.
If you want a 64 bit type on a 64 bit system and 32 bit type
on a 32 bit system, use those.

(The problem is that idea observed in Unix-like environments that long
is expected to be address-sized precedes C99.)

As defined by Microsoft, long is portable between Windows OSes even on
different architectures.

It gives 'long' different meaning than it had previously. And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.

In Microsoft land, there is a LONG type, which is involved in
the Win32 ABIs. That was their mistake.

In plenty of interfaces, Windows uses the types WORD and DWORD, which
are 16 and 32 bits wide unsigned types. (As well as QWORD,
a 64 bitter).

The problem is, when someone needed the signed versions of
WORD and DWORD, they found them to be missing, and stupidly came up with
the names INT and LONG (and derived typedefs like LPARAM).
Nobody caught this code smell and so it got woven into the Windows API. Probably long before 32 bit Windows, I'm guessing.

Thus, LONG has to continue to be a 32 bit type, since it is
used as a "signed DWORD".

But it's inconceivable for LONG to to be a typedef for anything other
than long. Too much code depends on the wrong idea that LONG and long
are interchangeable.

Thus long has to be stuck on 32 bits.

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

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

On 21/03/2025 17:51, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

As defined by Unix/Linux, long is not portable between different
Unix/Linux OSes if they run on a different architecture.

It portably between 32 and 64 bit machines gives word-sized
integer type.

Which was not its intention. (Probably intptr_t or ssize_t is better for
that purpose, and will be portable between Windows and Linux.)

As defined by Microsoft, long is portable between Windows OSes even on
different architectures.

It gives 'long' different meaning than it had previously.

I explained the differences without necessarily saying one is better
than the other. Sometimes one is more more useful, sometimes the other.

And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.

Well, 'long' is also useless on 32-bit Linux machines as it is the same
size as 'int'. Why didn't it also increase when 'int' migrated from i16
to i32?

One 'con' for Linux' approach is when someone assumes 'long' is i32;
when they run code on 64 bits, it will either be wasteful, or it could
go badly wrong.

While those running on Linux64 and expect 'long' to be double the width
of 'int', may also experience failures on Linux32.

On Windows, you just learn to avoid 'long' completely. After all you
don't need 5 basic types for four integer sizes!

'long long' is defined as a 64-bit

type in both Windows and Linux.

Using the defined width types is far better (e.g. uint64_t);
even if the standard allows the type to not exist on a particular
implementation. No useful implementation would fail to define
uint64_t in these modern times.

<snip>

The problem with 'long' manifests itself there too, since on Linux,
'int64_t' appears to be commonly defined on top of 'long' for 32-bit
systems, and 'long long' for 64-bit ones.

You mixed up this: 'int64_t' is defined as 'long long' for 32-bit
systems and as 'long' for 64-bit ones.

Sorry, yes. But it shows how confusing it all is:

LL/ll is used for 64 bits on 32-bit systems
L/l is used for 32 bits on 64-bit systems!

(I'm so glad I switched to all-64-bits in my own stuff, early last decade.

However lots of software has taken a long time to catch up. I acquired
an RPi 4 board 5 years ago with a view to doing 64-bit ARM development,
but most OSes were still 32 bits, and 64-bit ones immature. (You need a
64-bit OS to easily develop and run 64-bit programs.)

Even now, 32-bit OSes are supplied by default. I finally got a solid
64-bit OS for it last week. I just wondered what the point is of having
64-bit hardware if people just run 32-bit stuff on it.)

Doing it as you wrote
would give you variable length type. Of course, if you need
word-sized integer in Windows you may define it as 'long' for 32-bit
Windows and as 'long long' for 64-bit ones.

(I'll tell you a secret: my C compiler automatically reads a special
header that includes these definitions:

typedef signed char i8;
typedef short i16;
typedef int i32;
typedef long long int i64;

typedef unsigned char u8;
typedef unsigned char byte;
typedef unsigned short u16;
typedef unsigned int u32;
typedef unsigned long long int u64;

typedef float r32;
typedef double r64;

It makes the writing of hundreds of small test programs so much easier.
I wonder how many do the same, although they'd have to use a discrete
header.)

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

On 21/03/2025 19:04, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 21/03/2025 01:47, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
You're complaining about how much work it is. All that work
has been done for you by the implementers. Decades ago.

We are talking about defining types like 'int32' on top of 'char short
int long', yes? Then how difficult could it possibly be?

If you want <stdint.h> and <inttypes.h> headers that work correctly with
all relevant compilers, it's not particularly easy. I'll note that the
MUSL implementation of <stdint.h> is 117 lines, compared to 308 for GNU
libc.

I just
did a quick test comparing complation times for an empty program
with no #include directives and an empty program with #include
directives for <stdint.h> and <inttypes.h>. The difference was
about 3 milliseconds. I quite literally could not care care less.

I'm sorry but that's a really poor attitude, with bad
consequences. You're saying it doesn't matter how complex a header or
set of headers is, even when out of proportion to the task.

But this is why we end up with such complicated headers.

Complicated headers that work.

[...\

I think your response clarifies matters. Nobody cares, even as
compilers grind to a halt under all preprocessing.

If compilers ground to a halt, I would certainly care. They don't.

50 modules each including GTK.h say, which was 0.33Mloc across 500
headers (so reading 16Mloc and 25,000 headers in total when all are
compiled) would not impact your builds at all? OK.

But I expect if a major library supplier came out with the idea of a streamlined, compact one-file header that took 90% less compile-time,
that would be hailed as a brilliant advance!

Doing stuff the C way requires LOTs of lines of code. Look at all
those MIN/MAX macros, the PRINT/SCAN macros; there's hundreds of them!

So what? I don't have to read those lines of code. All I have to
read
is the standard (or some other document) that tells me how to use it.

It is crass. But it also affects the programmer because they have to
explicitly include that specific header and then remember the
dedicated MIN/MAX macros for the specific type. And they have to
/know/ the type.

Yes, of course.

If the type is opaque, or is an alias, then they won't know the name
of the macro. If the typedef is 'T' for example, then what's the macro
for its MAX value? Which header will they need?

There may not be one. For example, there's no format specifier for
time_t. If I need to print a time_t value, I'll probably cast to
intmax_t and use "%jd". If I'm being obsessive about portability, I'll
test whether time_t is signed, unsigned, or floating-point (all of which
are possible in principle), and use "%jd", "%ju", or "%Lf".

I wonder if you realise how utterly ridiculous all those incantations sound?

This is a C program using one of the extensions from my old compiler:

#include <stdio.h>
#include <time.h>

int main(void) {
time_t t = clock();
printf("%v\n", t); # (used to be '?'; changed to 'v')
}

The compiler replaces the 'v' format with a conventional format code
according to the type of the expression. For my 'time_t', it happens to
be 'lld'.

In a certain language I use, it will be T.max (and there are no
headers). I'm not suggesting that C turns into that language, only
that somebody acknowledges the downsides of using C's approach, since
again nobody cares.

I acknowledge the downsides of C's approach. See, all you had to
do was ask.

As Dennis Ritchie said, "C is quirky, flawed, and an enormous success".

So it's quirky and flawed.

It would be very nice if C had some kind of more generic I/O that
doesn't require remembering arbitrary format strings and qualifiers
for each type, and that doesn't provide format strings for a lot of
types in the standard library, and certainly not for types defined
in user code. And I'd *love* it if a future C standard removed
the undefined behavior for numeric input using *scanf(). Other C
programmers will have different priorities than yours or mine.

If I want to print a time_t value in C++, I just write
`std::cout << t` and the compiler figures out which overloaded
function to call.

That's amazing.

Scripting languages like Perl and Python have
print functions that take arguments of arbitrary types, and ways
to interpolate numeric values into string literals. And so on.

I'm not sure what would be the best way to add something like this
in C202y or C203z. There are arguments against adding too many new
features to C when other languages are available; if C became C++
Lite, a lot of programmers would just use C++. There are a number
of different approaches that could be taken, and choosing among
them is not trivial.

See above.

When I talk about how to work with C as it's currently defined,
you tend to see advocacy where it doesn't exist. When you complain
about things in C that I don't think are real problems, you tend
to assume that I'm saying C is perfect, something I've never said.
When you ask why something in C is defined the way it is, you don't acknowledge when people take the time to explain it.

This forum tends to not be critical of the language. But even if aspects
of it can't be changed, there's no reason not to call them out.

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

bart <bc@freeuk.com> wrote:

On 21/03/2025 17:51, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

As defined by Unix/Linux, long is not portable between different
Unix/Linux OSes if they run on a different architecture.

It portably between 32 and 64 bit machines gives word-sized
integer type.

Which was not its intention.

This was intention when 64-bit machines appeared.

(Probably intptr_t or ssize_t is better for
that purpose, and will be portable between Windows and Linux.)

Those did not exist in 1991 and would be needed only for small
machines. Except for Microsoft which decided to push its own,
different way.

As defined by Microsoft, long is portable between Windows OSes even on
different architectures.

It gives 'long' different meaning than it had previously.

I explained the differences without necessarily saying one is better
than the other. Sometimes one is more more useful, sometimes the other.

AFAICS your main trouble with 'long' is inconsistency. And the
inconsistency is due to Microsoft, as previously 'long' had
consitent definition on resonable machines: integer with max of
32 bits and word size, which simplified to word size on
"bigger" machines.

And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.

Well, 'long' is also useless on 32-bit Linux machines as it is the same
size as 'int'.

Not always. Motorola 68000 used 16-bit int. That was because
original 68000 had 16-bit bus which made 16-bit integers faster.

One 'con' for Linux' approach is when someone assumes 'long' is i32;
when they run code on 64 bits, it will either be wasteful, or it could
go badly wrong.

One 'con' of any assumption is that somebody can make a different
assumption.

(I'm so glad I switched to all-64-bits in my own stuff, early last decade.

However lots of software has taken a long time to catch up. I acquired
an RPi 4 board 5 years ago with a view to doing 64-bit ARM development,
but most OSes were still 32 bits, and 64-bit ones immature. (You need a 64-bit OS to easily develop and run 64-bit programs.)

I am not sure what was available for RPi 4. But in 2019 I got 64-bit
chinese ARM board and it was well supported by 64-bit Linux (armbian). Apparently Raspberry Pi foundation wanted to have the same OS on all
their boards (not only newest ones) so they delivered 32-bit OS for
some time after 64-bit board appeared. IIUC normal Linux distributions
rather quickly got 64-bit ARM versions.

Even now, 32-bit OSes are supplied by default. I finally got a solid
64-bit OS for it last week. I just wondered what the point is of having 64-bit hardware if people just run 32-bit stuff on it.)

See above.

--
Waldek Hebisch

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

bart <bc@freeuk.com> wrote:

Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types. (And if this is for a multitude of
targets, then there should be a dedicated header per target).

GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
of the core language, it would be zero lines.

You need few (say 3) lines of compiler code to define a type.
AFAICS there are 24 types in intXX... and uintXX... family.
So about 72 lines in compiler. For compatiblity with older
code you probably should define types under internal names
and have 24 lines in stdint.h (+3 lines of include guard).

stdint.h defines quite a bit more than just types, so actual
saving from having them built into compiler would be small,
in particular since preprocessor is fast. On my machine
I see 91 code lines after preprocessing of stdint.h. And
actually, several of definitions like '__pid_t' go beyond C
and are needed by other headers. So, really is not a big
deal.

BTW: I just tried

/tmp$ time gcc -E foo.c | wc
1000006 2000022 12889013

real 0m0.359s
user 0m0.351s
sys 0m0.085s

So gcc preprocessor is able to handle almost 3 million lines
per second. The lines were short, but gcc goes trough
piles of header files resonably fast, probably much faster
than you think.

I also tried to compile file contaning 100000 declarations
like:

extern int a0(void);
....
extern int a999999(void);

Compilation of such file takes 1.737s, so about 575000 lines
per second. So a lot of function declarations in header
files should not slow gcc too much. Typedefs seem to
trigger quadratic behaviour, so a lot of typedefs is likely
to slow down gcc quite a lot. But a limited bunch of
typedefs should not be too bad. And it probably does not
make much difference if the typedefs are in source file
or built into compiler.

--
Waldek Hebisch

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

On 21/03/2025 18:51, Kaz Kylheku wrote:

On 2025-03-21, Waldek Hebisch <antispam@fricas.org> wrote:

bart <bc@freeuk.com> wrote:

On 20/03/2025 13:36, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 20/03/2025 12:09, Tim Rentsch wrote:

Michael S <already5chosen@yahoo.com> writes:

I suspected that, but was not sure, so suggested to DFS a type that I am
sure about.

The width of char and [un]signed char must be at least 8 bits. >>>>>> The width of [un]signed short must be at least 16 bits. >>>>>> The width of [un]signed int must be at least 16 bits. >>>>>> The width of [un]signed long must be at least 32 bits. >>>>>> The width of [un]signed long long must be at least 64 bits. >>>>>>
That should be easy enough to remember now.

That table suggests that any program mixing 'short' and 'int' is
suspect. If 'int' doesn't need to store values beyond 16 bits, then why >>>>> not use 'short'?

'long' is another troublesome one. If the need is for 32-bit values, >>>>> then it's surprisingly rare in source code.

Long is useless, because Microsoft made the mistake of defining
'long' as 32-bits on 64-bit architectures, while unix and linux
define it as 64-bits.

Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
on 64-bit ones.

So long can't be used in programs intended to be portable to
other operating systems.

As defined by Unix/Linux, long is not portable between different
Unix/Linux OSes if they run on a different architecture.

It portably between 32 and 64 bit machines gives word-sized
integer type.

The bitness of modern mainstream machines is their address size.

C99 gaves us address-sized integers: intptr_t and uintptr_t.
If you want a 64 bit type on a 64 bit system and 32 bit type
on a 32 bit system, use those.

(The problem is that idea observed in Unix-like environments that long
is expected to be address-sized precedes C99.)

As defined by Microsoft, long is portable between Windows OSes even on
different architectures.

It gives 'long' different meaning than it had previously. And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.

In Microsoft land, there is a LONG type, which is involved in
the Win32 ABIs. That was their mistake.

In plenty of interfaces, Windows uses the types WORD and DWORD, which
are 16 and 32 bits wide unsigned types. (As well as QWORD,
a 64 bitter).

Those types are an invention of Microsoft and only appear in WinAPIs.
There seem to be hundreds of them, but they are well defined. Mostly
they are consistent between 32- and 64-bit systems too.

Since I've mostly used WinAPI via an FFI, I'm used to creating my own
bindings and using my own aliases for this ttypes. (Mostly it comes down
to one of i32 i64 u32 u64 plus a pointer type.)

The problem is, when someone needed the signed versions of
WORD and DWORD, they found them to be missing, and stupidly came up with
the names INT and LONG (and derived typedefs like LPARAM).
Nobody caught this code smell and so it got woven into the Windows API. Probably long before 32 bit Windows, I'm guessing.

Thus, LONG has to continue to be a 32 bit type, since it is
used as a "signed DWORD".

But it's inconceivable for LONG to to be a typedef for anything other
than long. Too much code depends on the wrong idea that LONG and long
are interchangeable.

Thus long has to be stuck on 32 bits.

There really isn't much in it. Here's the evolution as I see it (I stand
to be corrected if necessary):

C-Windows C-Linux My stuff
Machine int long int long int 'dint'

16 bits 16 32 16 32 16 32
32 bits 32 32 32 32 32 64
64 bits 32 32 32 64 64 [128]

The most logical and consistent progression seems to be with 'my
stuff'!Except I no longer support 128-bit types after doing so briefly.

The point is that there was usually a size exactly double the width of
'int', but it become less necessary when 'int' reached 64 bits.

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

On 2025-03-22, bart <bc@freeuk.com> wrote:

Since I've mostly used WinAPI via an FFI, I'm used to creating my own bindings and using my own aliases for this ttypes. (Mostly it comes down
to one of i32 i64 u32 u64 plus a pointer type.)

When I FFI to Windows, I tend to be a stickler for using names that
are exactly the same, wherever possible. I have DWORD, HWND,
and whatnot.

You can see it in this code; it is self-contained. It defines
all the symbols it needs, and requires just the DLLs:

https://rosettacode.org/wiki/Window_creation#Win32/Win64

Thus long has to be stuck on 32 bits.

There really isn't much in it. Here's the evolution as I see it (I stand
to be corrected if necessary):

There isn't much in it, but it doesn't take much in order to
pin things down and prevent change.

The point is that there was usually a size exactly double the width of
'int', but it become less necessary when 'int' reached 64 bits.

Yes, because other than for masks of 128 bits, there isn't a whole
lot of stuff you can *count* for which you need such large integers.

Money?

In an accounting system, if you use signed 64 bits for pennies, you can
go to 9.2 x 10^16 dollars.

Large integers are needed for crypto and such, but then 128 isn't enough anyway.

Obviously, IPv4 addresses are 128. In protocol stacks, switching and
routing, it could be useful to have 128 bit operations on them for
masking and comparing and whatnot.

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

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

On Sat, 22 Mar 2025 15:05:43 +1100
Alexis <flexibeast@gmail.com> wibbled:

Muttley@DastardlyHQ.org writes:

But 99.99% of the time doesn't.

Famously, mathematician G.H. Hardy was a fan of number theory _because_
it seemed to have no 'real world' applications (i.e. applications
outside of mathematics itself). Eventually, of course, it became the >theoretical basis of public-key cryptography.

Maths is the foundation of most technology, that doesn't mean all its
problems are useful. I could ponder balancing wheels on top of each other
but that wouldn't lead to the invention of the car.

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

On 22/03/2025 03:50, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 21/03/2025 19:04, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 21/03/2025 01:47, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
You're complaining about how much work it is. All that work
has been done for you by the implementers. Decades ago.

We are talking about defining types like 'int32' on top of 'char short >>>> int long', yes? Then how difficult could it possibly be?

If you want <stdint.h> and <inttypes.h> headers that work correctly
with all relevant compilers, it's not particularly easy. I'll note
that the MUSL implementation of <stdint.h> is 117 lines, compared to
308 for GNU libc.

I just did a quick test comparing complation times for an empty
program with no #include directives and an empty program with
#include directives for <stdint.h> and <inttypes.h>. The
difference was about 3 milliseconds. I quite literally could not
care care less.

I'm sorry but that's a really poor attitude, with bad
consequences. You're saying it doesn't matter how complex a header or
set of headers is, even when out of proportion to the task.

But this is why we end up with such complicated headers.

Complicated headers that work.
[...\

I think your response clarifies matters. Nobody cares, even as
compilers grind to a halt under all preprocessing.

If compilers ground to a halt, I would certainly care. They don't.

50 modules each including GTK.h say, which was 0.33Mloc across 500
headers (so reading 16Mloc and 25,000 headers in total when all are
compiled) would not impact your builds at all? OK.

First you talked about compilers grinding to a halt, then you talked
about headers not impacting builds at all. Those goalposts of yours
move *fast*.

You missed the "?".

For the record, as you can see above, I did not say that builds would
not be impacted. Do not put words into my mouth again.

Let me ask it again: so ploughing through a third of a million lines of
code across hundreds of #includes, even at the faster throughput
compared with compiling code, for a module of a few hundred lines, will
have little impact?

How about a project with 50 or 100 modules, each using that big header,
that needs to be built from scratch?

(I would download the GTK2 headers, if still available, to test it. But
it would be a huge undertaking. Just the set of compiler options needed
to tell it all the search paths to look for the right headers amongst
the 700 files and dozen of directories would be challenging.

Usually this is done with additional tools (PKCONFIG or some such thing) because it is so complicated. With my little toy compiler however it was
trial and error: look manually for each missing header, and add that to
the growing list of search paths.

So let me ask /this/ again: if such a library consisted of ONE compact
header file, would it make the process simpler? Would it make
compilation of multiple modules faster?)

printf("%v\n", t); # (used to be '?'; changed to 'v')
}

The compiler replaces the 'v' format with a conventional format code
according to the type of the expression. For my 'time_t', it happens
to be 'lld'.

That's nice. Seriously, it's nice. If it were added to a future
edition of the language, I'd likely use it (once I could count on it
being supported, which would take a while).

The Go language has something like that.

You can add extensions like that to your own compiler easily
enough. Adding them to the C standard (which requires getting all implementers to support them) is a lot harder. Does it work for
both output (printf) and input (scanf)? What if the format string
isn't a string literal; does the compiler generate code to adjust
it, allocating space for the translated string and deallocating it
after the call? Does it work with printf("%n", &var)? What about qualifiers, specifying width, base, and so forth.

My feature was a proof of concept. The 60 lines of code used to test it
worked specifically for 'printf', and didn't attempt to parse additional attributes like field widths (I wasn't implementing half of printf).

It only works when the format string is a literal (but so does gcc's
checking that format codes match parameter types).

It only looks for "$v" and "=v"; the latter will add a label:

#include <stdio.h>
#include <stdint.h>

int main(void) {
uint64_t a = 10;
double b = 23.1;
void* c = main;

printf("%=v %=v %=v\n", a, b, c);
printf("%=v %=v %=v\n", c, a, b);
}

The output is:

A=10 B=23.100000 C=0000000000401000
C=0000000000401000 A=10 B=23.100000

The motivation was partly to simplify writing lots of debug prints,
which rarely have field widths.

an integer of arbitrary type in hexadecimal in a right-justified
8-digit zero-padded field? The feature implies an ability for
generic code that works with different types; can programmers use
that feature for things other than format strings? How much more
complicated would the C language (as distinct from the library)
have to be to support this?

As I said the test was 60 lines of ad hoc code. It's not going to be
wildly complicated. As a language feature, somebody would need to write
a specification.

However, if a new format code is introduced, it should ideally be known
to the printf library functions, even it can't do much with it, for
those cases where it is used within a runtime string.

If you have answers to all those questions, and to all the other
questions that haven't occurred to me, I wouldn't mind seeing
something like that in a future version of C. I haven't looked
closely at Go, but it's a compiled language with a feature similar
to what you describe; it could probably be mined for ideas.

Or maybe we should be thinking in terms of something other than format strings. The idea that "%v", which is a 3-byte chunk of data, has compile-time implications in certain contexts is a bit unnerving.

Ada chose the short name "Put" for its output routines.
It's overloaded, so you can write `Put(this); Put(that);
Put(the_other);` Maybe that a little too verbose, but how about
a new built-in operator that takes an argument of any of various
types and yields something that can be printed? '$' is available.
I haven't thought this through.

The problem with Print is that it is a language feature that can take a arbitrary number of arguments, all of different types. Some may need
formatting info.

This is challenging for a language, if it wants to do it via functions
(which usually have a fixed number of arguments, of a specific type).
Some advanced features may needed.

C probably introduced variadic functions just for this purpose (which
remains challenging to implement!).

(I deal with it in my languages by having Print as a statement, with
special syntax. But internally the result is a series of function calls (print_i64 etc); ugly, sprawling code. Users will not see it, but I do.)

That's amazing.

Not particularly.

Sorry, I was being sarcastic. There were languages in the 60s where you
could just say 'print x' and it knew how to stringify x whatever its
type was. My first language using an 8KB compiler had such a Print
(though not many types).

C has programmer-defined operator (and function)
overloading as a language feature. (There are IMHO some serious
flaws in C++'s use of overloaded "<<" for output, but I won't go
into that here.)

You get an interesting set of error messages if you write >> instead of <<.

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

On 22/03/2025 02:37, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types. (And if this is for a multitude of
targets, then there should be a dedicated header per target).

GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
of the core language, it would be zero lines.

You need few (say 3) lines of compiler code to define a type.
AFAICS there are 24 types in intXX... and uintXX... family.

There's about 8, unless you include FAST/LEAST which are of interest to
a minority of the minority who are even aware of them.

So about 72 lines in compiler. For compatiblity with older
code you probably should define types under internal names
and have 24 lines in stdint.h (+3 lines of include guard).

It's a lot more than 72 lines in a compiler to support numeric types.

But this is about exposing fixed-size type aliases to existing types,
which can be done fairly tidily in a compiler, but not as tidily as when
all the built-in types can be expressed as one token; some need multiple tokens.

Also C requires those aliases to be hidden unless a particular header is
used.

Still, I was remarking on those Q8 headers requiring 1300 lines to add
these aliases.

stdint.h defines quite a bit more than just types, so actual
saving from having them built into compiler would be small,
in particular since preprocessor is fast. On my machine
I see 91 code lines after preprocessing of stdint.h. And
actually, several of definitions like '__pid_t' go beyond C
and are needed by other headers. So, really is not a big
deal.

BTW: I just tried

/tmp$ time gcc -E foo.c | wc
1000006 2000022 12889013

real 0m0.359s
user 0m0.351s
sys 0m0.085s

So gcc preprocessor is able to handle almost 3 million lines
per second. The lines were short, but gcc goes trough
piles of header files resonably fast, probably much faster
than you think.

Testing -E is tricky, since the output is textual, and usually
interspersed with # lines giving source line number info.

What was in foo.c?

In any case, I know that gcc can process headers reasonably fast
(otherwise it would take 10 seconds to plough through windows.h at the
speed of compiling code).

But it's the sheer size and scale of some headers that is the problem.
Why do you think precompiled headers were invented?

Compiling this program:

#define SDL_MAIN_HANDLED
#include "SDL2/SDL.h"
int main(){}

took gcc 0.85 seconds on my machine (however hello.c takes 0.2 seconds)

(SDL2 headers comprise 75 .h files and 50K lines; so about 75Kloc
throughput.)

Compiling this program:

#include <windows.h>
int main(){}

took 1.36 seconds. window.h might comprise 100 or 165 unique headers,
with 100-200K unique lines of code; I forget.

These figures are for each module that uses those headers. (My bcc took
0.07 seconds for the SDL test. The windows.h test can't be compared as
my version of that header is much smaller.)

I also tried to compile file contaning 100000 declarations
like:

extern int a0(void);
....
extern int a999999(void);

Compilation of such file takes 1.737s, so about 575000 lines
per second. So a lot of function declarations in header
files should not slow gcc too much.

I get these results (the test file has 'int main(){}' at the end):

c:\c>tim gcc fred.c
Time: 4.832

c:\c>tim tcc fred.c
Time: 4.620

c:\c>tim bcc fred.c
Compiling fred.c to fred.exe
Time: 1.324

Bear in mind that both gcc/tcc are presumably optimised code; bcc isn't)

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

Groovy hepcat DFS was jivin' in comp.lang.c on Wed, 19 Mar 2025 03:42
pm. It's a cool scene! Dig it.

On 3/18/2025 11:26 PM, Keith Thompson wrote:

DFS <nospam@dfs.com> writes:

There's your problem.

https://cses.fi/problemset/text/2433

"In all problems you should read input from standard input and write
output to standard output."

ha! It usually helps to read the instructions first.

The autotester expects your program to read arguments from stdin, not
from command line arguments.

It probably passes no arguments to your program, so argv[1] is a null
pointer. It's likely your program compiles (assuming the NBSP
characters were added during posting) and crashes at runtime,
producing no output.

I KNEW clc would come through!

Pretty easy fixes:

1 use scanf()

Normally I'd say take care with scanf(). But in this case, since the
program is intended to be executed in an automated environment, it
should be fine.
The reason scanf() can be a bit iffy is that you can't control what a
user will enter. If you search Google or Duck Duck Go for "comp.lang.c
faq" you can find more information on this and other issues. (The FAQ
is still out there, people..., somewhere...)

2 update int to long
3 handle special case of n = 1

The problem definition doesn't mention any special case. You should, I
think, treat 1 like any other number. So the output for 1 should be

1 4 2 1

4 instead of collecting the results in a char variable, I print
them as they're calculated

Yep, that's a more usual approach.
Another suggestion I have is to use a separate function to do part of
the work. But it's not vital.
Also, since the specification says that only positive numbers are to
be accepted, it makes sense (to me, at least) to use an unsigned type
for n.
One more thing: using while(1){...break;} is a bit pointless. You can
use do{...}while(1 != n) instead.
Here's my solution, for what it's worth:

#include <stdio.h>

unsigned long weird(unsigned long n)
{
printf("%lu", n);

if(n & 1)
{
/* Odd - multiply by 3 & add 1. */
n = n * 3 + 1;
}
else
{
/* Even - divide by 2. */
n /= 2;
}
return n;
}

int main(void)
{
unsigned long n;

/* Get n from stdin. */
scanf("%lu", &n);

/* Now feed it to the algorithm. */
do
{
n = weird(n);
putchar(' ');
} while(1 != n);

printf("%lu\n", n);
return 0;
}


--


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

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

On 22/03/2025 04:50, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

This is a C program using one of the extensions from my old compiler:

#include <stdio.h>
#include <time.h>

int main(void) {
time_t t = clock();
printf("%v\n", t); # (used to be '?'; changed to 'v')
}

The compiler replaces the 'v' format with a conventional format code
according to the type of the expression. For my 'time_t', it happens
to be 'lld'.

That's nice. Seriously, it's nice. If it were added to a future
edition of the language, I'd likely use it (once I could count on it
being supported, which would take a while).

I am sure it could be done using variadic macros, _Generic, and newer
C23 features like "typeof". But it would be difficult to handle
non-constant format strings, and may be difficult to do efficiently.
(C++ now has something like that in the modern "format" library. Of
course, it has the added power and complexity of handling user-defined
types too.)

It is certainly quite possible (in C11) to put together a macro so that
you can do :

int x = ... ;
const char *s = ...
double d = ...;

print("The result of ", s, " is ", x, " and ", d, "\r\n);

I suspect the biggest challenge to getting that into the standard
library would not be technical implementation in C11 - it would be
getting C programmers to agree that it is a good idea!


It would certainly be nice to have a less cumbersome way to specify
formats in C - especially for the size-specific integer types. But I
think it is likely that to do it /well/, you need a lot more apparatus
than C has at the moment, or is likely to gain in the future.

It would be very nice if C had some kind of more generic I/O that
doesn't require remembering arbitrary format strings and qualifiers
for each type, and that doesn't provide format strings for a lot of
types in the standard library, and certainly not for types defined
in user code. And I'd *love* it if a future C standard removed
the undefined behavior for numeric input using *scanf(). Other C
programmers will have different priorities than yours or mine.
If I want to print a time_t value in C++, I just write
`std::cout << t` and the compiler figures out which overloaded
function to call.

That's amazing.

Not particularly. C has programmer-defined operator (and function)

(You meant "C++" here?)

overloading as a language feature. (There are IMHO some serious
flaws in C++'s use of overloaded "<<" for output, but I won't go
into that here.)

[...]

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

On 22/03/2025 08:07, Peter 'Shaggy' Haywood wrote:

<snip>

Here's my solution, for what it's worth:

#include <stdio.h>

unsigned long weird(unsigned long n)
{
printf("%lu", n);

if(n & 1)
{
/* Odd - multiply by 3 & add 1. */
n = n * 3 + 1;

Or you can save yourself a multiplication

n = (n << 2) - (n - 1);

potentially shaving entire picoseconds off the runtime.

}
else
{
/* Even - divide by 2. */
n /= 2;

do
{
n >>= 1;
} while(~(n & 1));

...and there goes another attosecond.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

bart <bc@freeuk.com> writes:

On 21/03/2025 01:47, Keith Thompson wrote:

I just
did a quick test comparing complation times for an empty program
with no #include directives and an empty program with #include
directives for <stdint.h> and <inttypes.h>. The difference was
about 3 milliseconds. I quite literally could not care care less.

I'm sorry but that's a really poor attitude, with bad
consequences.

I'm with Keith on this one, and I expect most other C
developers are also.

You're saying it doesn't matter how complex a header or
set of headers is, even when out of proportion to the task.

This paraphrasing doesn't match what Keith said. Whether
deliberately or not, your interpretation is off base.

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

bart <bc@freeuk.com> wrote:

On 22/03/2025 02:37, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types. (And if this is for a multitude of
targets, then there should be a dedicated header per target).

GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
of the core language, it would be zero lines.

You need few (say 3) lines of compiler code to define a type.
AFAICS there are 24 types in intXX... and uintXX... family.

There's about 8, unless you include FAST/LEAST which are of interest to
a minority of the minority who are even aware of them.

Well, FAST/LEAST types are mandatory for standard compliance.

So about 72 lines in compiler. For compatiblity with older
code you probably should define types under internal names
and have 24 lines in stdint.h (+3 lines of include guard).

It's a lot more than 72 lines in a compiler to support numeric types.

But this is about exposing fixed-size type aliases to existing types,
which can be done fairly tidily in a compiler,

Yes, there is complex machinery to support types and compiler
data structires in general. But once machinery is in place
you need to create type node and insert it into symbol table.
In gcc creation of type node may look like:

sizetype = make_node (INTEGER_TYPE);
TYPE_NAME (sizetype) = get_identifier ("sizetype");
TYPE_PRECISION (sizetype) = precision;
TYPE_UNSIGNED (sizetype) = 1;
scalar_int_mode mode = smallest_int_mode_for_size (precision);
SET_TYPE_MODE (sizetype, mode);
SET_TYPE_ALIGN (sizetype, GET_MODE_ALIGNMENT (TYPE_MODE (sizetype)));
TYPE_SIZE (sizetype) = bitsize_int (precision);
TYPE_SIZE_UNIT (sizetype) = size_int (GET_MODE_SIZE (mode));
set_min_and_max_values_for_integral_type (sizetype, precision, UNSIGNED);

But such things are repeated for several types, so one can have
function like 'create_integer_type_node' which is doing the above,
but for type name and precision which are arguments to the function.

Of course, if you need to do soemthing special to a type, then
you may need a lot of code. But integer types should be handled
anyway, so there is really no special code beyond what is already
there.

but not as tidily as when
all the built-in types can be expressed as one token; some need multiple tokens.

Unlike classic integer types, types in stdint.h have names which
are single token, so all you need to do is to insert entry in the
symbol table.

Also C requires those aliases to be hidden unless a particular header is used.

Yes, so either one need some mechanism to hide/expose builtin
indentifiers, or (what is typically done) one need to use
reserved names for builtin indentifiers and use stdint.h to
define standard name as an alias.

Still, I was remarking on those Q8 headers requiring 1300 lines to add
these aliases.

I am not sure if Q8 really needed all those lines. But you
should take into account that it provided type without
cooperation with the compiler.

stdint.h defines quite a bit more than just types, so actual
saving from having them built into compiler would be small,
in particular since preprocessor is fast. On my machine
I see 91 code lines after preprocessing of stdint.h. And
actually, several of definitions like '__pid_t' go beyond C
and are needed by other headers. So, really is not a big
deal.

BTW: I just tried

/tmp$ time gcc -E foo.c | wc
1000006 2000022 12889013

real 0m0.359s
user 0m0.351s
sys 0m0.085s

So gcc preprocessor is able to handle almost 3 million lines
per second. The lines were short, but gcc goes trough
piles of header files resonably fast, probably much faster
than you think.

Testing -E is tricky, since the output is textual, and usually
interspersed with # lines giving source line number info.

What was in foo.c?

Just 1000000 lines of declarations (no includes etc.). The
point was that skipping input is easier than copying things to
the output, so that should give reasonable estimate of time
spent on parts that disappear after preprocessing.

In any case, I know that gcc can process headers reasonably fast
(otherwise it would take 10 seconds to plough through windows.h at the
speed of compiling code).

But it's the sheer size and scale of some headers that is the problem.
Why do you think precompiled headers were invented?

Some headers are pretty big. But fact that at source level
stdint.h has some hundreds of lines is not big problem, it
is still rather small. Note that it is convenient to have
common headers for variants of architecure, on my Linux
I can run 3 kinds of programs: classic 32-bit ones, 64-bit ones
and x32 (which uses 32-bit addresses, but uses 64-bit
instructions). Each needs slightly different definitions
in header files. This is handled by conditionals in
header files. And in fact large part of headers are shared
with different architecures (and even different OS-es using
the same libc).

Compiling this program:

#define SDL_MAIN_HANDLED
#include "SDL2/SDL.h"
int main(){}

took gcc 0.85 seconds on my machine (however hello.c takes 0.2 seconds)

(SDL2 headers comprise 75 .h files and 50K lines; so about 75Kloc throughput.)

Compiling this program:

#include <windows.h>
int main(){}

took 1.36 seconds. window.h might comprise 100 or 165 unique headers,
with 100-200K unique lines of code; I forget.

These figures are for each module that uses those headers. (My bcc took
0.07 seconds for the SDL test. The windows.h test can't be compared as
my version of that header is much smaller.)

I also tried to compile file contaning 100000 declarations

^^^^^^
Oops, should be 1000000.

like:

extern int a0(void);
....
extern int a999999(void);

Compilation of such file takes 1.737s, so about 575000 lines
per second. So a lot of function declarations in header
files should not slow gcc too much.

I get these results (the test file has 'int main(){}' at the end):

c:\c>tim gcc fred.c
Time: 4.832

c:\c>tim tcc fred.c
Time: 4.620

c:\c>tim bcc fred.c
Compiling fred.c to fred.exe
Time: 1.324

Bear in mind that both gcc/tcc are presumably optimised code; bcc isn't)

On my machine tcc preprocesses probably about 20% faster than gcc.
For timing compilation I used 'gcc -c' to generate linkable object
file, so no need to have 'main'. When actually compilning on my
machine tcc is significantly faster, on the same file 'tcc -c'
takes 0.418s, so more than 4 times faster than 'gcc -c'.

I do not know why 'tcc' is that much faster. One possibility
is that 'gcc' contains various extra info in compiler data
structures that help when optimizing, but require extra effort
even when not optimiziong.

--
Waldek Hebisch

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

Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2025-03-22, bart <bc@freeuk.com> wrote:

The point is that there was usually a size exactly double the width of
'int', but it become less necessary when 'int' reached 64 bits.

Yes, because other than for masks of 128 bits, there isn't a whole
lot of stuff you can *count* for which you need such large integers.

Money?

In an accounting system, if you use signed 64 bits for pennies, you can
go to 9.2 x 10^16 dollars.

Actually, to do fast division of N-bit number by fixed N-bit number
one need 2N-bit multiplication. Such divisions appear in base
convertions (to decimal) and when doing "decimal" rounding.
Also, converting between currencies needs extra accuracy. So
_fast_ financial arithmetic may need rather large number of digits,
current tendecy is to allow up to 37 digits in intermediate quantities.

Note that 64-bit _result_ type means that 32-bit integers are
largest that can be multiplied exactly, that is very limiting.

Large integers are needed for crypto and such, but then 128 isn't enough anyway.

Double word arthmetic is crucial if you want efficient high-level implementation of multiple precision arithmetic. So, 64-bit is
enough on 32-bit machines, 128-bit is needed on 64-bit machines
and hypotetical 128-bit machines would need 256-bit integer
type as a building block for efficient multiple precision
arithmetic.

--
Waldek Hebisch

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

On 3/22/2025 4:07 AM, Peter 'Shaggy' Haywood wrote:

Groovy hepcat DFS was jivin' in comp.lang.c on Wed, 19 Mar 2025 03:42
pm. It's a cool scene! Dig it.

On 3/18/2025 11:26 PM, Keith Thompson wrote:

DFS <nospam@dfs.com> writes:

There's your problem.

https://cses.fi/problemset/text/2433

"In all problems you should read input from standard input and write
output to standard output."

ha! It usually helps to read the instructions first.

The autotester expects your program to read arguments from stdin, not
from command line arguments.

It probably passes no arguments to your program, so argv[1] is a null
pointer. It's likely your program compiles (assuming the NBSP
characters were added during posting) and crashes at runtime,
producing no output.

I KNEW clc would come through!

Pretty easy fixes:

1 use scanf()

Normally I'd say take care with scanf(). But in this case, since the program is intended to be executed in an automated environment, it
should be fine.
The reason scanf() can be a bit iffy is that you can't control what a
user will enter. If you search Google or Duck Duck Go for "comp.lang.c
faq" you can find more information on this and other issues. (The FAQ
is still out there, people..., somewhere...)

https://c-faq.com/

I still see links to that document from time to time, like on university websites.

2 update int to long
3 handle special case of n = 1

The problem definition doesn't mention any special case. You should, I think, treat 1 like any other number. So the output for 1 should be

1 4 2 1

It's a 'special case' because n is already 1.

Your code passed all CSES tests but this one.

4 instead of collecting the results in a char variable, I print
them as they're calculated

Yep, that's a more usual approach.
Another suggestion I have is to use a separate function to do part of
the work. But it's not vital.
Also, since the specification says that only positive numbers are to
be accepted, it makes sense (to me, at least) to use an unsigned type
for n.
One more thing: using while(1){...break;} is a bit pointless. You can
use do{...}while(1 != n) instead.
Here's my solution, for what it's worth:

#include <stdio.h>

unsigned long weird(unsigned long n)
{
printf("%lu", n);

if(n & 1)
{
/* Odd - multiply by 3 & add 1. */
n = n * 3 + 1;
}
else
{
/* Even - divide by 2. */
n /= 2;
}
return n;
}

int main(void)
{
unsigned long n;

/* Get n from stdin. */
scanf("%lu", &n);

/* Now feed it to the algorithm. */
do
{
n = weird(n);
putchar(' ');
} while(1 != n);

printf("%lu\n", n);
return 0;
}

Cool.


I tweaked my original and got it down to: --------------------------------------------------------
#include <stdio.h>

int main(void)
{
long n = 0;
scanf("%ld", &n);
while(n > 1) {
printf("%ld ",n);
n = (n % 2) ? (n * 3 + 1) : (n / 2);
}
printf("1\n");
return 0;
}
--------------------------------------------------------

I also liked the Number Spiral, Coin Piles and Palindrome Reorder problems.


Thanks for the input!

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

antispam@fricas.org (Waldek Hebisch) writes:

bart <bc@freeuk.com> wrote:

On 21/03/2025 17:51, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

(Probably intptr_t or ssize_t is better for
that purpose, and will be portable between Windows and Linux.)

Those did not exist in 1991 and would be needed only for small
machines. Except for Microsoft which decided to push its own,
different way.

ssize_t existed in before 1990 (in SVR4). intptr_t came later.

$ grep ssize_t common/head/*
common/head/aio.h: ssize_t aio__return; /* operation result value */
common/head/unistd.h:extern ssize_t read(int, void *, size_t); common/head/unistd.h:extern ssize_t write(int, const void *, size_t);

One 'con' for Linux' approach is when someone assumes 'long' is i32;
when they run code on 64 bits, it will either be wasteful, or it could
go badly wrong.

One 'con' of any assumption is that somebody can make a different
assumption.

Programmers shouldn't be making 'assumptions' in the first place.

The architectural ABI describes fully the capabilities of the
native types. If the programmer isn't aware of that, they
shouldn't be programming.

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

On 22/03/2025 14:22, Scott Lurndal wrote:

Programmers shouldn't be making 'assumptions' in the first place.

The architectural ABI describes fully the capabilities of the
native types. If the programmer isn't aware of that, they
shouldn't be programming.

Did programmer just assume that all programmers are told on which
platforms their code will be run? Not all C programmers are so
pampered.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:

Groovy hepcat DFS was jivin' in comp.lang.c on Wed, 19 Mar 2025 03:42
pm. It's a cool scene! Dig it.

On 3/18/2025 11:26 PM, Keith Thompson wrote:

DFS <nospam@dfs.com> writes:

There's your problem.

https://cses.fi/problemset/text/2433

"In all problems you should read input from standard input and write
output to standard output."

ha! It usually helps to read the instructions first.

The autotester expects your program to read arguments from stdin, not
from command line arguments.

It probably passes no arguments to your program, so argv[1] is a null
pointer. It's likely your program compiles (assuming the NBSP
characters were added during posting) and crashes at runtime,
producing no output.

I KNEW clc would come through!

Pretty easy fixes:

1 use scanf()

Normally I'd say take care with scanf(). But in this case, since the
program is intended to be executed in an automated environment, it
should be fine.
The reason scanf() can be a bit iffy is that you can't control what a
user will enter. If you search Google or Duck Duck Go for "comp.lang.c
faq" you can find more information on this and other issues. (The FAQ
is still out there, people..., somewhere...)

2 update int to long
3 handle special case of n = 1

The problem definition doesn't mention any special case. You should, I
think, treat 1 like any other number. So the output for 1 should be

1 4 2 1

4 instead of collecting the results in a char variable, I print
them as they're calculated

Yep, that's a more usual approach.
Another suggestion I have is to use a separate function to do part of
the work. But it's not vital.
Also, since the specification says that only positive numbers are to
be accepted, it makes sense (to me, at least) to use an unsigned type
for n.
One more thing: using while(1){...break;} is a bit pointless. You can
use do{...}while(1 != n) instead.
Here's my solution, for what it's worth:

And here's mine.

int
main(int argc, const char **argv)
{
unsigned int n;
scanf("%u", &n);
printf("%u ", n);
do {
n = (n & 1u) ? n * 3u + 1u : n >> 1u;
printf("%u ", n);
} while (n != 1u);
putchar('\n');
return 0;
}

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