Thread: Writing a set of random integers to a file

Hey guys, I have a stupid question. I am trying to make a program that writes a set of a random number of random integers to a file for a program that I am writing for a class assignment. The program I have to write for class takes a file of integers (one integer per line) and adds them up in two divide and conquer techniqes that involve shared memory, one program executing another, and forked processes...I'm getting ahead of myself, sorry. This is the code for my little program.

Code:

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

int main()
{
  srand( ( unsigned ) time( NULL );
  FILE *fp;
  int i;

  printf( "Size of an integer on this machine: %d\n", sizeof( int ) );

  if( ( fp = fopen( "numbers.dat", "w" ) == NULL )
  {
    printf( "Can't open %s \n", "numbers.dat" );
    return( 1 );
  }
  else
    for( i = rand() % 200, i > 0, i-- )
      fprintf( fp, "%d\n", rand() );

  return( 0 );
}

Can you guys tell me what's wrong with it? It won't compile, citing errors with the srand statement, as well as *fp, among other things.

>srand( ( unsigned ) time( NULL );
>FILE *fp;
>int i;
Unless you're planning on compiling this as C99, C only allows declarations at the beginning of a block.

>srand( ( unsigned ) time( NULL );
Count your parens, you forgot to close the srand function call.

>printf( "Size of an integer on this machine: %d\n", sizeof( int ) );
sizeof gives you a size_t value, which is an unsigned quantity that could very well be larger than an int. In C89, it's best to use %lu and cast the result of the expression to unsigned long. That way you force the types to match while giving size_t the benefit of the doubt and using the largest standard unsigned integral type.

>if( ( fp = fopen( "numbers.dat", "w" ) == NULL )
Count the opening parens and compare with a count of the closing parens. Do they match? Try this instead:

Code:

if( ( fp = fopen( "numbers.dat", "w" ) ) == NULL )

>printf( "Can't open %s \n", "numbers.dat" );
Okay...I assume that "numbers.dat" is a placeholder for a string variable or macro? Otherwise there's no point in using a format modifier, you can just do this:

Code:

printf( "Can't open numbers.dat\n" );

>return( 1 );
A return value of 1 is not portable. The only three portable return values for main are 0, EXIT_SUCCESS and EXIT_FAILURE. The latter two are macros defined in stdlib.h.

>for( i = rand() % 200, i > 0, i-- )
You separate the parts of a for loop with a semicolon, not a comma.

You describe return values as supported by your enviornment, and it is not unique in supporting return values other than EXIT_SUCCESS, EXIT_FAILURE, and 0. However, the standard only guarantees that those three will be legal.

Originally Posted by Dave Evans

Maybe my question got lost in my excess verbiage, code and .bat file.

My question is, "What does one mean when one says, 'The only three portable return values for main are 0, EXIT_SUCCESS and EXIT_FAILURE'. "

What's portable about them? What's less portable about other values? C programs return an int. Programs that invoke C programs may or may not be C programs. A C program, in general, has no way of knowing what kind of program invoked it. How can anyone say that certain return values are more portable than others?

Are you saying that if my main() has a return -1; statement that the compiler can create code that returns any bloomin' value that it wants, since my return value is illegal? I will readily admit that I haven't read the C standard. I learned from K&R, and have supplemented my ad-hoc experiences by lurking on this board. I like to find out new things.

Dave

"I was born not knowing, and have only had a little time to change that, here and there."

---Richard Feynman

The basic idea is that a program that adheres to the C standard can be compiled on any compiler that adheres to the C standard and will produce a program with predictable, defined behaviour; portability.

Originally Posted by kermit

Well on a UNIX based system you can return any int number you like, but you are not guaranteed that number will return properly. If we use your example, you will get a return of 255, not -1.

So, what do you get when your main() returns EXIT_FAILURE (defined as 1). On my linux box I get 256, not 1. I don't see anything more portable about EXIT_FAILURE than any other value.

Dave

Test Code:

Code:

/* z.c                              */
/* Compile this with gcc -o z z.c   */

#include <stdio.h>
int main()
{
  int innum;
  int retval;
  char inbuf[BUFSIZ];

  printf("Enter an integer value to return to main: ");
  fgets(inbuf, BUFSIZ, stdin);
  if (sscanf(inbuf, "%d", &innum) == 1) {
    retval = innum;
  }
  else{
    printf("I was looking for an integer\n");
    retval = -99;
  }
  printf("I am returning with retval = %d\n", retval);
  return retval;
}

Code:

/* y.c                             */
/* compile this with gcc -o y y.c  */

#include <stdio.h>
#include <stdlib.h>
int main()
{
  int x;
  x = system("./z");
  printf ("x = %d, (0x%08x hex)\n", x,x);
  return 0;
}

now enter

./y

and see what return values you get.

Try it with execl, spawn, etc. Also try exit() instead of return().


Regards,

Dave

Originally Posted by kermit

That is interesting - it returns 1 on my machine. What version of Linux / gcc are you running (not that it matters, but I am curious)

Something else that I find interesting about the EXIT_SUCCESS, and EXIT_FAILURE macros is that they are traditionally 0 and 1 respectively on a UNIX based machine, but are not so on all implementations. I have wondered about how that would affect portability. No, I am not lashing out at the standard..

The machine that I just tested on has Fedora Core1, gcc version 3.3.2.

I repeat that I am not familiar with the standard to the point where I can say it's non-compliant. The bottom line for me is that return values from main() aren't portable among the various Windows and Linux systems that I use.

As far as traditional values, C programmers, of course, know that C functions typically return 0 for failure and non-zero for success, so we see things like

Code:

if (!isdigit()) {
  ...

Whereas return from main() typically uses 0 for "OK", something else for "Not OK". I think that's why they put EXIT_SUCCESS and EXIT_FAILURE in stdlib.h. Still not portable, as far as the value that the invoking functions actually obtain through operating system calls.

Regards,

Dave

"Everything should be made as simple as possible, but no simpler."
--- Albert Einstein

"Everything should be made as portable as possible, but no portablier."
--- Dave Evans

0 and EXIT_SUCCESS are synonymous, and mean that the program was successful
EXIT_FAILURE means the program failed. The macros will always be the correct values for your OS, and 0 is always converted into whatever your OS uses for success.

Take an odd OS like VAX-VMS, where (as far as the OS was concerned, 0 meant failure and 1 success). You would still use 0 or EXIT_SUCCESS for success and EXIT_FAILURE for failure.

If you do an explicit
return 1;
then it may mean different things in different environments.

> x = system("./z");
This too is non-portable. system() typically has to mangle its own return code with the return code of the process it executed.

regardless of where you compile, EXIT_FAILURE will return a value that is understood by the caller that the program has failed. Who knows what "1" or "-1" will do on a different system?