Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #9195 > unrolled thread

function

Back to article view | Back to comp.lang.c

Contents

  function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-11 05:04 -0400
    Re: function Mark Bluemel <mark_bluemel@pobox.com> - 2011-08-11 11:36 +0100
      Re: function Ralph Spitzner <rasp@spitzner.org> - 2011-08-11 14:13 +0200
        Re: function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-11 15:12 +0100
    Re: function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-11 06:45 -0400
    Re: function John Gordon <gordon@panix.com> - 2011-08-11 14:03 +0000
    Re: function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-08-11 07:14 -0700
      Re: function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-11 17:16 -0400
      Re: function "io_x" <a@b.c.invalid> - 2011-08-13 08:32 +0200
        Re: function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-08-15 04:08 -0700
          Re: function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-28 04:11 -0400
            Re: function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-08-29 00:03 -0700
              Re: function gordonb.kyfki@burditt.org (Gordon Burditt) - 2011-08-29 05:00 -0500
                Re: function Nobody <nobody@nowhere.com> - 2011-08-29 19:58 +0100
              Re: function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-29 20:43 -0400
                Re: function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-30 01:48 +0100
                  Re: function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-29 21:14 -0400
                Re: function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-29 20:52 -0400
                Re: function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-08-30 01:08 -0700
    Re: function "Bill Cunningham" <nospam@nspam.invalid> - 2011-08-14 17:43 -0400

#9195 — function

    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

[toc] | [next] | [standalone]

#9200

On 08/11/2011 10:53 AM, lolzy@live.nl wrote:
> On 11 aug, 11:04, "Bill Cunningham"<nos...@nspam.invalid>  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.

[toc] | [prev] | [next] | [standalone]

#9205

Mark Bluemel wrote:
> On 08/11/2011 10:53 AM, lolzy@live.nl 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

[toc] | [prev] | [next] | [standalone]

#9212

Ralph Spitzner <rasp@spitzner.org> writes:

> Mark Bluemel wrote:
>> On 08/11/2011 10:53 AM, lolzy@live.nl 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.

[toc] | [prev] | [next] | [standalone]

#9201

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. 

[toc] | [prev] | [next] | [standalone]

#9211

In <4e439af9$0$7278$bbae4d71@news.suddenlink.net> "Bill Cunningham" <nospam@nspam.invalid> 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
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#9213

On Aug 11, 12:04 pm, "Bill Cunningham" <nos...@nspam.invalid> 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.

[toc] | [prev] | [next] | [standalone]

#9232

Malcolm McLean wrote:
> On Aug 11, 12:04 pm, "Bill Cunningham" <nos...@nspam.invalid> 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

[toc] | [prev] | [next] | [standalone]

#9325

"Malcolm McLean" <malcolm.mclean5@btinternet.com> ha scritto nel messaggio
news:769e6acc-b1bd-484f-a6fb-166588f26b1d@b19g2000yqj.googlegroups.com...
On Aug 11, 12:04 pm, "Bill Cunningham" <nos...@nspam.invalid> 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.

why not 2x the buffer each time,
and realloc to actual size at end for the input?
it mess the malloc memory?


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

[toc] | [prev] | [next] | [standalone]

#9425

On Aug 13, 9:32 am, "io_x" <a...@b.c.invalid> 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.

[toc] | [prev] | [next] | [standalone]

#9697

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

[toc] | [prev] | [next] | [standalone]

#9703

On Aug 28, 11:11 am, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> Malcolm McLean wrote:
>
>     Can you show me an example of code using malloc realloc and fread to 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;
}

[toc] | [prev] | [next] | [standalone]

#9704

> /*
>  read integers from a file
>   assume that int is 32 bit, and that endianness is native. 

These assumptions are not sufficient to guarantee that sizeof(int)
== 4.  For example, chars might be 16 or 32 bit (and there are some
real signal-processing microcontrollers which use 32-bit chars).
Use of 16-bit or 32-bit chars might also be appropriate if the native
character set is Unicode.


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

Your documentation fails to state that the pointer returned by this
function is allocated with malloc() and it is the caller's
responsibility to free() it.  This is, of course, only a style
issue.  Forgetting to free() pointers returned from a (programmer-defined)
function is a common source of memory leaks, so you should put a
reminder in with comments for the function.

>  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);

Using sizeof(*answer) or sizeof(int) is more portable than using 4
here.  There's been a lot of comp.lang.c discussion about which of
these 2 alternatives I gave is better.  I'll suggest here that if
the file format is significantly more "cast in stone" than the type
of "answer", (suggested here by the name of the function), then in
this case sizeof(int) might be clearer, although the decision
might hinge on whether the specification for the input file said
"32-bit little endian integers" vs. "C native-endian ints".


>  if(!answer)
>    goto outofmemory;
>  while(fread(&x, 4, 1, fp) == 1)
The same issue of using 4 as the size of an int applies here.

>  {
>    answer[Nread++] = x;
>    if(Nread == bufsize)
>    {
>      buffsize = bufsize + bufsize/10;

Careful of your spelling.  I assume you mean
bufsize in 3 places in the line above, as you
don't declare a buffsize.

>      temp = realloc(answer, bufsize * 4);
The same issue of using 4 as the size of an int applies here.

>      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;
> }

It might be polite to realloc() the buffer *DOWN* in size to the
number of integers actually read after you've hit end-of-file and
know how many there are.  This is more of an issue should you call
this function in a loop on many different files and keep the results
around so that you can do something with the data (e.g. merge and
sort it, graph it, remove the duplicates, or whatever).

[toc] | [prev] | [next] | [standalone]

#9712

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.

[toc] | [prev] | [next] | [standalone]

#9715

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

[toc] | [prev] | [next] | [standalone]

#9716

"Bill Cunningham" <nospam@nspam.invalid> 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.

[toc] | [prev] | [next] | [standalone]

#9719

Ben Bacarisse wrote:
> "Bill Cunningham" <nospam@nspam.invalid> 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

[toc] | [prev] | [next] | [standalone]

#9718

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

[toc] | [prev] | [next] | [standalone]

#9725

On Aug 30, 3:43 am, "Bill Cunningham" <nos...@nspam.invalid> 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.

[toc] | [prev] | [next] | [standalone]

#9410

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web