> CBFalconer <cbfalco...@yahoo.com> writes:

... snip ...

> See, I dunno -- you're trying to devise a library function that's
> idiot-proof? No way. I think you've just replaced one POLA violation
> with another: gets() will cheerfully overrun the buffer passed to it;
> your ggets() will cheerfully use whatever memory it can get its hands
> on. When a simple library function does that I think something's
> wrong.

> [snip]
> > Experiment at your console.  Just hold down some key for input,
> > and see how long a line you can generate from the keyboard.  I am
> > morally certain you will find a limit.

> > /* FILE longline.c */
> > #include <stdio.h>
> > #include <string.h>
> > #include "ggets.h"

> > int main(void)
> > {
> >   char * ln;

> >   ln = ggets();
> >   printf("\nlinelength was %d\n", (int)strlen(ln));
> >   return 0;
> > }

> > On my machine this spat out 127.  First there was much beeping and
> > input was rejected until I finally hit return.  From a file things
> > can get much longer.  When I made a file with 530 a's and a
> > newline, I got back 530 with "longline <longline.txt".  I also
> > tried it on 4 binaries, and never got anything over 5.

> Dude, tell me this is not how you've tested this?! It makes me wonder
> if you've ever actually executed the code for when memory runs out...

> If your argument is that there's almost always a newline at some
> point, all you need is to pass a big enough buffer to gets().

> I've compiled it & tested it a little, but don't have time at the
> moment to do a proper job. Did you test on files or input with no
> newlines at all? I got no output back at all from tggets. None at
> all. But figuring out why will have to wait until later tonight...

> (I'll also test on input bigger than available memory, so we can
> compare to other approaches.)