How is "static buffers" defined?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • chenxinleo@gmail.com

    #1

    How is "static buffers" defined?


    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

    #2
    Re: How is "static buffers" defined?

    chenxinleo@gmai l.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_buff er[SOME_SIZE];

    or

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

    Note: the 'static' on file_scope_buff er 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.

    Comment

    • Gordon Burditt

      #3
      Re: How is &quot;static buffers&quot; defined?

      >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.

      Comment

      Working...