RE: [Dev-C++] Errorhandling

[Ioannis V. <no...@ya...>]

My last note on the matter is i want to reinforce that, yes you are
*right*, strcat() places the new string at the first occurence of '\0'
of its first argument (=3Dit behaves as if it searches character by
character from the beginning for '\0') because i used the term
"probably" in my previous email regarding the matter. Also as i said
"string\0" is looking for trouble in our code.=20

 That doesn't mean that strcat() searches character by character for 0
but it *behaves* as if it does that. The same way that pointers *behave*
as if they store a memory address, string literals *behave* as null
terminated const char arrays, e.t.c.. This is important for all to keep
in mind. :) This behavior is required by the standard, but it doesn't
mean things happen this way. But it is safe to think of them as working
this way.


Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
* Alternative URL: http://run.to/noicys


> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf=20
> Of Jason Hardman
> Sent: Saturday, October 20, 2001 1:38 AM
> To: Dev-C++
> Subject: Re: [Dev-C++] Errorhandling
>=20
>=20
> As defined in C/C++ Programmers Reference:
>=20
> strcat
> ------
> #include <string.h>
> char *strcat(char *str1, const char *str2);
>=20
> The strcat() function concatenates a copy of str2 to str1 and
> terminates str1 with a null. The null terminator originally=20
> ending str1 is overwritten by the first character of str2.=20
> The string str2 is untouched by the operation. If the arrays=20
> overlap, the behavior of strcat() is undefined.
>=20
> In C99, str1 and str2 are qualified by restrict.
>=20
> The strcat() function returns str1.
>=20
> Remember, no bounds checking takes place, so it is the
> programmer's responsibility to ensure that str1 is large=20
> enough to hold both its original contents and also those of str2.
> ------------------------
>=20
> The function strcat() is defined in the C, and therefore the
> C++, standard. It must follow a consistent behaviour. It is
> feasible that it could have been written in assembler, but it
> will still have the same basic behaviour. I know it would be=20
> slow in large strings, but there isn't really any faster and=20
> reliable way to search for the null. Skipping characters=20
> opens up the possibility of missing the proper null, and=20
> accessing characters after it which will be undefined. In=20
> strcat you might not overrun the array containing the string=20
> that way, but in a similar function such as strlen you=20
> probably would, and that would be an access violation.
>=20
> Without more information about the string being passed then
> you are pretty much limited to going throught the string from=20
> start to finish. Generally if a programmer was dealing with=20
> very large string then it would be wise for him/her to find a=20
> better way of dealing with them (such as tracking the=20
> length), or to just accept the performance hit.
>=20
> Whether the include is an on/off switch or a header won't
> change the way the function works, just how the compiler adds=20
> it to the exe.
>=20
> Regards, Jason.
>=20
> PS: Yet again I've probably gone OTT (Over The Top). LOL! It
> looks like I've written an essay on a standard function.
>=20
> PPS: Why is it us to always seem to be arguing over silly
> little things like this?
>=20
>=20
> _______________________________________________
> Dev-cpp-users mailing list Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>=20