In other words, give a true email address or don't
expect an answer.

"Trust the computer industry to shorten 'Year 2000' to 'Y2K.'  It was
this kind of thinking that caused the problem in the first place."

The machine does not isolate man from the great problems of nature
but plunges him more deeply into them.
                   -- Antoine de Saint-Exupery, 'Wind, Sand, and Stars.'

You've been working on systems which round up memory allocations,
or you haven't checked whatever variable follows the misallocated array
in memory.  I must admit, I'm suprised you've got away with it for any
length of time.  A character array of length ten can hold a string of
maximum length nine in elements 0 to 8, with the last element, array[9],
being nul.  You can safely have a pointer which points to the element
one beyond the end of the array, but you can't de-reference it.

Will

#define MAX_STRING_SIZE 25

typedef char STRING[MAX_STRING_SIZE];

STRING s, s1;

Now,

to move between s1 and s, do:

memcpy((void *) s, (void *) s1, MAX_STRING_SIZE);

JPL

        process_string(STRING s)
        {
                /*...*/
        }

It looks harmless enough, but the parameter 's' has been secretly converted to
char * type. Hence sizeof 's' is not the same as sizeof(STRING), for instance.

I find such typedefs handy for defining specific data types, for example:

        typedef char user_name_t[64];
        typedef char pass_phrase_t[128];

These types can then appear in distinct, but related, data structures, ensuring
that everything is compatible: that, for instance, one user ID can always be
copied to another with an unchecked, fixed-size memcpy().

When I use such typedefs, I try always to treat such types opaquely and pass
around pointers to them, e.g.

        unsigned long pass_phrase_hash(pass_phrase_t *pp)
        {
                /*
                 * use ``sizeof (*pp)'' here as needed
                 * ...
                 */
        }

By putting in the cast, you may hide a potential error; for example,
what if 's' points at the first element of an array of const chars?
Your (void *) type casts away the constness, suppressing a compiler
diagnostic.

Also, since you went to all the trouble to create the STRING array typedef,
why not take advantage of it and use sizeof instead of MAX_STRING_SIZE?

        memcpy(s, s1, sizeof s);

--
{ Sunil Rao }
"Is there any light more becoming than that, low and richly tinted, that comes
subdued through the mists of sunshine?"
        -- J Sheridan Le Fanu

In the real world it would usually be very costly to have
memory protection this fine grained and I have never seen
an implementation that signals a "violation" for this error.  
In practice reading off the end of an array will almost
always silently return garbage or zero, and writing will
often silently clobber some other variable, which may cause
other parts of your program later to do almost anything from
giving slightly wrong results to crashing.  The only case
likely to be caught by hardware is if array happens to be
the very last static-duration object in your link image,
and on many platforms only if it falls on a page boundary
(maybe 4K or 16K), or the last auto on an upward-growing stack.  

If you mean & array [10], which most programmers expect
to be the same, this is specified to be &*(array+10),
which formally is undefined because of the dereference.  
This has been debated at length in the past; see dejanews.  
But since any reasonable implementation can compute this
without doing the dereference, there seem no reliable reports
of this actually failing "in the wild", and C9X will have
a change (in 6.5.3.2/3) that specifies the &* to be
effectively elided and makes this case (also) legal.  

(CCed) david.thompson at but not for trintech.com

--
{ Sunil Rao }
"Is there any light more becoming than that, low and richly tinted, that comes
subdued through the mists of sunshine?"
        -- J Sheridan Le Fanu