Re: Suggested method for returning a string from a C program?

Groovy hepcat DFS was jivin' in comp.lang.c on Sun, 23 Mar 2025 01:29
am. It's a cool scene! Dig it.

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/

  There we go! :)

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.

  No, there was no special case mentioned in the specification.
Therefore 1 is not a special case, and you still run the algorithm on
that. At least, that's how it should be. If it's not how it is, then
the spec differs from the actual requirement.

Your code passed all CSES tests but this one.

  If the test failed due to this, then they should have mentioned this
special case in the spec. I wrote my code based on what was there, not
what they left out.

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!

  No wuckin' forries, pal! :)

--


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
              Ain't I'm a dawg!!