Recent searches

No recent searches

Search options

Not available on mstdn.science.
mstdn.science is one of the many independent Mastodon servers you can use to participate in the fediverse.
http://mstdn.science is a place for scientists and science enthusiasts to discuss research and topics surrounding our work.

Administered by:

Server stats:

509
active users

mstdn.science: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.3

Christos Argyropoulos MD, PhD

This is something you are probably NOT supposed to be doing with but consider my innocent looking C code found in an Inline::C region (which will be discussed in my talk).
If my understanding of the API is correct, then this macro allocates a buffer of known size in bytes and puts the buffer under the garbage collector. One only needs an entry point from Perl to and one just enhanced their code with a garbage collector
for safe memory management.
@Perl

// macro for the creation of a new SV buffer of a given size w/o resizing #define NEW_SV_BUFFER(sv, buf , buffer_size) \ SV *sv = newSV(0); \ char *buf; \ Newxz(buf,buffer_size,char); \ sv_usepvn_flags(sv, buf, buffer_size,SV_HAS_TRAILING_NUL|SV_SMAGIC)
··Web
1boost·2favorites
Christos Argyropoulos MD, PhD

@Perl We use C to make things run faster in but why not think of turning the tables? Having Perl make C somewhat safer to use, leave IO and string pains behind (jump from back to Perl)

1. screenshot has alt-text
2. yes, I am aware that the arguments of the macro should probably be inside parentheses

Christos Argyropoulos MD, PhD

@Perl There is another more sinister pattern that one can apply to do safe memory management in *assembly* that I will blog about at some point. None of these patterns prevent things like out of bounds access - they are merely there to prevent memory management FAFO

Oriel Jutty :hhHHHAAAH:

@ChristosArgyrop @Perl I don't see any garbage collecting. If you don't register sv for cleanup later, it'll probably just leak.
(Also, why not just SV *sv = newSVpvn(buf, buffer_size);?)

Christos Argyropoulos MD, PhD

@barubary @Perl

Regarding the allocation sequence (comments all based on my understanding of perlguts)
1) newSVpvn(const char*, STRLEN) -> allocates STRLEN+1 (for C's 'terminal \0') while
2) Newxz gives one the size they want (
3) sv_usepvn_flags can then be applied and the buffer now belongs to perl (see screenshot) through the SV that was just created to hold it

Christos Argyropoulos MD, PhD

@barubary @Perl
4) the C code using this macro is supposed to return the sv back to Perl for registration. Inline::C *appears* to be handling mortalization for you. Again, if this is not the case one should probably add a call sv_2mortal to the macro

*
Oriel Jutty :hhHHHAAAH:

@ChristosArgyrop @Perl
SV_HAS_TRAILING_NUL promises that buf[buffer_size] == '\0' (i.e. buf has actually buffer_size+1 elements). In your code, that's not the case, so that's not a valid PV string buffer. See perldoc.perl.org/perlapi#sv_us:

And if flags & SV_HAS_TRAILING_NUL is true, then ptr[len] must be NUL, and the realloc will be skipped (i.e., the buffer is actually at least 1 byte longer than len, and already meets the requirements for storing in SvPVX).

(Also, SV_MAGIC seems weird for a newly allocated SV, which is guaranteed to not have magic.)

Christos Argyropoulos MD, PhD

@barubary @Perl
Hm, I am not using these SV as strings, I am allocating a space of sufficient size to hold a C struct, and lie to perl that it has a terminal zero to avoid copying the buffer to a new area in memory and have its size extended by 1 to hold the terminal '\0'

It is easy to see that memory does not leak by creating an example in which the SV is mortalized. Code in alt text. Upon execution there is a warning about the freeing of the area allocated in C when the program terminates.

use strict; use warnings; use v5.38; use Inline ( C => 'DATA' ); my $buffer_size = 1024; my $mortal_sv = mortal_FAFO_alloc($buffer_size); say "Mortal SV address : ", \$mortal_sv; __DATA__ __C__ // macro for the creation of a new SV buffer of a given size w/o resizing #define NEW_SV_BUFFER(sv, buf , buffer_size) \ SV *sv = newSV(0); \ char *buf; \ Newxz(buf,buffer_size,char); \ sv_usepvn_flags(sv, buf, buffer_size,SV_HAS_TRAILING_NUL|SV_SMAGIC) SV* mortal_FAFO_alloc(size_t buffer_size) { SV *sv = newSV(0); char *buf; Newxz(buf,buffer_size,char); sv_usepvn_flags(sv, buf, buffer_size,SV_HAS_TRAILING_NUL|SV_SMAGIC); sv_2mortal(sv); printf("Mortal SV address : %p in C\n",sv); return sv; }
Oriel Jutty :hhHHHAAAH:

@ChristosArgyrop @Perl That's not how the API is intended to work. And on a debugging Perl, that will just crash due to an assertion failure: github.com/Perl/perl5/blob/ee4

*
Christos Argyropoulos MD, PhD

@barubary @Perl
Agreed that the SV_MAGIC is weird, but look at the examples
perldoc.perl.org/perlguts#Work

Every single one of the sets the MAGIC flag when working in C with buffers.

There is probably some undocumented MAGIC that requires the MAGIC to be set.

TrendingLive feeds
About