Determine the size of malloc

J

jty0734

i don't know what input size of string is.

so i can't gets inputsize before malloc function.

i want determine the size of malloc without get inputsize in advance.

how to deal with it?
 
R

Richard Tobin

i don't know what input size of string is.

so i can't gets inputsize before malloc function.

i want determine the size of malloc without get inputsize in advance.

how to deal with it?

Allocate a reasonable amount, and if it overflows realloc() it.

-- Richard
 
J

Jens Thoms Toerring

i don't know what input size of string is.
so i can't gets inputsize before malloc function.
i want determine the size of malloc without get inputsize in advance.
how to deal with it?

I can only guess what you're writing about. Do you want to know
the length of a string that you're going to read in before you
actually have read it in in order to allocate enough memory for
the string? If that's the case then you're unfortunately out
of luck. You can't know the length of a string before you have
read it in completely. Predicting the future is simply hard to
do...

What you normally do in cases where you want to read in a string
of arbitrary length which you want to store in dynamically allo-
cated memory is to start by allocating some amount of memory
(e.g. 128 bytes, but any other non-zero guess will also do).
Then you read in not more than fits into that amount of memory.
If you find that the whole string already fits into this buffer
you're done. Otherwise you increase the size of your buffer by
allocating more memory using realloc() and con- tinue to read
until also this increased buffer is full or you reached the end
of the string. In case you still didn't reach the end you again
allocate more memory with realloc() and continue as above. In
the end you have ethe whole string stored in allocated memory
if you haven't run out of memory before.

Some friendly people have already taken the time to write a
function just doing this, see e.g. the ggets() function by
C.B. Falconer:

http://cbfalconer.home.att.net/download/ggets.zip

Regards, Jens
 
A

Antoninus Twink

Some friendly people have already taken the time to write a
function just doing this, see e.g. the ggets() function by
C.B. Falconer:

*Please* don't recommend this garbage to unsuspecting newbies who might
actually use it. The many problems of ggets have been discussed over and
over again in this group, and Falconer has always shown his usual
pig-headedness in refusing to accept any criticism.

The OP should investigate whatever functions are provided as standard by
his implementation: GNU getline() or fgetln() or similar.
 
R

Richard Tobin

i don't know what input size of string is. so i can't gets
inputsize before malloc function. i want determine the size of
malloc without get inputsize in advance.
[/QUOTE]
/* Get sufficient memory to hold a copy of s */

You would never pass the Turing test. He's trying
to input a string, so he can't use strlen() to get its size.

-- Richard
 
V

vippstar

*Please* don't recommend this garbage to unsuspecting newbies who might
actually use it. The many problems of ggets have been discussed over and
over again in this group, and Falconer has always shown his usual
pig-headedness in refusing to accept any criticism.

The OP should investigate whatever functions are provided as standard by
his implementation: GNU getline() or fgetln() or similar.

These functions are OT for this group. You know that, but you suggest
them regardless. CBFalconers ggets() is ISO C code, which you can (I
suppose) copy to your code. Even if you copy the code of GNUs
getline() into your code, it still won't be valid ISO C; If you are
interested to learn why, get glibc and look at libio/iogetdelim.c
(it's the function getline() calls). The implementation is not valid
ISO C.
Last, I don't agree that ggets() is 'trash'. Having read the code, the
function does exactly what it claims to do, without any hackery
involved.
 
K

Kenny McCormack

*Please* don't recommend this garbage to unsuspecting newbies who might
actually use it. The many problems of ggets have been discussed over and
over again in this group, and Falconer has always shown his usual
pig-headedness in refusing to accept any criticism.

The OP should investigate whatever functions are provided as standard by
his implementation: GNU getline() or fgetln() or similar.

Hush. There you go. Being sensible again.
 
R

Richard Tobin

Malcolm McLean said:
ggets() will become unacceptably slow on maliciously large inputs.

Presumably you are referring to its apparent n^2 behaviour because of
its using a fixed increment when reallocating. With a good C library
implementation this will probably not be a problem, because realloc()
itself will use a better strategy, and most calls to it will be
no-ops.

-- Richard
 
T

thomas.mertes

I can only guess what you're writing about. Do you want to know
the length of a string that you're going to read in before you
actually have read it in in order to allocate enough memory for
the string? If that's the case then you're unfortunately out
of luck. You can't know the length of a string before you have
read it in completely. Predicting the future is simply hard to
do...

What you normally do in cases where you want to read in a string
of arbitrary length which you want to store in dynamically allo-
cated memory is to start by allocating some amount of memory
(e.g. 128 bytes, but any other non-zero guess will also do).
Then you read in not more than fits into that amount of memory.
If you find that the whole string already fits into this buffer
you're done. Otherwise you increase the size of your buffer by
allocating more memory using realloc() and con- tinue to read
until also this increased buffer is full or you reached the end
of the string. In case you still didn't reach the end you again
allocate more memory with realloc() and continue as above. In
the end you have ethe whole string stored in allocated memory
if you haven't run out of memory before.

Some friendly people have already taken the time to write a
function just doing this, see e.g. the ggets() function by
C.B. Falconer:

http://cbfalconer.home.att.net/download/ggets.zip

Although developed independent my filLineRead() function
is very similar to ggets(). It can be found in the file
seed7/src/fil_rtl.c of the Seed7 package. Some things
are important when reading strings this way.

- The function gets() cannot be used. Instead the
functions ggets() and filLineRead() use getc() to
read single characters until EOF or \n is reached.
- Both functions (ggets() and filLineRead() ) use some
initial size for the buffer and some increment size
which is used to realloc the buffer.
- When the line has been read a final realloc()
resizes the buffer to the correct size.

But there are also differences between ggets() and
filLineRead():

- The function filLineRead() returns also the
termination_char which can be \n or EOF;
- The function filLineRead() removes a \r if it
preceedes the \n .
- The function filLineRead() returns a stritype
which is the string type used in the hi interpreter
and the Seed7 runtime library (The Seed7 strings
are not \0 terminated and therefore can contain
also binary data).

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
J

Jens Thoms Toerring

*Please* don't recommend this garbage to unsuspecting newbies who might
actually use it.

It works, it's written in standard C and it's a readable example
of the method I tried to describe, so why is it garbage? If you
have some better reference then tell the OP about it but don't
call other peoples work "garbage" without giving at least some
good explanation for your opinion.

Of course, I have my own version of a ggets() function (which
works a bit differently) but in contrast to C.B. Falconer I did
not take the time to make it available as an easy to use package.
If *you* have something better simply publish it - and I hope
you will be able to deal with the criticism you're likely to
receive. If it's really better I will happily recommend it.
The many problems of ggets have been discussed over and
over again in this group, and Falconer has always shown his usual
pig-headedness in refusing to accept any criticism.

When it's about "pig-headedness in refusing to accept any
criticism" I can only say pot, kettle,...
The OP should investigate whatever functions are provided as standard by
his implementation: GNU getline() or fgetln() or similar.

Since when has GNU become a "standard"? And where's the code
for the OP to look at? I strongly suspect that the OP will
have a lot of problems just finding the getline() function
in the GNU libc and it's not unlikely that it will not be
written in a portable way. And the only link I could find
for a fgetln() function that does the things C.B. Falconer's
(f)ggets() function does is BSD/MacOSX specific and the
available source code is neither portable at all nor easy
to understand (and does not even return a string but a
pointer rather likely to point somewhere into the innards
of the stdio buffers). Finally, what makes you believe that
the OP is using a GNU libc or BSD/MacOSX based system?
 
I

Ian Collins

Jens said:
It works, it's written in standard C and it's a readable example
of the method I tried to describe, so why is it garbage?

Because that's what trolls do, disrupt newsgroups.

I would also recommend the OP looks at Chuck's ggets().
 
R

Richard Tobin

The user can often pipe newline-free sequences to stdin, thus opening the
way for a denial of service attack.

It would be absurd to rely on every program to idividually prevent
this kind of attack. If your system is set up so that untrusted users
can send arbitrary data to programs not specially written to handle
it, you should make use of your operating system's facilities for
limiting process memory and cpu use.

-- Richard
 
A

Antoninus Twink

Because that's what trolls do, disrupt newsgroups.

I suggest you check the group archives. One of the most severe critics
of CBF's ggets is Heathfield himself - is he a troll now?
I would also recommend the OP looks at Chuck's ggets().

If you insist on recommending clc-compliant ANSI-standard blah-di-blah,
rather than the solution provided by one's implementation, then there's
also a getline module by Sossman floating around, which is a /much/
better piece of coding than CBF's attempt.
 
I

Ian Collins

Antoninus said:
If you insist on recommending clc-compliant ANSI-standard blah-di-blah,
rather than the solution provided by one's implementation, then there's
also a getline module by Sossman floating around, which is a /much/
better piece of coding than CBF's attempt.
Note I said "look at". ggets() is an example of how to solve the OP's
problem with portable code. Only the OP can decide whether a piece of
code meets his or her needs.
 
E

Eligiusz Narutowicz

Ian Collins said:
Note I said "look at". ggets() is an example of how to solve the OP's
problem with portable code. Only the OP can decide whether a piece of
code meets his or her needs.

I am sorry too. But I was looking please at this code and it is being
poorly formatted and naive in almost all aspects of functionality. I
emailed the man my suggestions to improve but recieved no replies.
 
I

Ian Collins

Eligiusz said:
I am sorry too. But I was looking please at this code and it is being
poorly formatted and naive in almost all aspects of functionality. I
emailed the man my suggestions to improve but recieved no replies.
Now that's unfair, there's nothing wrong with the formatting (OK, it is
infected with DOS line endings, but that's easy to fix). The only
"naive" aspect is the fixed increment size, but any profiler would show
that to be a problem, if it is one at all.
 
K

Keith Thompson

CBFalconer said:
The standard allows for a limitation to the buffers used for
stdin/stdout. The limit is somewhere in the 512 to 4096 byte
area. An intelligent implementation will enforce a nl at those
points.

Why on Earth would it do that?

The systems I use (and, I suspect, the systems you use as well) impose
no limit on the length of a line in a text file. I can't think of any
good reason not to allow a line to be bigger than the buffer size
(which should be nearly invisible to the program anyway). Reading a
very long line might require reading multiple buffers. So what?
 
C

Chris Dollin

Malcolm said:
How sophisticated can an expanding buffer be?

Arbitrarily sophisticated. It depends on what the costs are and
what the data profile is.

Of course one shouldn't go for a complicated solution if one doesn't
need it.
 
R

Richard Tobin

The standard allows for a limitation to the buffers used for
stdin/stdout. The limit is somewhere in the 512 to 4096 byte
area. An intelligent implementation will enforce a nl at those
points.

Can you name one that does? So that I can avoid it. I prefer
implementations that don't corrupt my data.

-- Richard
 
N

Nick Keighley

Can you name one that does?  So that I can avoid it.  I prefer
implementations that don't corrupt my data.

I *think* DOS had a limit on the command line length.
(I don't know if it stuck a \n in).
This has been argued as a safe way to use gets()
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top