In the function file_connect_unix(), Pike_sp[-args].u.string->len is checked against PATH_MAX, and then its strcpy'd into name.sun_path. The size of a sockaddr_un.sun_path isn't standard, and can be much smaller than PATH_MAX.
How should this be fixed, changing the PATH_MAX test to a sizeof(name.sun_path)? Or removing that check altogether, using strncpy and then checking for truncation and giving a "path too long" error instead of the current "Illegal argument. Expected string(8bit)"?
Is it worth adding configure tests for strlcpy/cat and using those instead of strncpy/cat?
Adam
In the function file_connect_unix(), Pike_sp[-args].u.string->len is checked against PATH_MAX, and then its strcpy'd into name.sun_path. The size of a sockaddr_un.sun_path isn't standard, and can be much smaller than PATH_MAX.
How should this be fixed, changing the PATH_MAX test to a sizeof(name.sun_path)? Or removing that check altogether, using strncpy and then checking for truncation and giving a "path too long" error instead of the current "Illegal argument. Expected string(8bit)"?
I think my vote is on a configure test for PATH_MAX.
Is it worth adding configure tests for strlcpy/cat and using those instead of strncpy/cat?
strlcpy is faster than strncpy, so we would like to use it when it exsits. Perhaps use a definition in port.h?
On Wed, 19 Apr 2006 15:45:03 +0000 (UTC) "Henrik Grubbstr_m (Lysator) @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se wrote:
strlcpy is faster than strncpy, so we would like to use it when it exsits. Perhaps use a definition in port.h?
"faster"? Do you mean "easier to use"?
Both. If you have a big buffer, and strncpy only a few chars into, it wastes time filling the entire buffer with nulls. So strlcpy should be faster since it only copies the few chars and a single null.
Adam
On the other hand, if you have a small buffer, and strncpy only copies a few chars of the source string, then strlcpy is _slower_, as it has to waste time counting all the chars in the source string anyway for the return value.
With faster I mean slightly slower than strcpy but faster than strncpy, according the this _completely_unbiased_ presentation http://www.courtesan.com/todd/papers/strlcpy.html
On Wed, 19 Apr 2006 14:50:07 +0000 (UTC) "Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se wrote:
In the function file_connect_unix(), Pike_sp[-args].u.string->len is checked against PATH_MAX, and then its strcpy'd into name.sun_path. The size of a sockaddr_un.sun_path isn't standard, and can be much smaller than PATH_MAX.
How should this be fixed, changing the PATH_MAX test to a sizeof(name.sun_path)? Or removing that check altogether, using strncpy and then checking for truncation and giving a "path too long" error instead of the current "Illegal argument. Expected string(8bit)"?
I think my vote is on a configure test for PATH_MAX.
Configure test for what about PATH_MAX? The problem is that PATH_MAX is defined as 1024 here, and sockaddr_un.sun is char[104] (although it could be any length). So testing against PATH_MAX doesn't do anything, it should be testing against sizeof(name.sun_path) instead.
Is it worth adding configure tests for strlcpy/cat and using those instead of strncpy/cat?
strlcpy is faster than strncpy, so we would like to use it when it exsits. Perhaps use a definition in port.h?
I've attached a patch to add STRLCPY and STRLCAT to port.c/h.
Adam
pike-devel@lists.lysator.liu.se
-
Adam Montague -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum