src/dynext.c uses STRING's ->strstart

[coke]

There are several places in src/dynext.c where, instead of using Parrot_str_to_cstring, it unsafely uses strstart.

[NotFound]

Fixed several in r38494 The remaining are Windows specific and I don't have a Windows box to test.

[doughera]

Thanks.

There are still a number of places elsewhere that use Parrot_string_cstring, which is simply implemented as return str->strstart . Some of those are wrapped in a strdup() call, and could probably be replaced by calls to more appropriate functions in string/api.c.

Also, this call in src/pmc/packfile.pmc (lines 175-6):

const opcode_t  *ptr =
                (const opcode_t*)Parrot_string_cstring(interp, str);

ends up not only peeking inside the str structure, but also relying on the hidden assumption that the strstart member of the STRING structure happens to be suitably aligned for use as an opcode_t pointer. Slight changes to the STRING structure, such as might occur if UnionVal is removed from it, will invalidate that assumption.

[jkeenan]

Replying to nwellnhof:

nwellnhof,

Can we get an update on the status of this ticket?

Thank you very much.

kid51

[nwellnhof]

I fixed the remaining places in the Windows code in commit 67bc4de8872ccb. strstart is still accessed directly in function clone_string_into. This is related to threading and I don't want to touch that code. I think this bug can be closed regardless.