How is "static buffers" defined?

[chenxinleo]

Hi,
When i use some standard library functions and fields,which return
char* type(like ctime in time.h, optarg in getopt.h)and do not have to
be freed after calling,i always worry about memory leaking(thoug i
konw i just donot have to).Then i look inside in time.h
file(mingw) ,and i found notes say"These functions write to and return
pointers to static buffers that may be overwritten by other function
calls".So how is the"static buffers" defined?What about its size?Is
memory leaking possible when returning long enough string?Is it a part
of ANSI c?

Thanks.

[James Kuyper]

ch********@gmail.com wrote:

Hi,
When i use some standard library functions and fields,which return
char* type(like ctime in time.h, optarg in getopt.h)and do not have to
be freed after calling,i always worry about memory leaking(thoug i
konw i just donot have to).Then i look inside in time.h
file(mingw) ,and i found notes say"These functions write to and return
pointers to static buffers that may be overwritten by other function
calls".So how is the"static buffers" defined?What about its size?Is
memory leaking possible when returning long enough string?Is it a part
of ANSI c?

<nitI think your space bar is malfunctioning; there's a lot of
mandatory spaces missing from the above message. It makes your message
hard to read.</nit>

If the function is defined in C, then it probably uses the same methods
any other C function would use to define a static buffer:

static char file_scope_buffer[SOME_SIZE];

or

char *myfunc()
{
static char block_scope_buffer[SOME_SIZE];
/* rest of myfunc */
return block_scope_buffer;
}

Note: the 'static' on file_scope_buffer was not needed to give the
buffer static storage duration; it already had that just by reason of
being declared with file scope. Instead, it gives the buffer internal
linkage, which is what I would choose for this kind of usage.

If ctime() is defined in some other way, such as assembly, some entirely
different method of defining the buffer would be used.

The only thing you need to know about the size of the buffer is that it
must be big enough to hold the string that you've requested. You should
never write to these buffers, so it should not matter to you how much
bigger they are than the string.

There is one anomalous case: asctime(). It is the only function in the
standard library whose behavior is defined in terms of a reference
implementation. However, the actual code that implements asctime() isn't
required to be the same as the reference implementation, it's just
supposed to produce the same behavior, when that behavior is defined;
when the behavior is undefined, the standard imposes no requirements on
asctime().

That reference implementation gives a length of 26. The behavior of the
reference implementation is undefined if the arguments given to
asctime() would cause that buffer to overrun. This is possible for
values of timeptr->year 8099, among other possibilities. This is a
prime example of why reference implementations should not be used to
define the behavior; it would have been much clearer to explicitly state
that timeptr->year must be <= 8099.

Since the behavior of the function is undefined in those cases, it's
permissible for it to be the same as the behavior of a function that
uses some method of preventing the buffer overrun, such as making the
buffer longer. So even for asctime(), you don't really know how big the
buffer is.

Memory leakage is only an issue for memory with dynamic storage
duration. Since this memory has static storage duration, memory leakage
from calling these functions is something you should never have to worry
about.

[Gordon Burditt]

>When i use some standard library functions and fields,which return

>char* type(like ctime in time.h, optarg in getopt.h)and do not have to
be freed after calling,i always worry about memory leaking(thoug i
konw i just donot have to).

You can't free() that, so don't try.

The string pointed at by optarg after a return from getopt() is a
pointer into the middle of data *YOU* supplied: the same happens
for strchr(), strrchr(), and similar functions.

>Then i look inside in time.h
file(mingw) ,and i found notes say"These functions write to and return
pointers to static buffers that may be overwritten by other function
calls".So how is the"static buffers" defined?

It's a variable that is declared static (function or file scope),
and "buffer" sort of implies a character array, and the type of the
pointer used to point into it also implies the type of the buffer.
For ctime(), the buffer is a character array. In the case of
localtime(), however, the buffer is a struct tm.

>What about its size?Is

If a function chooses this method of returning something, it must
think that the buffer is sufficiently big for all results. ctime(),
for example, is supposed to return a string the same length all the
time (26 bytes, including the \0 terminator), although that function
does have a serious Y10K problem. localtime() returns a pointer to
a struct, and the struct is a fixed size.

>memory leaking possible when returning long enough string?

When talking about *LONG* strings, think *BUFFER OVERFLOW*, not
memory leak. Buffer overflows are much more serious than memory
leaks.

>Is it a part
of ANSI c?

Is what a part of ANSI C? ctime()? Yes. Buffer overflow? ANSI
C doesn't define that, but you can certainly make it happen with
ANSI C. Memory leak? ANSI C doesn't define that, but you can
certainly make it happen with ANSI C.