[perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful

[Leopold Toetsch]

# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #39117]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39117 >

See also http://use.perl.org/articles/06/05/03/1325204.shtml

19:24 <@leo> Andy: btw - if you got some extra tuits: Using
"v?snprintf/strlcpy/strlcat when useful" would be also very welcome for
Parrot
19:25 <@leo> strlcpy/strlcat would need a test too, snprintf should
already be in config tests
19:25 <@leo> and we'd need an implementation, if libc doesn't provide
the funcs

leo

[Steve Peters]

I'm taking a look at it. I should have something working this evening
for the configs. Adding the HAS_BLAH's will take some additional time.

Steve Peters
st...@fisharerojo.org

[Christoph Otto via RT]

On Wed May 10 11:01:34 2006, stmpeters wrote:
>
> I'm taking a look at it. I should have something working this evening
> for the configs. Adding the HAS_BLAH's will take some additional time.
>
> Steve Peters
> st...@fisharerojo.org

"when useful" is vague does not indicate why the extra configuration
machinery is justified by whatever benefit we'd get from using these
functions. If someone would like to make the requirements a little
tighter or make the case for implementing this request (or even
implement it), they'd be encouraged. Otherwise this ticket isn't very
useful.
It would be good to either go somewhere with this or reject this request.

[Andy Dougherty]

These functions are typically used in place of the plain sprintf and
strcat family as a way to be explicitly careful about buffer overflows.
Plain sprintf and strcat are both widely used in the parrot source.
Replacing them when it would ease future maintenance and help ensure
parrot is not susceptible to buffer overflows is a quite sensible path
forward.

As you correctly observe, no one has actually done anything about it yet.
That doesn't mean it's not worth doing, however.

I'd say it should simply stay as an open ticket.

--
Andy Dougherty doug...@lafayette.edu

[Jerry Gay]

+1
~jerry

[Allison Randal via RT]

Agreed that this particular ticket is not useful. Resolve it and replace
it with a [CAGE] ticket with explicit instructions on converting all
existing 'sprintf', 'strcat', etc calls with calls to 'snprintf',
'strlcat', etc. (Also include a list of all calls that should be converted.)

This can wait a couple of weeks until we dive into the String
implementation milestone.

Allison

[NotFound]

On Mon, Sep 8, 2008 at 9:31 AM, Allison Randal via RT
<parrotbug...@parrotcode.org> wrote:
> Agreed that this particular ticket is not useful. Resolve it and replace
> it with a [CAGE] ticket with explicit instructions on converting all
> existing 'sprintf', 'strcat', etc calls with calls to 'snprintf',
> 'strlcat', etc. (Also include a list of all calls that should be converted.)

I disagree on the "all" part. strlcat and strlcpy are not always the
best repalcement. When the C string length is known memcpy is a
simpler and faster solution.

For example in config/gen/platform/generic/env.c we have:

int name_len = strlen(name);
int val_len = strlen(value);

char *envs = malloc(name_len + 1 + val_len + 1);
if (envs == NULL)
return;

/* Save a bit of time, by using the fact we already have the
lengths, avoiding strcat */
strcpy(envs, name);
strcpy(envs + name_len, "=");
strcpy(envs + name_len + 1, value);

The memcpy way can be:

memcpy(envs, name, name_len);
envs[name_len] = '=';
memcpy(envs + name_len + 1, value, val_len + 1);

This code can be encapsulated on a function or a macro, and add inside
it checks for non-nullness and lengths in debug builds.

Regarding snprintf, according linux man page is in the C99, BSD and
XOPEN standards, not on older ansi C, and I think we don't have that
as a requirement for the C compiler usable to build parrot. And a
replacement for this is not so easy to write and test as the others.

--
Salu2