Thanks very much.

It's safer to use strtol(). If the string pointed by nptr represents a
number that is two big to be represented as a long int, strtol(nptr,
&endptr, 10) will set errno to ERANGE and return either LONG_MIN or
LONG_MAX, depending upon the sign of the number. If nptr points at a
string that cannot be interpreted as a correctly formated number, it
returns 0. In either case, is sets endptr to be equal to nptr.

Using strtol() also eliminates the need for the strtok() call; if
strtol(nptr, &endptr, 10) succeeds, it sets endptr to point after the
end of the string that it processed.

#include <errno.h>
#include <stdlib.h>

int fill_array(
        size_t max_elements;
        long array[],
        char buffer[]
){
     char *nptr;
     char *endptr;
     int num;

     nptr = buffer;
     errno = 0;
     for(num=0; *endptr && num<max_elements; num++)
     {
         array[num] = strtol(nptr, &endptr, 10);
         if(nptr == endptr)
         {
             if(errno == ERANGE)
             {  /* The number was too big to be converted */
                /* array[num] will be either LONG_MIN or LONG_MAX,
                 * depending upon the sign of the number */
                /* Handle error. */;
             }
             else
             {  /* The string could not be interpreted as number */
                /* array[num] will be 0. */
                /* Handle error */;
             }

             /* Unless your error handling changed either the
              * contents of the buffer or the location pointed
              * at by nptr, there is no point in making any more
              * calls to strtol(). Therefore,
              */
             break;
         }
         else
             nptr = endptr;
     }

     return num;

Best wishes,

Show the code that is not working and people will try to help you
identify where your problems are.  It would also be very useful if you
tell us how you know the code is not doing what you want.

 to read an int:

 n=fscanrf( f, "%d", &intvar);

 to skip spaces and other crud:

   fscanf( f, "%*[^0-9\n]");

 to check for end-of-line:

   eol=fscanf( f, "%1[\n]" , &dummy_char);

Reading in a line at a time with fgets(), and then parsing it with
sscanf(), is usually a better approach. It's easier to debug if
something goes wrong. It may also make it easier to get the code right
in the first place, though I'm not as sure about that. However, it does
get clumsy when there's a large number of fields on the same line.

The other issue, for all members of the *scanf() family, is that section
7.19.6.2p10 says:

"... the result of the conversion is placed in the object pointed to by
the first argument following the format argument that has not already
received a conversion result. If this object does not have an
appropriate type, or if the result of the conversion cannot be
represented in the object, the behavior is undefined."

That's why it's safer to use the strto*() family of functions rather
than relying upon the *scanf() family; if given valid arguments, their
behavior is well-defined, regardless of the content of the string being
processed. There's also footnote 251, which says:

"fscanf pushes back at most one input character onto the input stream.
Therefore, some sequences that are acceptable to strtod, strtol, etc.,
are unacceptable to fscanf.".

I haven't bothered to figure out which kinds of sequences those are, but
that's yet another reasons to favor strto*() of *scanf().

If the input is a syntactically valid integer outside the range of
int, the behavior is undefined.

  http://en.wikipedia.org/wiki/Information_hiding

You would need to consider what the integer-read routine would do on
such as

1. A suitable integer
2. A number that's too large
3. A signed integer
4. A non-space, non-digit character including a decimal point
5. The end of a line
6. The end of the file

Depending on your needs this gives two basic choices for the format of
the call in C:

  integer = integer_read(file)

or

  status = integer_read(&integer, file)

The first is usable if there are some integer values that won't exist
in the file. You can return these to indicate end of file and the
like. The second allows you to return various status values separately
from the integer.

Given the above structure you can then write the integer-read routine
in any of a number of different ways - and can change the method later
if desired. Apart from suggestions others have made consider using
getc. It is a more fundamental call. You will learn more and have more
flexibility that way.

        0xOOPS
        1.23eek
        INCREDIBLE
        infinitesimal
        NABOB
--
Larry Jones

    If this object does not have an appropriate type, or if the result
    of the conversion cannot be represented in the object, the
    behavior is undefined.

How wierd!

It might require some extra work for some implementations to avoid
Bad Things Happening for "%*d", perhaps a bit of special-case
code that only parses the input without trying to convert to to an
integer.  Other implementations can just quietly ignore the overflow.

Still, I would have been happier if the behavior hadn't been
left undefined.  Implementations already have to be able to handle
overflowing string-to-number conversions for strto*(); requiring
some sort of reasonable behavior for *scanf() wouldn't have been
too much of a burden.

Perhaps at the time the standard was being written, some
implementations treated an overflowing integer as a failed
conversion, and other stored some arbitrary value.  Perhaps the
authors of the standard decided not to force some implementations
to change.  It's not the decision I would have made.  (I am, of
course, speaking with 20+ years of hindsight.)

"undefined behavior" is no rules of behavior whatsoever...  usually
for cases where (to use real-world terms) you can corrupt the stack,
heap, or other memory regions not involved in the expression.

// implementation defined behavior
int foo(void)
{
   int a ;
   return a;