Helper's xs_buffer does not work when called inline with another function call

[wchristian]

First mentioned in #14, on my Perl (Strawberry 5.18.4) this does not work, i.e. the created buffers remain zeroed out:

    glGetShaderInfoLog( $id, $bufsize, xs_buffer(my $len, 8), xs_buffer(my $buffer, $bufsize));

Meanwhile standalone xs_buffer calls do work:

    xs_buffer(my $len, 8);
    xs_buffer(my $buffer, $bufsize);
    glGetShaderInfoLog( $id, $bufsize, $len, $buffer);

@devel-chm: You mentioned it still works for you. What is your Perl version?

[devel-chm]

perl version 5.22.2

…

On Fri, Jan 13, 2017 at 12:58 PM, Christian Walde (Mithaldu) < ***@***.***> wrote: First mentioned in #14 <#14>, on my Perl (Strawberry 5.18.4) this does not work, i.e. the created buffers remain zeroed out: glGetShaderInfoLog( $id, $bufsize, xs_buffer(my $len, 8), xs_buffer(my $buffer, $bufsize)); Meanwhile standalone xs_buffer calls do work: xs_buffer(my $len, 8); xs_buffer(my $buffer, $bufsize); glGetShaderInfoLog( $id, $bufsize, $len, $buffer); @devel-chm <https://github.com/devel-chm>: You mentioned it still works for you. What is your Perl version? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwNecX9Nc1z0Akjyub_aMS5CRpRWFjZks5rR7s2gaJpZM4LjI1W> .

[wchristian]

Ok, nailed it down a bit further, and short version is: It's fucked.

https://gist.github.com/wchristian/6df5740d442002a311cbeb8282cfca4d

The default version does not work on 5.18.4, adding :lvalue kinda makes it work, but it still breaks under certain debuggers (though not all).

Unless you get real creative, there is no way the xs_buffer api as it is currently can be advocated for.

[wchristian]

Oh yeah, i skimmed through perl5200delta, but didn't find any definite smoking gun. I am currently suspecting the COW optimization for making it work in the first place.

[wchristian]

Zefram commented in #p5p:

(Zefram) your four() function doesn't sv_force_normal() or otherwise respect SvREADONLY
(Zefram) Inline::C can't tell whether the function body is going to try to mutate the string. XS has the same problem
(Mithaldu) is there a quick and common way to declare those inputs as "gonna mutate those"?
(Zefram) no, it's a rare need
(Zefram) you'll have to take an SV* and do it yourself, or create a custom typemap to do it if you need it a lot
(Zefram) the failure to respect SvREADONLY is a reportable bug in any case
(Mithaldu) how does one normally respect SvREADONLY?
(Zefram) if(SvREADONLY(argsv)) croak("woah nelly!");
(Zefram) sv_force_normal() is a better way, because COWed strings are SvREADONLY but may actually be mutatable
(Zefram) sv_force_normal() will de-COW and remove the SvREADONLY status if you're allowed to mutate the scalar

[devel-chm]

The current OpenGL::Modern bindings make use of perl strings to be the interface for data buffers and pointers to the same to/from perl. This was a simple way to get the raw OpenGL bindings working but at the cost of fragile and awkward perl constructs needed by the user.... But wow! Look at the promise of modern OpenGL bindings for perl in Max's app-shadertoy.

Regarding remaining development for OpenGL::Modern, that work is taking place here and Max/Corion is using OpenGL::Modern for his app-shadertoy work. If there are any problems with app-shadertoy and OpenGL::Modern, we need to open the issues here to resolve them.

BTW, thanks for tracking this down.

[wchristian]

I have absolutely no idea what that response means. I don't know if you expect me to do something now, or whether you even understood me right in what this means for what you need to be doing.