![]() |
|
![]() |
|
|
Thread Tools | Display Modes |
|
|
#1 |
|
Newbie
Join Date: Mar 2006
Posts: 11
Rep Power: 0
![]() |
Safe string copy?
Hi,
strcpy is a one way to copy strings but what if I need to make sure that the dest string (buffer) is large enough to hold the source string, is there a function for that? I could just check the length of the source string can compare that to the predefined size of destination buffer but I assume there is already function for this. Thank you. |
|
|
|
|
|
#2 |
|
Hobbyist Programmer
|
IIRC, there's no function to do that, if you're dealing with a buffer obtained from malloc you can just realloc it to the appropriate size, though. If you're not afraid of just truncating the value you can do:
strncpy(destination,source,sizeof(source)-1); source[sizeof(source)-1] = 0; That'll make sure that the string is copied safely and that the string is null terminated (many str functions like strncat and strncpy don't ensure null termination which can still lead to arbitrary code execution or nothing based on adjacent buffers.) |
|
|
|
|
|
#3 | |
|
Expert Programmer
Join Date: Jun 2005
Posts: 893
Rep Power: 4
![]() |
Quote:
strncpy(destination,source,sizeof(destination)-1); destination[sizeof(destination)-1] = 0; Also, this will only work if destination is an array, not a pointer. If it is a pointer, sizeof will return 4 (for a 32 bit system). |
|
|
|
|
|
|
#4 |
|
Resident Grouch
![]() ![]() ![]() ![]() ![]() ![]() Join Date: Jun 2005
Posts: 6,453
Rep Power: 10
![]() |
You can use 'strdup' if you accept responsibility for freeing the memory when you're through.
__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers |
|
|
|
|
|
#5 |
|
Newbie
Join Date: Mar 2006
Posts: 11
Rep Power: 0
![]() |
Thanks for the replies but I know that option but you see what I'm doing is receiving IRC messages from clients but if the client sends very long messages I don't want to just allocate more space. I could just reject the over sized (flood) messages.
But anyway, thanks again, I can continue from my own from here. |
|
|
|
|
|
#6 |
|
Professional Programmer
![]() Join Date: Sep 2005
Posts: 419
Rep Power: 4
![]() |
>but if the client sends very long messages
It's generally a bad idea to have built-in limitations. >I could just reject the over sized (flood) messages. You could terminate the program too, and get about the same reaction from your user base.
__________________
Even if the voices aren't real, they have some pretty good ideas. |
|
|
|
|
|
#7 | |
|
Newbie
Join Date: Mar 2006
Posts: 11
Rep Power: 0
![]() |
Quote:
![]() |
|
|
|
|
|
|
#8 |
|
Professional Programmer
![]() Join Date: Sep 2005
Posts: 419
Rep Power: 4
![]() |
>But then if one client sends an oversized message all the client apps would be
>terminated since none could handle it. Methinks you missed the point entirely. ![]()
__________________
Even if the voices aren't real, they have some pretty good ideas. |
|
|
|
|
|
#9 | |
|
Newbie
Join Date: Mar 2006
Posts: 11
Rep Power: 0
![]() |
Quote:
Any hints? ![]() |
|
|
|
|
|
|
#10 | |
|
Professional Programmer
|
I think he means rejecting data would be the same as removing the client from the server, so why keep the client in the server?
__________________
▄▄▄▄ Quote:
Due to incorrect calculations during the middle ages, our calendar actually begins a few years after Jesus' birth. Thus the real 6/6/6 happened a few years back. The world already ended and you missed it. Download Code::Blocks now! ▄▄▄▄ |
|
|
|
|
![]() |
| Bookmarks |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | |
|
|