Ok well im making a program in c++ and gui and i hit a speed bump how do i add these into one variable.
char* server=strTemp;
char* URL = "steam://-applaunch 240 -game cstrike +connect ";
char* server=strTemp;
char* URL = "steam://-applaunch 240 -game cstrike +connect ";
char BothVariables[255];
sprintf(BothVariables, "%s%s", server, URL);
BothVariables now contains both server and URL in it.
thanks lots frozen your a real pal
(http://www.jinxbot.net/pub/finaladescentprogrammer.gif)
Dude, you programmed Descent? That was a really cool game. But I always thought it was written in C or C++.... obviously it was something else. What was it written in?
Quote from: FrOzeN on January 03, 2006, 03:50 AM
char* server=strTemp;
char* URL = "steam://-applaunch 240 -game cstrike +connect ";
char BothVariables[255];
sprintf(BothVariables, "%s%s", server, URL);
BothVariables now contains both server and URL in it.
You're not checking whether there's actually enough room in the buffer. If strTemp is too long, the program will crash or execute undesirable code when it attempts to return from this function.
I realise that, though I assumed the CS: Source Server's DNS name wouldn't exceed 209 characters. If it does I'm going to further assume it lags and is not worth playing on anyway.
Wow..
http://www.mkssoftware.com/docs/man3/strcat.3.asp
Why not use the super duper function in string.h!?
Warning: Heed the warnings on the page, you MUST ensure that s1 is large enough to hold itself and whatever is appened to it.
I think that "descent" joke has happened before. I'm not sure if it was about his description, but I know I've seen that happen here once.
Quote from: warz on January 03, 2006, 10:03 PM
I think that "descent" joke has happened before. I'm not sure if it was about his description, but I know I've seen that happen here once.
Yes it has happened before and Nope, it was someone else. :P
Oh sorry I mispelled my lil personnal comment I ment decent I just forgot how to spell it please forgive me!
Frozen told me its a game of somesort 3d game right ? well i didnt know about it at all never even heard of it
and the space for the buffer is easiely solved by this:
instead of putting a number just put this
"MAX_PATH"
heck ive used it alot before so the space prob didnt hurt cuz i fixed that when i read the code.
How is using a buffer of size 260 safer than a buffer of size 255? They're both vulnerable to an overflow if you pass too much data in. The correct thing to do would be to use a length-checking variant, such as strncat, strncpy, or snprintf, of the string function you want. strncpy behaves strangely though, so you might be better off copying the BSD strlcpy instead.
@Myndfyre: He spelled decent wrong. =p
Quote from: Kp on January 03, 2006, 11:41 PM
How is using a buffer of size 260 safer than a buffer of size 255? They're both vulnerable to an overflow if you pass too much data in. The correct thing to do would be to use a length-checking variant, such as strncat, strncpy, or snprintf, of the string function you want. strncpy behaves strangely though, so you might be better off copying the BSD strlcpy instead.
For personal knowledge, can you explain how it behaves strangley and is unique compared to other length checking string functions?
Quote from: Mephisto on January 04, 2006, 06:18 PM
Quote from: Kp on January 03, 2006, 11:41 PM
How is using a buffer of size 260 safer than a buffer of size 255? They're both vulnerable to an overflow if you pass too much data in. The correct thing to do would be to use a length-checking variant, such as strncat, strncpy, or snprintf, of the string function you want. strncpy behaves strangely though, so you might be better off copying the BSD strlcpy instead.
For personal knowledge, can you explain how it behaves strangley and is unique compared to other length checking string functions?
I could, but it's easier just to quote the man page. :)
The strncpy() function is similar, except that not more
than n bytes of src are copied. Thus, if there is no null
byte among the first n bytes of src, the result will not
be null-terminated.
In the case where the length of src is less than that of
n, the remainder of dest will be padded with nulls.
Other length-limited string functions ensure the string is null terminated (even if they must cut off some characters to do so), and don't do anything to the space beyond where the null is dropped.
Hmm, I think it would be better practice to just account for the null terminator when doing the allocation or whatever for s1. The others seem like workarounds that withought checks can easily confuse a person.
Quote from: Kp on January 04, 2006, 06:53 PM
Quote from: Mephisto on January 04, 2006, 06:18 PM
Quote from: Kp on January 03, 2006, 11:41 PM
How is using a buffer of size 260 safer than a buffer of size 255? They're both vulnerable to an overflow if you pass too much data in. The correct thing to do would be to use a length-checking variant, such as strncat, strncpy, or snprintf, of the string function you want. strncpy behaves strangely though, so you might be better off copying the BSD strlcpy instead.
For personal knowledge, can you explain how it behaves strangley and is unique compared to other length checking string functions?
I could, but it's easier just to quote the man page. :)
The strncpy() function is similar, except that not more
than n bytes of src are copied. Thus, if there is no null
byte among the first n bytes of src, the result will not
be null-terminated.
In the case where the length of src is less than that of
n, the remainder of dest will be padded with nulls.
Other length-limited string functions ensure the string is null terminated (even if they must cut off some characters to do so), and don't do anything to the space beyond where the null is dropped.
Note: This isn't true for windows.
Take _snprintf for example http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__snprintf.2c_._snwprintf.asp
Quote
The _snprintf function formats and stores count or fewer characters and values (including a terminating null character that is always appended unless count is zero or the formatted string length is greater than or equal to count characters) in buffer.
Security Note Ensure that format is not a user-defined string. This function does not guarantee NULL termination, so ensure it is followed by sz[ ARRAYSIZE(sz) - 1] = 0. For more information, see Avoiding Buffer Overruns.
Wow, the security note is neat. It wasn't around the last time I looked at the MSDN page for _snprintf.
That's terrible! The GNU libc implementation of snprintf always null terminates non-empty buffers, even if the output is truncated. It's likely that much code written for Unix relies on this behavior, as do many Windows programmers. I'd never heard about this incompatibility in the Microsoft implementation, nor do I see reference to it in the PSDK I use as a reference.