function

Discussion in 'C Programming' started by Bill Cunningham, Aug 11, 2011.

  1. I have been looking for a function from ANSI C that would start out with
    a buffer size of zero initialized and would grow to a certain size. I have
    already been able to set aside a 32 byte type using malloc(). Could calloc()
    be what I'm looking for? This buffer would be able to grow by a mechanism
    that would include using fscanf to find the size of a file in bytes. So my
    question is simply is there any functions or ways in c89 to fill a buffer to
    a certain size before it's clear? int buffer[] won't work unless it's a
    char.

    Bill
    Bill Cunningham, Aug 11, 2011
    #1
    1. Advertising

  2. Bill Cunningham

    Guest

    On 11 aug, 11:04, "Bill Cunningham" <> wrote:
    >     I have been looking for a function from ANSI C that would start out with
    > a buffer size of zero initialized and would grow to a certain size. I have
    > already been able to set aside a 32 byte type using malloc(). Could calloc()
    > be what I'm looking for? This buffer would be able to grow by a mechanism
    > that would include using fscanf to find the size of a file in bytes. So my
    > question is simply is there any functions or ways in c89 to fill a bufferto
    > a certain size before it's clear? int buffer[] won't work unless it's a
    > char.
    >
    > Bill


    I'm sorry, I can't understand you... could you explain exactly what
    you want to achieve?
    , Aug 11, 2011
    #2
    1. Advertising

  3. "Bill Cunningham" <> writes:

    > I have been looking for a function from ANSI C that would start out with
    > a buffer size of zero initialized and would grow to a certain size. I have
    > already been able to set aside a 32 byte type using malloc(). Could calloc()
    > be what I'm looking for?


    No.

    > This buffer would be able to grow by a mechanism
    > that would include using fscanf to find the size of a file in bytes. So my
    > question is simply is there any functions or ways in c89 to fill a buffer to
    > a certain size before it's clear?


    Yes. There are "ways" in C89 to write almost any program -- it's a
    general purpose language after all.

    No standard function does what you want. Many programming languages can
    do what you want in a single function call (or equivalent) but you seem
    determined to butt your head up against, what is to you, C's impenetrable
    syntax and library.

    > int buffer[] won't work unless it's a char.


    What an odd statement! Fortunately I don't need to know what you mean
    by it.

    --
    Ben.
    Ben Bacarisse, Aug 11, 2011
    #3
  4. Bill Cunningham

    Mark Bluemel Guest

    On 08/11/2011 10:53 AM, wrote:
    > On 11 aug, 11:04, "Bill Cunningham"<> wrote:


    [It really doesn't matter what he wrote]

    > I'm sorry, I can't understand you... could you explain exactly what
    > you want to achieve?


    It seems unlikely. Bill's been around here spouting impenetrable
    nonsense for quite some time, there's no indication that that will
    change any time soon.

    Some say that he is a troll, others that he has cognitive issues. (All I
    know is he's not the Stig!)

    Over the time I've been reading this newsgroup, there has been no sign
    that Bill learns from any information given to him. Because of this,
    many people have given up bothering with his posts.

    I only see him in people's replies, as I have him kill-filed.
    Mark Bluemel, Aug 11, 2011
    #4
  5. Gordon Burditt wrote:
    >> I have been looking for a function from ANSI C that would start
    >> out with a buffer size of zero initialized and would grow to a
    >> certain size. I have

    >
    > A buffer is not of size zero. C doesn't have zero-sized objects.
    > Even if it did, you can't initialize a zero-sized buffer without
    > overflowing it.
    >
    >> already been able to set aside a 32 byte type using malloc(). Could
    >> calloc()

    >
    > You can use realloc() to change the size of a malloc()ed buffer
    > (upwards or downwards). You can use memset() to clear, for example,
    > the newly-allocated part of the buffer (assuming the size grew).
    > Or, your code can fill in the appropriate values.


    Ok. That may be what I'm looking for.

    > Beware that memset() is not appropriate to initialize struct elements
    > that are pointers or floating-point types (if that's what you are
    > going to put in the buffer) where all-bits-zero doesn't guarantee
    > a specific value. A NULL pointer is not guaranteed to be represented
    > as the bit pattern 0xdeadbeef even on machines where pointers are
    > 32-bits.
    >
    >> be what I'm looking for? This buffer would be able to grow by a
    >> mechanism that would include using fscanf to find the size of a file
    >> in bytes. So my

    >
    > By the time you have found out the size of a file in bytes, the size
    > of that file might have already changed. If you take one pass through
    > the file to calculate its size, allocate that much memory, and then
    > read the file again, you might end up overflowing the file or losing
    > the last part of it if it grows between passes.


    Oh ok I see I didn't know that.

    > You can allocate an initial buffer, and keep growing the buffer
    > (usually *NOT* by one byte at a time; this is horribly inefficient)
    > with realloc() as needed until you've read the whole file. Some
    > people like doubling the size of the buffer each time. Then,
    > perhaps, you can shrink the buffer down to the actual size used.
    > The file still might grow while or after you finish reading it.
    >
    >> question is simply is there any functions or ways in c89 to fill a
    >> buffer to a certain size before it's clear?

    >
    > Filling a buffer does not change its size (unless you specifically
    > code a call to realloc() in this situation). Changing the size of
    > a buffer with realloc() does not "clear" it - the data in the minimum
    > size of the buffer before and after the realloc() is preserved.
    >
    > This question does not make any sense. Please define the word
    > "clear" as you use it here.


    I meant clear"ed". A typo. As in void free(void *)

    I don't think that "filled with zero
    > bytes" nor "transparent; lacking color and colour" makes sense here.
    > Neither is the question "clear".
    >
    >> int buffer[] won't work unless it's a
    >> char.

    >
    > int buffer[] as a definition won't work even if <it> is a char,
    > regardless of what <it> refers to. You have to specify a (nonzero)
    > size.
    Bill Cunningham, Aug 11, 2011
    #5
  6. Mark Bluemel wrote:
    > On 08/11/2011 10:53 AM, wrote:

    [whatever]
    >
    >
    > I only see him in people's replies, as I have him kill-filed.


    He's looking for a 'self growing linked list storage',
    which unfortunately is (to my knowledge) not a part
    of _any_ programming language that I know of :p

    -rasp
    Ralph Spitzner, Aug 11, 2011
    #6
  7. Bill Cunningham

    John Gordon Guest

    In <4e439af9$0$7278$> "Bill Cunningham" <> writes:

    > I have been looking for a function from ANSI C that would start out with
    > a buffer size of zero initialized and would grow to a certain size. I have


    If you want a buffer that grows, malloc and realloc sound like a perfect
    fit.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
    John Gordon, Aug 11, 2011
    #7
  8. Ralph Spitzner <> writes:

    > Mark Bluemel wrote:
    >> On 08/11/2011 10:53 AM, wrote:

    > [whatever]
    >>
    >>
    >> I only see him in people's replies, as I have him kill-filed.

    >
    > He's looking for a 'self growing linked list storage',
    > which unfortunately is (to my knowledge) not a part
    > of _any_ programming language that I know of :p


    Haskel does. Bill wants to read a file, and Haskell's getContents is
    just that. Because it's value is a lazy list, it will grow as needed
    and, for that matter, it will also shrink as needed.

    --
    Ben.
    Ben Bacarisse, Aug 11, 2011
    #8
  9. On Aug 11, 12:04 pm, "Bill Cunningham" <> wrote:
    >     I have been looking for a function from ANSI C that would start out with
    > a buffer size of zero initialized and would grow to a certain size. I have
    > already been able to set aside a 32 byte type using malloc(). Could calloc()
    > be what I'm looking for? This buffer would be able to grow by a mechanism
    > that would include using fscanf to find the size of a file in bytes. So my
    > question is simply is there any functions or ways in c89 to fill a bufferto
    > a certain size before it's clear? int buffer[] won't work unless it's a
    > char.
    >

    You need realloc().

    Start with a null pointer and a buffer of size zero. Then grow by a
    bit each time. I usually use the formula new_size = (size_t) (oldsize
    * 1.1 + 100). This means that the buffer grows by 10% each time, plus
    a bit, so you don't have too many reallocations when it is small, and
    you don't take up too much memory when it is large.

    realloc() won't initialise data for you. You'll have to do that by
    hand. There ought to be a recalloc() which zero-initialises data, but
    there isn't.
    Malcolm McLean, Aug 11, 2011
    #9
  10. Malcolm McLean wrote:
    > On Aug 11, 12:04 pm, "Bill Cunningham" <> wrote:
    >> I have been looking for a function from ANSI C that would start out
    >> with
    >> a buffer size of zero initialized and would grow to a certain size.
    >> I have already been able to set aside a 32 byte type using malloc().
    >> Could calloc() be what I'm looking for? This buffer would be able to
    >> grow by a mechanism that would include using fscanf to find the size
    >> of a file in bytes. So my question is simply is there any functions
    >> or ways in c89 to fill a buffer to a certain size before it's clear?
    >> int buffer[] won't work unless it's a char.
    >>

    > You need realloc().
    >
    > Start with a null pointer and a buffer of size zero. Then grow by a
    > bit each time. I usually use the formula new_size = (size_t) (oldsize
    > * 1.1 + 100). This means that the buffer grows by 10% each time, plus
    > a bit, so you don't have too many reallocations when it is small, and
    > you don't take up too much memory when it is large.
    >
    > realloc() won't initialise data for you. You'll have to do that by
    > hand. There ought to be a recalloc() which zero-initialises data, but
    > there isn't.


    Just what I need. Thanks very much.

    Bill
    Bill Cunningham, Aug 11, 2011
    #10
  11. Ben Bacarisse wrote:

    > What an odd statement! Fortunately I don't need to know what you mean
    > by it.


    Brain fart! As usual sometimes I don't know what I've talking about.

    Bill
    Bill Cunningham, Aug 14, 2011
    #11
  12. On Aug 13, 9:32 am, "io_x" <> wrote:
    >
    > why not 2x the buffer each time,
    > and realloc to actual size at end for the input?
    > it mess the malloc memory?
    >

    That's not too bad a strategy.

    The problem is that if your buffer is very close to the system-imposed
    limit, doubling may take it over that limit when in fact there are
    enough resources to run your algorithm. Increasing by 10% is less
    likely to do that.
    Malcolm McLean, Aug 15, 2011
    #12
  13. Malcolm McLean wrote:

    > That's not too bad a strategy.
    >
    > The problem is that if your buffer is very close to the system-imposed
    > limit, doubling may take it over that limit when in fact there are
    > enough resources to run your algorithm. Increasing by 10% is less
    > likely to do that.


    Can you show me an example of code using malloc realloc and fread to use
    this type of buffer?

    Bill
    Bill Cunningham, Aug 28, 2011
    #13
  14. On Aug 28, 11:11 am, "Bill Cunningham" <> wrote:
    > Malcolm McLean wrote:
    >
    >     Can you show me an example of code using malloc realloc and freadto use
    > this type of buffer?
    >
    > Bill


    /*
    read integers from a file
    assume that int is 32 bit, and that endianness is native. End of
    file = end of data
    fp - open file
    N - return for number of integers read
    Out of memory: returns 0, N = -1;
    IO error: returns 0, N = -2;

    Note: untested code. Might have bugs in it.
    */
    int *readintsfromfile(FILE *fp, int *N)
    {
    int *answer = 0;
    int *temp;
    int bufsize = 100;
    int Nread = 0;
    int x;

    answer = malloc(bufsize * 4);
    if(!answer)
    goto outofmemory;
    while(fread(&x, 4, 1, fp) == 1)
    {
    answer[Nread++] = x;
    if(Nread == bufsize)
    {
    buffsize = bufsize + bufsize/10;
    temp = realloc(answer, bufsize * 4);
    if(!temp)
    goto outofmemory;
    answer = temp;
    }
    }
    if(ferror(fp))
    goto readerror;
    *N = Nread;
    return answer;
    outofmeomory:
    free(answer);
    *N = -1;
    return 0;
    readerror:
    free(answer);
    *N = -2;
    return 0;
    }
    Malcolm McLean, Aug 29, 2011
    #14
  15. Bill Cunningham

    Nobody Guest

    On Mon, 29 Aug 2011 05:00:38 -0500, Gordon Burditt wrote:

    > Use of 16-bit or 32-bit chars might also be appropriate if the native
    > character set is Unicode.


    Not really. The question isn't the size of a "character", but the size of
    the smallest "unit" of data which you wish to handle, as you can't have
    any object smaller than a "char".

    Which tends to mean that 16/32-bit "char" is reserved for highly
    specialised architectures which don't need to deal with file formats,
    network protocols, etc.
    Nobody, Aug 29, 2011
    #15
  16. Malcolm McLean wrote:
    > /*
    > read integers from a file
    > assume that int is 32 bit, and that endianness is native. End of
    > file = end of data
    > fp - open file
    > N - return for number of integers read
    > Out of memory: returns 0, N = -1;
    > IO error: returns 0, N = -2;
    >
    > Note: untested code. Might have bugs in it.
    > */
    > int *readintsfromfile(FILE *fp, int *N)
    > {
    > int *answer = 0;
    > int *temp;
    > int bufsize = 100;
    > int Nread = 0;
    > int x;
    >
    > answer = malloc(bufsize * 4);
    > if(!answer)
    > goto outofmemory;
    > while(fread(&x, 4, 1, fp) == 1)
    > {
    > answer[Nread++] = x;
    > if(Nread == bufsize)
    > {
    > buffsize = bufsize + bufsize/10;
    > temp = realloc(answer, bufsize * 4);
    > if(!temp)
    > goto outofmemory;
    > answer = temp;
    > }
    > }
    > if(ferror(fp))
    > goto readerror;
    > *N = Nread;
    > return answer;
    > outofmeomory:
    > free(answer);
    > *N = -1;
    > return 0;
    > readerror:
    > free(answer);
    > *N = -2;
    > return 0;
    > }


    Excellent. Myself I might have used switch instead of goto or better yet
    maybe confused myself with a string of if ,else if, and else statements. In
    binary transfer would it be alright to use char* anyway? Transfer one byte
    at 512, 1024 groups.

    Bill
    Bill Cunningham, Aug 30, 2011
    #16
  17. "Bill Cunningham" <> writes:

    > Malcolm McLean wrote:
    >> /*
    >> read integers from a file
    >> assume that int is 32 bit, and that endianness is native. End of
    >> file = end of data
    >> fp - open file
    >> N - return for number of integers read
    >> Out of memory: returns 0, N = -1;
    >> IO error: returns 0, N = -2;
    >>
    >> Note: untested code. Might have bugs in it.
    >> */
    >> int *readintsfromfile(FILE *fp, int *N)
    >> {
    >> int *answer = 0;
    >> int *temp;
    >> int bufsize = 100;
    >> int Nread = 0;
    >> int x;
    >>
    >> answer = malloc(bufsize * 4);
    >> if(!answer)
    >> goto outofmemory;
    >> while(fread(&x, 4, 1, fp) == 1)
    >> {
    >> answer[Nread++] = x;
    >> if(Nread == bufsize)
    >> {
    >> buffsize = bufsize + bufsize/10;
    >> temp = realloc(answer, bufsize * 4);
    >> if(!temp)
    >> goto outofmemory;
    >> answer = temp;
    >> }
    >> }
    >> if(ferror(fp))
    >> goto readerror;
    >> *N = Nread;
    >> return answer;
    >> outofmeomory:
    >> free(answer);
    >> *N = -1;
    >> return 0;
    >> readerror:
    >> free(answer);
    >> *N = -2;
    >> return 0;
    >> }

    >
    > Excellent. Myself I might have used switch instead of goto [...]


    How?

    <snip>
    --
    Ben.
    Ben Bacarisse, Aug 30, 2011
    #17
  18. Bill Cunningham wrote:
    > Malcolm McLean wrote:
    >> /*
    >> read integers from a file
    >> assume that int is 32 bit, and that endianness is native. End of
    >> file = end of data
    >> fp - open file
    >> N - return for number of integers read
    >> Out of memory: returns 0, N = -1;
    >> IO error: returns 0, N = -2;
    >>
    >> Note: untested code. Might have bugs in it.
    >> */
    >> int *readintsfromfile(FILE *fp, int *N)
    >> {
    >> int *answer = 0;
    >> int *temp;
    >> int bufsize = 100;
    >> int Nread = 0;
    >> int x;
    >>
    >> answer = malloc(bufsize * 4);
    >> if(!answer)
    >> goto outofmemory;
    >> while(fread(&x, 4, 1, fp) == 1)
    >> {
    >> answer[Nread++] = x;
    >> if(Nread == bufsize)
    >> {
    >> buffsize = bufsize + bufsize/10;
    >> temp = realloc(answer, bufsize * 4);
    >> if(!temp)
    >> goto outofmemory;
    >> answer = temp;
    >> }
    >> }
    >> if(ferror(fp))
    >> goto readerror;
    >> *N = Nread;
    >> return answer;
    >> outofmeomory:
    >> free(answer);
    >> *N = -1;
    >> return 0;
    >> readerror:
    >> free(answer);
    >> *N = -2;
    >> return 0;
    >> }

    >
    > Excellent. Myself I might have used switch instead of goto or
    > better yet maybe confused myself with a string of if ,else if, and
    > else statements. In binary transfer would it be alright to use char*
    > anyway? Transfer one byte at 512, 1024 groups.
    >
    > Bill


    Thing is. that's using a doubling and not 10%.

    Bill
    Bill Cunningham, Aug 30, 2011
    #18
  19. Ben Bacarisse wrote:
    > "Bill Cunningham" <> writes:
    >
    >> Malcolm McLean wrote:
    >>> /*
    >>> read integers from a file
    >>> assume that int is 32 bit, and that endianness is native. End of
    >>> file = end of data
    >>> fp - open file
    >>> N - return for number of integers read
    >>> Out of memory: returns 0, N = -1;
    >>> IO error: returns 0, N = -2;
    >>>
    >>> Note: untested code. Might have bugs in it.
    >>> */
    >>> int *readintsfromfile(FILE *fp, int *N)
    >>> {
    >>> int *answer = 0;
    >>> int *temp;
    >>> int bufsize = 100;
    >>> int Nread = 0;
    >>> int x;
    >>>
    >>> answer = malloc(bufsize * 4);
    >>> if(!answer)
    >>> goto outofmemory;
    >>> while(fread(&x, 4, 1, fp) == 1)
    >>> {
    >>> answer[Nread++] = x;
    >>> if(Nread == bufsize)
    >>> {
    >>> buffsize = bufsize + bufsize/10;
    >>> temp = realloc(answer, bufsize * 4);
    >>> if(!temp)
    >>> goto outofmemory;
    >>> answer = temp;
    >>> }
    >>> }
    >>> if(ferror(fp))
    >>> goto readerror;
    >>> *N = Nread;
    >>> return answer;
    >>> outofmeomory:
    >>> free(answer);
    >>> *N = -1;
    >>> return 0;
    >>> readerror:
    >>> free(answer);
    >>> *N = -2;
    >>> return 0;
    >>> }

    >>
    >> Excellent. Myself I might have used switch instead of goto [...]

    >
    > How?
    >
    > <snip>


    That would involve coding a different style and not leaving all the
    labels for the end of the code and making things more confusing by having to
    whack up code and end large chunks with break; constantly. As I said it
    would probably look like a mess. Better left the way it is.

    Bill
    Bill Cunningham, Aug 30, 2011
    #19
  20. On Aug 30, 3:43 am, "Bill Cunningham" <> wrote:
    >
    >     Excellent. Myself I might have used switch instead of goto or better yet
    > maybe confused myself with a string of if ,else if, and else statements. In
    > binary transfer would it be alright to use char* anyway? Transfer one byte
    > at 512, 1024 groups.
    >

    Yes. Normally it's easier to read binary data as unsigned chars using
    fgetc(). However you can use fread.
    --
    Website
    http://www.malcolmmclean.site11.com/www
    Play Amino Invaders.
    Malcolm McLean, Aug 30, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. James Vanns
    Replies:
    7
    Views:
    7,014
    Evan Carew
    Jan 21, 2004
  2. komal
    Replies:
    6
    Views:
    1,409
    msalters
    Jan 25, 2005
  3. Replies:
    2
    Views:
    897
    Bengt Richter
    Aug 1, 2005
  4. Giannis Papadopoulos

    Function pointer to void function and int function

    Giannis Papadopoulos, Sep 5, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,218
    Barry Schwarz
    Sep 5, 2005
  5. weafon
    Replies:
    1
    Views:
    291
    Diez B. Roggisch
    Jul 14, 2009
Loading...

Share This Page