In article <861e0a94-345b-4aaf-8cb0-7b1864695f48@w4 g2000prd.google groups.com>,
<jty0734@naver. comwrote:
>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.
>
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.
/* Get sufficient memory to hold a copy of s */
void *mallocforstrin g(char *s) {
void *p;
if ((p = malloc(1 + strlen(s))) return p;
else {
puts(" No memory available");
exit(EXIT_FAILU RE);
}
}
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
On 18 May 2008 at 13:10, Jens Thoms Toerring wrote:
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.
In article <483030D7.5E032 5AB@yahoo.com>,
CBFalconer <cbfalconer@mai neline.netwrote :
>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.
>/* 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.
On May 18, 5:00 pm, silly troll <nos...@nospam. invalidwrote:
On 18 May 2008 at 13:10, Jens Thoms Toerring wrote:
>
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.
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.
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?
int get_line(char **lineptr, size_t *n, FILE *stream);
int main(void)
{
int rc;
char *buff = NULL;
size_t size = 0;
puts("/* BEGIN new.c output */\n");
puts(
"Just hit the Enter key to end,\n"
"or enter any line of characters to continue.");
while ((rc = get_line(&buff, &size, stdin)) 1) {
puts("\nYour input string is:");
puts(buff);
puts("\n\nJust hit the Enter key to end,\n"
"or enter any line of characters to continue");
}
free(buff);
puts("\n/* END new.c output */");
return 0;
}
int get_line(char **lineptr, size_t *n, FILE *stream)
{
int rc;
void *p;
size_t count;
In article <slrng30dkq.igv .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:
>On 18 May 2008 at 13:10, Jens Thoms Toerring wrote:
>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.
"Antoninus Twink" <nospam@nospam. invalidwrote in message
On 18 May 2008 at 13:10, Jens Thoms Toerring wrote:
>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.
>
ggets() will become unacceptably slow on maliciously large inputs. However a
very large number of programs can be slowed to a crawl by feeding them large
datasets.
Whilst it is certainly a weakness, ggets() is perfectly usable.
A semi-standard function, on the other hand, will cause real problems if
ported to a platform where it is not avialable.
In article <tvidncGL-IU7_q3VnZ2dnUVZ 8tPinZ2d@bt.com >,
Malcolm McLean <regniztar@btin ternet.comwrote :
>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.
>>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.
>
>/* 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.
That is not clear from the enquiry. He may simply not know that
strlen measures string lengths. At any rate, if your
interpretation is correct, then my ggets does the job, as
referenced elsewhere.
Please don't strip attribution lines for any material you quote.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
>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.
ggets is envisioned for primary use in interactive applications.
It will still function correctly when reading long lines from
files, but this is expected to be very rare. Most operators get
somewhat tired of typing after 250 to 500 input chars per line.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
"CBFalconer " <cbfalconer@yah oo.comwrote in message
ggets is envisioned for primary use in interactive applications.
It will still function correctly when reading long lines from
files, but this is expected to be very rare. Most operators get
somewhat tired of typing after 250 to 500 input chars per line.
>
The user can often pipe newline-free sequences to stdin, thus opening the
way for a denial of service attack.
However if he's running, for example, my Basic interpreter he can easily
achieve the same effect just by typing
10 DIM x(100,100,100,1 00)
gobbling almost all the memory in the machine. So in this case avoiding
ggets() gains no additional safety.
On 18 May 2008 at 13:10, Jens Thoms Toerring wrote:
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.
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?
Comment