A custom gets function

Hello there,
I am trying to implement a custom gets function which would allow me to read a string so as to avaoid the pitfalls associated with the C version of 'gets'.

Well...I have been able to get some breakthrough into it. What my function does it that it keeps on extending the buffer (to hold the string) size by 16 if the user enters a string longer than 16 until it encounters the '\n' character. Im doing a char by char read using getchar and i check for the '\n' character and for the number of chars entered as of yet.

So if the user string is more than 4(size of the original buffer) but less than 16, it works fine though it only displays the first 4 chars..but if the user string is >16 then issues do arise.

Im wondering why...the seg fault occurs at the line preceded by an arrow-head in the program below

Just so you know, fgets is a safe alternative to gets.
The problem with your function is that you're taking a pointer to a buffer on the stack. The size of such buffers cannot be changed.
Realloc can only reallocate buffers allocated on the heap with malloc or calloc.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

hmmm..
yea it sure is...but then one has to know the size before hand...

but Im trying to experiment with the idea of 'dynamic strings in C' ....I could instead use a bufffer big enough or I could dynamically create one such big buffer then free it...

Perhaps what I wanna know is why the second time I use realloc it gives me an error...I have read from here that realloc can only work on pointers to memory which have been previously allocated using malloc/calloc/realloc...

The pointer you give to realloc must have come from malloc (or calloc, or realloc), since realloc must free the original memory. You must have initialized your string before calling realloc.

well...I did use realloc to increase the size of the mem chunk...do you mean that I should have created a new pointer variable and then have itpointed to at the newly allocated memory?..

Perhaps what I wanna know is why the second time I use realloc it gives me an error...I have read from here that realloc can only work on pointers to memory which have been previously allocated using malloc/calloc/realloc...
so..it should be fine as I had used realloc before and then used it again in the second part of the for loop...

Undefined behavior.
What you need to do is
a) take a pointer-to-pointer to hold the buffer
b) return a buffer

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

What you need to do is
a) take a pointer-to-pointer to hold the buffer
b) return a buffer

You mean the first time I used the realloc function it allocated for me a part of the memory from the stack and not the heap (as function calls are locally allowed to use resources from the stack right?)

So the pointer that must be passed to this function should instead be a pointer to a pointer (or a handle as they say) and I should make that handle point to the location of this buffer (thus it would be holding another address).

But what about the memory allocation part of the function? would such a memory be rendered useless once we exit the function?

but Im trying to experiment with the idea of 'dynamic strings in C' ....I could instead use a bufffer big enough or I could dynamically create one such big buffer then free it...

So you're basically trying to create a C version of the C++ string class?
In that case, maybe you could create a struct string that contains the char* pointer and the size of the buffer, and maybe the length of the string (so you don't have to keep calling strlen() on the string)...

The function "magicalFindSize" will dig out the "admin" block for this allocation, and find out what size the block is. It's not really important.

What is important is the bit in red: The freeing of the original pointer. If that pointer wasn't originally from a malloc/realloc call, then things are going to go horribly wrong at some point sooner or later [quite possibly LATER].

A real realloc will have some more logic in it, where it looks to see if there is more space right behind the current allocation that we can use directly, rather than doing a complete new allocation, and such things - but that doesn't change the matter that sooner or later the original allocation will most likely be freed.

--
Mats

Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.

well..this does seem to be a simple and good implementation of the re-alloc. What I would wanna know is that elysia said that all memory allocated within a function call is allocated on the stack. And then what happens to the content of that memory location once we exit the function?

Well...does that mean that I would not be able to use str to point to some memory allocated within this function and then extend the size of the block again using realloc?

What I would wanna know is that elysia said that all memory allocated within a function call is allocated on the stack. And then what happens to the content of that memory location once we exit the function?

That data disappears with the function, unless you allocate it on the heap. Data on the heap must be explicitly freed, so it will stay after the function.

First and foremost - you are not looking for a handle. No, sir. A handle is not a pointer to pointer.
In this case, you need char**. A pointer to char*. The reason you need this is because the data must be on the heap in order to resize it using realloc. And data on the heap needs a pointer. So therefore, main must have a pointer to the data and your mygets must take a pointer to that pointer.
Easy enough, yes?
Or you can just let the function itself allocate the memory and return a buffer.

And secondly: no, C is not more efficient than C++ at low level stuff. That's a myth. Yes, C++ can be slower, but if you use it properly, like C, it is just as fast as C. I always dislike using C for the reason it's so limited and C++ can do everything C can (and equally good, as well) plus more.
I do recommend you use C++ instead. If you can't use C++ classes and such, you can always fall back on using typical C code within C++. No, it won't compile straight away, but 99% of it will.
Then you'll have the advantages of C++ and the speed of C at your disposal. Not a bad deal, eh?

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

First and foremost - you are not looking for a handle. No, sir. A handle is not a pointer to pointer.

thnks for the info...seems that the term is a bit too vague and does not neccesarily mean a pointer to a pointer....go google!!

In this case, you need char**. A pointer to char*. The reason you need this is because the data must be on the heap in order to resize it using realloc. And data on the heap needs a pointer. So therefore, main must have a pointer to the data and your mygets must take a pointer to that pointer.

So you mean I should instead pass to this function a pointer to b2(the string b2 that is). And my mygets function should then allocate more space as and when needed?.. you also said

Or you can just let the function itself allocate the memory and return a buffer.

..well...as before if I do that allocation within the function won't it get allocated on the stack again?...is there a way to specify that I'd like to have it allocated on the heap?...

What exactly do you mean by a buffer..I hope its just a memory block pointed to by some pointer right?...