r185137 used strlcpy() even though it is not standardized by POSIX. It caused build break on GTK and EFL port's debug build. To fix it, let's use strncpy() in Text.cpp.
Created attachment 254154 [details] Patch
Comment on attachment 254154 [details] Patch Rejecting attachment 254154 [details] from commit-queue. hyungwook.lee@navercorp.com does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/contributors.json. - If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags. - If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/contributors.json by adding yourself to the file (no review needed). The commit-queue restarts itself every 2 hours. After restart the commit-queue will correctly respect your committer rights.
I uploaded this patch instead of Hyungwook.
Comment on attachment 254154 [details] Patch Clearing flags on attachment: 254154 Committed r185148: <http://trac.webkit.org/changeset/185148>
All reviewed patches have been landed. Closing bug.
I think this is a buffer overflow; it should be strncpy(buffer, result.toString().utf8().data(), length - 1) as it was prior to r185137. From strcpy(3): strlcpy() Some systems (the BSDs, Solaris, and others) provide the following function: size_t strlcpy(char *dest, const char *src, size_t size); This function is similar to strncpy(), but it copies at most size-1 bytes to dest, always adds a terminating null byte, and does not pad the target with (further) null bytes. This function fixes some of the problems of strcpy() and strncpy(), but the caller must still handle the possibility of data loss if size is too small. The return value of the function is the length of src, which allows truncation to be easily detected: if the return value is greater than or equal to size, trunca‐ tion occurred. If loss of data matters, the caller must either check the arguments before the call, or test the function return value. strlcpy() is not present in glibc and is not standardized by POSIX, but is available on Linux via the libbsd library.
Let's use bug #145608
(In reply to comment #6) > I think this is a buffer overflow; it should be strncpy(buffer, > result.toString().utf8().data(), length - 1) as it was prior to r185137. > > From strcpy(3): > > strlcpy() > Some systems (the BSDs, Solaris, and others) provide the > following > function: > > size_t strlcpy(char *dest, const char *src, size_t size); > > This function is similar to strncpy(), but it copies at most > size-1 > bytes to dest, always adds a terminating null byte, and does not > pad > the target with (further) null bytes. This function fixes some of > the > problems of strcpy() and strncpy(), but the caller must still > handle > the possibility of data loss if size is too small. The return value > of > the function is the length of src, which allows truncation to be > easily > detected: if the return value is greater than or equal to size, > trunca‐ > tion occurred. If loss of data matters, the caller must either > check > the arguments before the call, or test the function return > value. > strlcpy() is not present in glibc and is not standardized by POSIX, > but > is available on Linux via the libbsd library. Oh, thank you for your fix.