<?xml version="1.0" encoding="UTF-8"?>
<metadata xmlns="http://linux.duke.edu/metadata/common" xmlns:rpm="http://linux.duke.edu/metadata/rpm" packages="5">
<package type="rpm">
  <name>perl-MIME-Lite</name>
  <arch>noarch</arch>
  <version epoch="0" ver="3.033" rel="lp160.38.1"/>
  <checksum type="sha512" pkgid="YES">806f694f3494387242e7b92f84f1680797780aec9893cdd0f66e1073b170871e89dce0ee0c54504d1520bbcf15ed67d76e0292699224a76f339cb9fb78e3abb2</checksum>
  <summary>Low-calorie MIME generator</summary>
  <description>In the never-ending quest for great taste with fewer calories, we proudly
present: _MIME::Lite_.

MIME::Lite is intended as a simple, standalone module for generating (not
parsing!) MIME messages... specifically, it allows you to output a simple,
decent single- or multi-part message with text or binary attachments. It
does not require that you have the Mail:: or MIME:: modules installed, but
will work with them if they are.

You can specify each message part as either the literal data itself (in a
scalar or array), or as a string which can be given to open() to get a
readable filehandle (e.g., "&lt;filename" or "somecommand|").

You don't need to worry about encoding your message data: this module will
do that for you. It handles the 5 standard MIME encodings.</description>
  <packager></packager>
  <url>https://metacpan.org/release/MIME-Lite</url>
  <time file="1763352585" build="1763352581"/>
  <size package="94919" installed="242681" archive="245568"/>
  <location href="noarch/perl-MIME-Lite-3.033-lp160.38.1.noarch.rpm"/>
  <format>
    <rpm:license>Artistic-1.0 OR GPL-1.0-or-later</rpm:license>
    <rpm:vendor>obs://build.opensuse.org/home:silicon_chip</rpm:vendor>
    <rpm:group>Unspecified</rpm:group>
    <rpm:buildhost>reproducible</rpm:buildhost>
    <rpm:sourcerpm>perl-MIME-Lite-3.033-lp160.38.1.src.rpm</rpm:sourcerpm>
    <rpm:header-range start="4504" end="12545"/>
    <rpm:provides>
      <rpm:entry name="perl(MIME::Lite)" flags="EQ" epoch="0" ver="3.033"/>
      <rpm:entry name="perl(MIME::Lite::IO_Handle)"/>
      <rpm:entry name="perl(MIME::Lite::IO_Scalar)"/>
      <rpm:entry name="perl(MIME::Lite::IO_ScalarArray)"/>
      <rpm:entry name="perl(MIME::Lite::SMTP)"/>
      <rpm:entry name="perl-MIME-Lite" flags="EQ" epoch="0" ver="3.033" rel="lp160.38.1"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="perl(:MODULE_COMPAT_5.42.0)"/>
      <rpm:entry name="perl(Email::Date::Format)" flags="GE" epoch="0" ver="1.000"/>
      <rpm:entry name="perl(MIME::Types)" flags="GE" epoch="0" ver="1.28"/>
      <rpm:entry name="perl(Mail::Address)" flags="GE" epoch="0" ver="1.62"/>
    </rpm:requires>
  </format>
</package>
<package type="rpm">
  <name>perl-MIME-Lite</name>
  <arch>src</arch>
  <version epoch="0" ver="3.033" rel="lp160.38.1"/>
  <checksum type="sha512" pkgid="YES">dd2bf4cda4ebb88c9f22b8c29ffd73d669983991a70556c7f09141dfe0e7b0cec7c6a94d32b24dd04e85f6db98d6f6e8d2039afe81b463e0aa07cac37c603e59</checksum>
  <summary>Low-calorie MIME generator</summary>
  <description>In the never-ending quest for great taste with fewer calories, we proudly
present: _MIME::Lite_.

MIME::Lite is intended as a simple, standalone module for generating (not
parsing!) MIME messages... specifically, it allows you to output a simple,
decent single- or multi-part message with text or binary attachments. It
does not require that you have the Mail:: or MIME:: modules installed, but
will work with them if they are.

You can specify each message part as either the literal data itself (in a
scalar or array), or as a string which can be given to open() to get a
readable filehandle (e.g., "&lt;filename" or "somecommand|").

You don't need to worry about encoding your message data: this module will
do that for you. It handles the 5 standard MIME encodings.</description>
  <packager></packager>
  <url>https://metacpan.org/release/MIME-Lite</url>
  <time file="1763352585" build="1763352581"/>
  <size package="103910" installed="89161" archive="89804"/>
  <location href="src/perl-MIME-Lite-3.033-lp160.38.1.src.rpm"/>
  <format>
    <rpm:license>Artistic-1.0 OR GPL-1.0-or-later</rpm:license>
    <rpm:vendor>obs://build.opensuse.org/home:silicon_chip</rpm:vendor>
    <rpm:group>Unspecified</rpm:group>
    <rpm:buildhost>reproducible</rpm:buildhost>
    <rpm:sourcerpm></rpm:sourcerpm>
    <rpm:header-range start="4504" end="17794"/>
    <rpm:provides>
      <rpm:entry name="perl-MIME-Lite" flags="EQ" epoch="0" ver="3.033" rel="lp160.38.1"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="perl"/>
      <rpm:entry name="perl(Email::Date::Format)" flags="GE" epoch="0" ver="1.000"/>
      <rpm:entry name="perl(MIME::Types)" flags="GE" epoch="0" ver="1.28"/>
      <rpm:entry name="perl(Mail::Address)" flags="GE" epoch="0" ver="1.62"/>
      <rpm:entry name="perl-macros"/>
    </rpm:requires>
  </format>
</package>
<package type="rpm">
  <name>perl-Sys-Mmap</name>
  <arch>aarch64</arch>
  <version epoch="0" ver="0.200.0" rel="lp160.4.2"/>
  <checksum type="sha512" pkgid="YES">9edf634986ec7c01a05b3f018785cd7eb984211800da7be8362b004380fabb8549301c1418dd7031344e1134fe70aded40a8fe60a450246c0a7a3daf94115cac</checksum>
  <summary>Uses mmap to map in a file as a Perl variable</summary>
  <description>The Sys::Mmap module uses the POSIX at https://en.wikipedia.org/wiki/Mmap
call to map in a file as a Perl variable. Memory access by mmap may be
shared between threads or forked processes, and may be a disc file that has
been mapped into memory. Sys::Mmap depends on your operating system
supporting UNIX or POSIX.1b mmap, of course.

*Note* that PerlIO now defines a ':mmap' tag and presents mmap'd files as
regular files, if that is your cup of joe.

Several processes may share one copy of the file or string, saving memory,
and concurrently making changes to portions of the file or string. When not
used with a file, it is an alternative to SysV shared memory. Unlike SysV
shared memory, there are no arbitrary size limits on the shared memory
area, and sparse memory usage is handled optimally on most modern UNIX
implementations.

Using the 'new()' method provides a 'tie()''d interface to 'mmap()' that
allows you to use the variable as a normal variable. If a filename is
provided, the file is opened and mapped in. If the file is smaller than the
length provided, the file is grown to that length. If no filename is
provided, anonymous shared inheritable memory is used. Assigning to the
variable will replace a section in the file corresponding to the length of
the variable, leaving the remainder of the file intact and unmodified.
Using 'substr()' allows you to access the file at an offset, and does not
place any requirements on the length argument to 'substr()' or the length
of the variable being inserted, provided it does not exceed the length of
the memory region. This protects you from the pathological cases involved
in using 'mmap()' directly, documented below.

When calling 'mmap()' or 'hardwire()' directly, you need to be careful how
you use the variable. Some programming constructs may create copies of a
string which, while unimportant for smallish strings, are far less welcome
if you're mapping in a file which is a few gigabytes big. If you use
'PROT_WRITE' and attempt to write to the file via the variable you need to
be even more careful. One of the few ways in which you can safely write to
the string in-place is by using 'substr()' as an lvalue and ensuring that
the part of the string that you replace is exactly the same length. Other
functions will allocate other storage for the variable, and it will no
longer overlay the mapped in file.

* Sys::Mmap-&gt;new( 'VARIABLE', 'LENGTH', 'OPTIONALFILENAME' )

Maps 'LENGTH' bytes of (the contents of) 'OPTIONALFILENAME' if
'OPTIONALFILENAME' is provided, otherwise uses anonymous, shared
inheritable memory. This memory region is inherited by any 'fork()'ed
children. 'VARIABLE' will now refer to the contents of that file. Any
change to 'VARIABLE' will make an identical change to the file. If 'LENGTH'
is zero and a file is specified, the current length of the file will be
used. If 'LENGTH' is larger then the file, and 'OPTIONALFILENAME' is
provided, the file is grown to that length before being mapped. This is the
preferred interface, as it requires much less caution in handling the
variable. 'VARIABLE' will be tied into the "Sys::Mmap" package, and
'mmap()' will be called for you.

Assigning to 'VARIABLE' will overwrite the beginning of the file for a
length of the value being assigned in. The rest of the file or memory
region after that point will be left intact. You may use 'substr()' to
assign at a given position:

    substr(VARIABLE, POSITION, LENGTH) = NEWVALUE

* mmap(VARIABLE, LENGTH, PROTECTION, FLAGS, FILEHANDLE, OFFSET)

Maps 'LENGTH' bytes of (the underlying contents of) 'FILEHANDLE' into your
address space, starting at offset 'OFFSET' and makes 'VARIABLE' refer to
that memory. The 'OFFSET' argument can be omitted in which case it defaults
to zero. The 'LENGTH' argument can be zero in which case a stat is done on
'FILEHANDLE' and the size of the underlying file is used instead.

The 'PROTECTION' argument should be some ORed combination of the constants
'PROT_READ', 'PROT_WRITE' and 'PROT_EXEC', or else 'PROT_NONE'. The
constants 'PROT_EXEC' and 'PROT_NONE' are unlikely to be useful here but
are included for completeness.

The 'FLAGS' argument must include either 'MAP_SHARED' or 'MAP_PRIVATE' (the
latter is unlikely to be useful here). If your platform supports it, you
may also use 'MAP_ANON' or 'MAP_ANONYMOUS'. If your platform supplies
'MAP_FILE' as a non-zero constant (necessarily non-POSIX) then you should
also include that in 'FLAGS'. POSIX.1b does not specify 'MAP_FILE' as a
'FLAG' argument and most if not all versions of Unix have 'MAP_FILE' as
zero.

mmap returns 'undef' on failure, and the address in memory where the
variable was mapped to on success.

* munmap(VARIABLE)

Unmaps the part of your address space which was previously mapped in with a
call to 'mmap(VARIABLE, ...)' and makes VARIABLE become undefined.

munmap returns 1 on success and undef on failure.

* hardwire(VARIABLE, ADDRESS, LENGTH)

Specifies the address in memory of a variable, possibly within a region
you've 'mmap()'ed another variable to. You must use the same precautions to
keep the variable from being reallocated, and use 'substr()' with an exact
length. If you 'munmap()' a region that a 'hardwire()'ed variable lives in,
the 'hardwire()'ed variable will not automatically be 'undef'ed. You must
do this manually.

* Constants

The Sys::Mmap module exports the following constants into your namespace:

    MAP_SHARED MAP_PRIVATE MAP_ANON MAP_ANONYMOUS MAP_FILE
    MAP_NORESERVE MAP_POPULATE
    MAP_HUGETLB MAP_HUGE_2MB MAP_HUGE_1GB
    PROT_EXEC PROT_NONE PROT_READ PROT_WRITE

Of the constants beginning with 'MAP_', only 'MAP_SHARED' and 'MAP_PRIVATE'
are defined in POSIX.1b and only 'MAP_SHARED' is likely to be useful.</description>
  <packager></packager>
  <url>https://metacpan.org/release/Sys-Mmap</url>
  <time file="1765374041" build="1765374034"/>
  <size package="39514" installed="111156" archive="113292"/>
  <location href="aarch64/perl-Sys-Mmap-0.200.0-lp160.4.2.aarch64.rpm"/>
  <format>
    <rpm:license>Artistic-1.0 OR GPL-1.0-or-later</rpm:license>
    <rpm:vendor>obs://build.opensuse.org/home:silicon_chip</rpm:vendor>
    <rpm:group>Unspecified</rpm:group>
    <rpm:buildhost>reproducible</rpm:buildhost>
    <rpm:sourcerpm>perl-Sys-Mmap-0.200.0-lp160.4.2.src.rpm</rpm:sourcerpm>
    <rpm:header-range start="4504" end="16181"/>
    <rpm:provides>
      <rpm:entry name="perl(Sys::Mmap)" flags="EQ" epoch="0" ver="0.200.0"/>
      <rpm:entry name="perl-Sys-Mmap" flags="EQ" epoch="0" ver="0.200.0" rel="lp160.4.2"/>
      <rpm:entry name="perl-Sys-Mmap(aarch-64)" flags="EQ" epoch="0" ver="0.200.0" rel="lp160.4.2"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="ld-linux-aarch64.so.1()(64bit)"/>
      <rpm:entry name="ld-linux-aarch64.so.1(GLIBC_2.17)(64bit)"/>
      <rpm:entry name="perl(:MODULE_COMPAT_5.42.0)"/>
      <rpm:entry name="libc.so.6(GLIBC_2.38)(64bit)"/>
    </rpm:requires>
  </format>
</package>
<package type="rpm">
  <name>perl-Sys-Mmap</name>
  <arch>src</arch>
  <version epoch="0" ver="0.200.0" rel="lp160.4.2"/>
  <checksum type="sha512" pkgid="YES">0f1180205e72af56bd2d01f2c45dfbf2da14701fc1addb9ead09c7f71daed179162b55509a8345aef1e13fbdea760b4be10ff8c801a3a3e0d0379eed09ef724d</checksum>
  <summary>Uses mmap to map in a file as a Perl variable</summary>
  <description>The Sys::Mmap module uses the POSIX at https://en.wikipedia.org/wiki/Mmap
call to map in a file as a Perl variable. Memory access by mmap may be
shared between threads or forked processes, and may be a disc file that has
been mapped into memory. Sys::Mmap depends on your operating system
supporting UNIX or POSIX.1b mmap, of course.

*Note* that PerlIO now defines a ':mmap' tag and presents mmap'd files as
regular files, if that is your cup of joe.

Several processes may share one copy of the file or string, saving memory,
and concurrently making changes to portions of the file or string. When not
used with a file, it is an alternative to SysV shared memory. Unlike SysV
shared memory, there are no arbitrary size limits on the shared memory
area, and sparse memory usage is handled optimally on most modern UNIX
implementations.

Using the 'new()' method provides a 'tie()''d interface to 'mmap()' that
allows you to use the variable as a normal variable. If a filename is
provided, the file is opened and mapped in. If the file is smaller than the
length provided, the file is grown to that length. If no filename is
provided, anonymous shared inheritable memory is used. Assigning to the
variable will replace a section in the file corresponding to the length of
the variable, leaving the remainder of the file intact and unmodified.
Using 'substr()' allows you to access the file at an offset, and does not
place any requirements on the length argument to 'substr()' or the length
of the variable being inserted, provided it does not exceed the length of
the memory region. This protects you from the pathological cases involved
in using 'mmap()' directly, documented below.

When calling 'mmap()' or 'hardwire()' directly, you need to be careful how
you use the variable. Some programming constructs may create copies of a
string which, while unimportant for smallish strings, are far less welcome
if you're mapping in a file which is a few gigabytes big. If you use
'PROT_WRITE' and attempt to write to the file via the variable you need to
be even more careful. One of the few ways in which you can safely write to
the string in-place is by using 'substr()' as an lvalue and ensuring that
the part of the string that you replace is exactly the same length. Other
functions will allocate other storage for the variable, and it will no
longer overlay the mapped in file.

* Sys::Mmap-&gt;new( 'VARIABLE', 'LENGTH', 'OPTIONALFILENAME' )

Maps 'LENGTH' bytes of (the contents of) 'OPTIONALFILENAME' if
'OPTIONALFILENAME' is provided, otherwise uses anonymous, shared
inheritable memory. This memory region is inherited by any 'fork()'ed
children. 'VARIABLE' will now refer to the contents of that file. Any
change to 'VARIABLE' will make an identical change to the file. If 'LENGTH'
is zero and a file is specified, the current length of the file will be
used. If 'LENGTH' is larger then the file, and 'OPTIONALFILENAME' is
provided, the file is grown to that length before being mapped. This is the
preferred interface, as it requires much less caution in handling the
variable. 'VARIABLE' will be tied into the "Sys::Mmap" package, and
'mmap()' will be called for you.

Assigning to 'VARIABLE' will overwrite the beginning of the file for a
length of the value being assigned in. The rest of the file or memory
region after that point will be left intact. You may use 'substr()' to
assign at a given position:

    substr(VARIABLE, POSITION, LENGTH) = NEWVALUE

* mmap(VARIABLE, LENGTH, PROTECTION, FLAGS, FILEHANDLE, OFFSET)

Maps 'LENGTH' bytes of (the underlying contents of) 'FILEHANDLE' into your
address space, starting at offset 'OFFSET' and makes 'VARIABLE' refer to
that memory. The 'OFFSET' argument can be omitted in which case it defaults
to zero. The 'LENGTH' argument can be zero in which case a stat is done on
'FILEHANDLE' and the size of the underlying file is used instead.

The 'PROTECTION' argument should be some ORed combination of the constants
'PROT_READ', 'PROT_WRITE' and 'PROT_EXEC', or else 'PROT_NONE'. The
constants 'PROT_EXEC' and 'PROT_NONE' are unlikely to be useful here but
are included for completeness.

The 'FLAGS' argument must include either 'MAP_SHARED' or 'MAP_PRIVATE' (the
latter is unlikely to be useful here). If your platform supports it, you
may also use 'MAP_ANON' or 'MAP_ANONYMOUS'. If your platform supplies
'MAP_FILE' as a non-zero constant (necessarily non-POSIX) then you should
also include that in 'FLAGS'. POSIX.1b does not specify 'MAP_FILE' as a
'FLAG' argument and most if not all versions of Unix have 'MAP_FILE' as
zero.

mmap returns 'undef' on failure, and the address in memory where the
variable was mapped to on success.

* munmap(VARIABLE)

Unmaps the part of your address space which was previously mapped in with a
call to 'mmap(VARIABLE, ...)' and makes VARIABLE become undefined.

munmap returns 1 on success and undef on failure.

* hardwire(VARIABLE, ADDRESS, LENGTH)

Specifies the address in memory of a variable, possibly within a region
you've 'mmap()'ed another variable to. You must use the same precautions to
keep the variable from being reallocated, and use 'substr()' with an exact
length. If you 'munmap()' a region that a 'hardwire()'ed variable lives in,
the 'hardwire()'ed variable will not automatically be 'undef'ed. You must
do this manually.

* Constants

The Sys::Mmap module exports the following constants into your namespace:

    MAP_SHARED MAP_PRIVATE MAP_ANON MAP_ANONYMOUS MAP_FILE
    MAP_NORESERVE MAP_POPULATE
    MAP_HUGETLB MAP_HUGE_2MB MAP_HUGE_1GB
    PROT_EXEC PROT_NONE PROT_READ PROT_WRITE

Of the constants beginning with 'MAP_', only 'MAP_SHARED' and 'MAP_PRIVATE'
are defined in POSIX.1b and only 'MAP_SHARED' is likely to be useful.</description>
  <packager></packager>
  <url>https://metacpan.org/release/Sys-Mmap</url>
  <time file="1765374041" build="1765374034"/>
  <size package="48319" installed="27968" archive="28608"/>
  <location href="src/perl-Sys-Mmap-0.200.0-lp160.4.2.src.rpm"/>
  <format>
    <rpm:license>Artistic-1.0 OR GPL-1.0-or-later</rpm:license>
    <rpm:vendor>obs://build.opensuse.org/home:silicon_chip</rpm:vendor>
    <rpm:group>Unspecified</rpm:group>
    <rpm:buildhost>reproducible</rpm:buildhost>
    <rpm:sourcerpm></rpm:sourcerpm>
    <rpm:header-range start="4504" end="25420"/>
    <rpm:provides>
      <rpm:entry name="perl-Sys-Mmap" flags="EQ" epoch="0" ver="0.200.0" rel="lp160.4.2"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="perl"/>
      <rpm:entry name="perl-macros"/>
    </rpm:requires>
  </format>
</package>
<package type="rpm">
  <name>perl-Sys-Mmap</name>
  <arch>x86_64</arch>
  <version epoch="0" ver="0.200.0" rel="lp160.4.2"/>
  <checksum type="sha512" pkgid="YES">f88ed3b816d2f0606e85ae20b63034040991a3b7ebddc650a01b0a502503bad55719ec78e939f103debecba6ef6e0bf57f0387cdc25b4070ae17ef2264706363</checksum>
  <summary>Uses mmap to map in a file as a Perl variable</summary>
  <description>The Sys::Mmap module uses the POSIX at https://en.wikipedia.org/wiki/Mmap
call to map in a file as a Perl variable. Memory access by mmap may be
shared between threads or forked processes, and may be a disc file that has
been mapped into memory. Sys::Mmap depends on your operating system
supporting UNIX or POSIX.1b mmap, of course.

*Note* that PerlIO now defines a ':mmap' tag and presents mmap'd files as
regular files, if that is your cup of joe.

Several processes may share one copy of the file or string, saving memory,
and concurrently making changes to portions of the file or string. When not
used with a file, it is an alternative to SysV shared memory. Unlike SysV
shared memory, there are no arbitrary size limits on the shared memory
area, and sparse memory usage is handled optimally on most modern UNIX
implementations.

Using the 'new()' method provides a 'tie()''d interface to 'mmap()' that
allows you to use the variable as a normal variable. If a filename is
provided, the file is opened and mapped in. If the file is smaller than the
length provided, the file is grown to that length. If no filename is
provided, anonymous shared inheritable memory is used. Assigning to the
variable will replace a section in the file corresponding to the length of
the variable, leaving the remainder of the file intact and unmodified.
Using 'substr()' allows you to access the file at an offset, and does not
place any requirements on the length argument to 'substr()' or the length
of the variable being inserted, provided it does not exceed the length of
the memory region. This protects you from the pathological cases involved
in using 'mmap()' directly, documented below.

When calling 'mmap()' or 'hardwire()' directly, you need to be careful how
you use the variable. Some programming constructs may create copies of a
string which, while unimportant for smallish strings, are far less welcome
if you're mapping in a file which is a few gigabytes big. If you use
'PROT_WRITE' and attempt to write to the file via the variable you need to
be even more careful. One of the few ways in which you can safely write to
the string in-place is by using 'substr()' as an lvalue and ensuring that
the part of the string that you replace is exactly the same length. Other
functions will allocate other storage for the variable, and it will no
longer overlay the mapped in file.

* Sys::Mmap-&gt;new( 'VARIABLE', 'LENGTH', 'OPTIONALFILENAME' )

Maps 'LENGTH' bytes of (the contents of) 'OPTIONALFILENAME' if
'OPTIONALFILENAME' is provided, otherwise uses anonymous, shared
inheritable memory. This memory region is inherited by any 'fork()'ed
children. 'VARIABLE' will now refer to the contents of that file. Any
change to 'VARIABLE' will make an identical change to the file. If 'LENGTH'
is zero and a file is specified, the current length of the file will be
used. If 'LENGTH' is larger then the file, and 'OPTIONALFILENAME' is
provided, the file is grown to that length before being mapped. This is the
preferred interface, as it requires much less caution in handling the
variable. 'VARIABLE' will be tied into the "Sys::Mmap" package, and
'mmap()' will be called for you.

Assigning to 'VARIABLE' will overwrite the beginning of the file for a
length of the value being assigned in. The rest of the file or memory
region after that point will be left intact. You may use 'substr()' to
assign at a given position:

    substr(VARIABLE, POSITION, LENGTH) = NEWVALUE

* mmap(VARIABLE, LENGTH, PROTECTION, FLAGS, FILEHANDLE, OFFSET)

Maps 'LENGTH' bytes of (the underlying contents of) 'FILEHANDLE' into your
address space, starting at offset 'OFFSET' and makes 'VARIABLE' refer to
that memory. The 'OFFSET' argument can be omitted in which case it defaults
to zero. The 'LENGTH' argument can be zero in which case a stat is done on
'FILEHANDLE' and the size of the underlying file is used instead.

The 'PROTECTION' argument should be some ORed combination of the constants
'PROT_READ', 'PROT_WRITE' and 'PROT_EXEC', or else 'PROT_NONE'. The
constants 'PROT_EXEC' and 'PROT_NONE' are unlikely to be useful here but
are included for completeness.

The 'FLAGS' argument must include either 'MAP_SHARED' or 'MAP_PRIVATE' (the
latter is unlikely to be useful here). If your platform supports it, you
may also use 'MAP_ANON' or 'MAP_ANONYMOUS'. If your platform supplies
'MAP_FILE' as a non-zero constant (necessarily non-POSIX) then you should
also include that in 'FLAGS'. POSIX.1b does not specify 'MAP_FILE' as a
'FLAG' argument and most if not all versions of Unix have 'MAP_FILE' as
zero.

mmap returns 'undef' on failure, and the address in memory where the
variable was mapped to on success.

* munmap(VARIABLE)

Unmaps the part of your address space which was previously mapped in with a
call to 'mmap(VARIABLE, ...)' and makes VARIABLE become undefined.

munmap returns 1 on success and undef on failure.

* hardwire(VARIABLE, ADDRESS, LENGTH)

Specifies the address in memory of a variable, possibly within a region
you've 'mmap()'ed another variable to. You must use the same precautions to
keep the variable from being reallocated, and use 'substr()' with an exact
length. If you 'munmap()' a region that a 'hardwire()'ed variable lives in,
the 'hardwire()'ed variable will not automatically be 'undef'ed. You must
do this manually.

* Constants

The Sys::Mmap module exports the following constants into your namespace:

    MAP_SHARED MAP_PRIVATE MAP_ANON MAP_ANONYMOUS MAP_FILE
    MAP_NORESERVE MAP_POPULATE
    MAP_HUGETLB MAP_HUGE_2MB MAP_HUGE_1GB
    PROT_EXEC PROT_NONE PROT_READ PROT_WRITE

Of the constants beginning with 'MAP_', only 'MAP_SHARED' and 'MAP_PRIVATE'
are defined in POSIX.1b and only 'MAP_SHARED' is likely to be useful.</description>
  <packager></packager>
  <url>https://metacpan.org/release/Sys-Mmap</url>
  <time file="1765374242" build="1765374238"/>
  <size package="39539" installed="61076" archive="63208"/>
  <location href="x86_64/perl-Sys-Mmap-0.200.0-lp160.4.2.x86_64.rpm"/>
  <format>
    <rpm:license>Artistic-1.0 OR GPL-1.0-or-later</rpm:license>
    <rpm:vendor>obs://build.opensuse.org/home:silicon_chip</rpm:vendor>
    <rpm:group>Unspecified</rpm:group>
    <rpm:buildhost>reproducible</rpm:buildhost>
    <rpm:sourcerpm>perl-Sys-Mmap-0.200.0-lp160.4.2.src.rpm</rpm:sourcerpm>
    <rpm:header-range start="4504" end="16169"/>
    <rpm:provides>
      <rpm:entry name="perl(Sys::Mmap)" flags="EQ" epoch="0" ver="0.200.0"/>
      <rpm:entry name="perl-Sys-Mmap" flags="EQ" epoch="0" ver="0.200.0" rel="lp160.4.2"/>
      <rpm:entry name="perl-Sys-Mmap(x86-64)" flags="EQ" epoch="0" ver="0.200.0" rel="lp160.4.2"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="ld-linux-x86-64.so.2()(64bit)"/>
      <rpm:entry name="ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)"/>
      <rpm:entry name="perl(:MODULE_COMPAT_5.42.0)"/>
      <rpm:entry name="libc.so.6(GLIBC_2.38)(64bit)"/>
    </rpm:requires>
  </format>
</package>
</metadata>