Bug 145596 – [EFL][GTK] Fix build error since r185137

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Hyungwook Lee]

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.

[Gyuyoung Kim]

Created attachment 254154 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 254154 [details]
Patch

Rejecting attachment 254154 [details] from commit-queue.

[e-mail] 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.

[Gyuyoung Kim]

I uploaded this patch instead of Hyungwook.

[Gyuyoung Kim]

Comment on attachment 254154 [details]
Patch

Clearing flags on attachment: 254154

Committed r185148: <http://trac.webkit.org/changeset/185148>

[Gyuyoung Kim]

All reviewed patches have been landed.  Closing bug.

[Michael Catanzaro]

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.

[Michael Catanzaro]

Let's use bug #145608

[Gyuyoung Kim]

(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.