------=_Part_2973_524919056.1502094924494
Content-Type: multipart/alternative;
 boundary="----=_Part_2974_1918574343.1502094924494"

------=_Part_2974_1918574343.1502094924494
Content-Type: text/plain; charset="UTF-8"

I thought something like this had already been proposed but I could not
find the link. Does anyone recall and previous discussion?
I present this as something which could be turned into a proposal if the
group thinks there is any merit.

*Motivation*

Some operations on a POSIX system, notably locking, require access to a
low-level file descriptor <https://en.wikipedia.org/wiki/File_descriptor>.

The C++ standard does not mandate any mechanism to contruct a stream buffer
from a file descriptor
or to obtain the underlying file descriptor though it is almost certainly
accessible in an implementation
on a POSIX system.
Many implementations of libstdc++ provide their own extensions allowing a
buffer to be constructed from one
directly.

The canonical and arguably more portable method of doing this is for the
user to derive a new streambuf themselves
based on stdio functions. There are a few variants of this available off
the shelf (e.g. stdio_buffer).

This is the typical answer given to the FAQ of how to do this on stack
overflow and elsewhere.

This is 'portable' because libc and stdio are required if even POSIX is not.

*Proposal*

I propose extending std::filebuf with:


   - a constructor accepting a representation of a low level file
   descriptor
   - a method for obtaining the representation of the underlying low level
   file descriptor


Options for the low level file descriptor representation:


   - a naked file descriptor. i.e. an integer
   - a FILE*
   - a struct wrapping a file descriptor which in POSIX is just an integer


A naked file descriptor is just an integer and therefore a very leaky
abstraction.
However this is the abstraction that is most often available in existing
implementations (notably gcc).

A FILE* mandates C stdio behaviour which may include buffering (see for
example
https://stackoverflow.com/questions/2423628/whats-the-difference-between-a-file-descriptor-and-file-pointer).
It may be that there are use cases where buffering identical to stdio is
desired. These are not considered by this proposal.

I therefore suggest the methods make use of a 'file descriptor' struct
which is opaque to the standard
but allows implementation defined access to the low level representation.

On a POSIX system this could be a POD type like:

struct std::file_descriptor
{
   int fileDes;
};

There already exist feature testing macros for POSIX itself.
The C++ standard could recognise the existance of _POSIX_C_SOURCE and if
defined mandate the fileDes member exists.

This does introduce a coupling between ISO C++ and POSIX but it is a
trivial one.

On non-POSIX systems the type would remain opaque but there would still be
a standard way
to obtain low level access that might have similar application on those
platforms.

It is notable that the filesystem ts introduces several Unix friendly
functions such as those
for dealing with symbolic links. This proposal aims to go in a similar
direction.

*use cases*

The primary use case considered is to provide interoperability with the
POSIX functions
 fcntl, lockf & fdopen.

Specifically to enable:

   - file locking


'file' descriptor access also enables the creation of:


   - streams representing a pipe.



*alternatives to this proposal*:


   - provide an implementation of stdio_buffer in the library which is
   required to be based on FILE*
   - provide an implementation of stdio_buffer in the library which is
   based on a file descriptor if _POSIX_C_SOURCE is defined
   - provide higher-level interfaces for the use cases considered
   - do nothing. Leave the status quo as is.

I argue against the "do nothing" option as this is a frequent requirement
on POSIX based systems
as evidenced by questions on stack overflow and elsewhere going back many
years.
See: https://www.google.co.uk/search?q=fstream+and+file+descriptor

and notably:
 https://stackoverflow.com/questions/2746168/how-to-construct-a-c-fstream-from-a-posix-file-descriptor

Implementing a fdbuf is also described in Nicolai Josuttis's "The C++
Standard Library".

Providing higher-level interfaces is fraught with implementation defined
issues which would need to be worked out in full.
Such proposals might require something like this proposal as a low-level
interface on which to build
or they might use an entirely different mechanism e.g.
http://www.boost.org/doc/libs/1_44_0/doc/html/boost/interprocess/file_lock.html

*Relation to previous proposals*

Though this must come up often. I have not seen a recent concrete proposal.
The most recent discussion I can find is:

https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/posix/std-proposals/Q4RdFSZggSE/RcRWo1S7dKsJ

Boost ASIO includes a posix::stream_descriptor (see
http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/reference/posix__stream_descriptor.html).
This does not appear in the networking TS proposal -
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/83f911d8-9e79-4589-9e16-ba45961a4bdb%40isocpp.org.

------=_Part_2974_1918574343.1502094924494
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I thought something like this had already been proposed bu=
t I could not find the link. Does anyone recall and previous discussion?<br=
>I present this as something which could be turned into a proposal if the g=
roup thinks there is any merit.<br><br><b>Motivation</b><br><br>Some operat=
ions on a POSIX system, notably locking, require access to a low-level <a h=
ref=3D"https://en.wikipedia.org/wiki/File_descriptor">file descriptor</a>.<=
br><br>The C++ standard does not mandate any mechanism to contruct a stream=
 buffer from a file descriptor<br>or to obtain the underlying file descript=
or though it is almost certainly accessible in an implementation<br>on a PO=
SIX system.<br>Many implementations of libstdc++ provide their own extensio=
ns allowing a buffer to be constructed from one<br>directly.<br><br>The can=
onical and arguably more portable method of doing this is for the user to d=
erive a new streambuf themselves<br>based on stdio functions. There are a f=
ew variants of this available off the shelf (e.g. stdio_buffer).<br><br>Thi=
s is the typical answer given to the FAQ of how to do this on stack overflo=
w and elsewhere.<br><br>This is &#39;portable&#39; because libc and stdio a=
re required if even POSIX is not.<br><br><b>Proposal</b><br><br>I propose e=
xtending std::filebuf with:<br><br><ul><li>a constructor accepting a repres=
entation of a low level file descriptor </li><li>a method for obtaining the=
 representation of the underlying low level file descriptor </li></ul><br>O=
ptions for the low level file descriptor representation:<br><br><ul><li>a n=
aked file descriptor. i.e. an integer</li><li>a FILE*</li><li>a struct wrap=
ping a file descriptor which in POSIX is just an integer</li></ul><br>A nak=
ed file descriptor is just an integer and therefore a very leaky abstractio=
n.<br>However this is the abstraction that is most often available in exist=
ing implementations (notably gcc).<br><br>A FILE* mandates C stdio behaviou=
r which may include buffering (see for example https://stackoverflow.com/qu=
estions/2423628/whats-the-difference-between-a-file-descriptor-and-file-poi=
nter).<br>It may be that there are use cases where buffering identical to s=
tdio is desired. These are not considered by this proposal.<br><br>I theref=
ore suggest the methods make use of a &#39;file descriptor&#39; struct whic=
h is opaque to the standard<br>but allows implementation defined access to =
the low level representation.<br><br>On a POSIX system this could be a POD =
type like:<br><br>struct std::file_descriptor<br>{<br>=C2=A0=C2=A0 int file=
Des;<br>};<br><br>There already exist feature testing macros for POSIX itse=
lf.<br>The C++ standard could recognise the existance of _POSIX_C_SOURCE an=
d if defined mandate the fileDes member exists.<br><br>This does introduce =
a coupling between ISO C++ and POSIX but it is a trivial one.<br><br>On non=
-POSIX systems the type would remain opaque but there would still be a stan=
dard way<br>to obtain low level access that might have similar application =
on those platforms.<br><br>It is notable that the filesystem ts introduces =
several Unix friendly functions such as those<br>for dealing with symbolic =
links. This proposal aims to go in a similar direction.<br><br><b>use cases=
</b><br><br>The primary use case considered is to provide interoperability =
with the POSIX functions<br>=C2=A0fcntl, lockf &amp; fdopen.<br><br>Specifi=
cally to enable:<br><ul><li>file locking</li></ul><br>&#39;file&#39; descri=
ptor access also enables the creation of:<br><br><ul><li>streams representi=
ng a pipe.</li></ul><br><br><b>alternatives to this proposal</b>:<br><br><u=
l><li>provide an implementation of stdio_buffer in the library which is req=
uired to be based on FILE*</li><li>provide an implementation of stdio_buffe=
r in the library which is based on a file descriptor if _POSIX_C_SOURCE is =
defined</li><li>provide higher-level interfaces for the use cases considere=
d</li><li>do nothing. Leave the status quo as is.</li></ul>I argue against =
the &quot;do nothing&quot; option as this is a frequent requirement on POSI=
X based systems<br>as evidenced by questions on stack overflow and elsewher=
e going back many years.<br>See: https://www.google.co.uk/search?q=3Dfstrea=
m+and+file+descriptor<br><br>and notably:<br>=C2=A0https://stackoverflow.co=
m/questions/2746168/how-to-construct-a-c-fstream-from-a-posix-file-descript=
or<br><br>Implementing a fdbuf is also described in Nicolai Josuttis&#39;s =
&quot;The C++ Standard Library&quot;.<br><br>Providing higher-level interfa=
ces is fraught with implementation defined issues which would need to be wo=
rked out in full.<br>Such proposals might require something like this propo=
sal as a low-level interface on which to build<br>or they might use an enti=
rely different mechanism e.g. http://www.boost.org/doc/libs/1_44_0/doc/html=
/boost/interprocess/file_lock.html<br><br><b>Relation to previous proposals=
</b><br><br>Though this must come up often. I have not seen a recent concre=
te proposal.<br>The most recent discussion I can find is:<br><br>https://gr=
oups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/posi=
x/std-proposals/Q4RdFSZggSE/RcRWo1S7dKsJ<br><br>Boost ASIO includes a posix=
::stream_descriptor (see http://www.boost.org/doc/libs/1_47_0/doc/html/boos=
t_asio/reference/posix__stream_descriptor.html).<br>This does not appear in=
 the networking TS proposal - http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2017/n4656.pdf<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/83f911d8-9e79-4589-9e16-ba45961a4bdb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83f911d8-9e79-4589-9e16-ba45961a4bdb=
%40isocpp.org</a>.<br />

------=_Part_2974_1918574343.1502094924494--

------=_Part_2973_524919056.1502094924494--

.

On 7 August 2017 at 11:35,  <tortoise741@gmail.com> wrote:
> I thought something like this had already been proposed but I could not find
> the link. Does anyone recall and previous discussion?
> I present this as something which could be turned into a proposal if the
> group thinks there is any merit.
>
> Motivation
>
> Some operations on a POSIX system, notably locking, require access to a
> low-level file descriptor.
>
> The C++ standard does not mandate any mechanism to contruct a stream buffer
> from a file descriptor
> or to obtain the underlying file descriptor though it is almost certainly
> accessible in an implementation
> on a POSIX system.
> Many implementations of libstdc++ provide their own extensions allowing a
> buffer to be constructed from one
> directly.
>
> The canonical and arguably more portable method of doing this is for the
> user to derive a new streambuf themselves
> based on stdio functions. There are a few variants of this available off the
> shelf (e.g. stdio_buffer).
>
> This is the typical answer given to the FAQ of how to do this on stack
> overflow and elsewhere.
>
> This is 'portable' because libc and stdio are required if even POSIX is not.

In general, yes, please, it would be about time C++ gains this
functionality in a semi-portable manner.

> Proposal
>
> I propose extending std::filebuf with:
>
> a constructor accepting a representation of a low level file descriptor
> a method for obtaining the representation of the underlying low level file
> descriptor

Why not just add a stdio_filebuf and a native_filebuf (for the native
descriptor)? Why should
we extend filebuf?

> Options for the low level file descriptor representation:
>
> a naked file descriptor. i.e. an integer
> a FILE*
> a struct wrapping a file descriptor which in POSIX is just an integer

If we want to be minimal, fdopen() already gives us a FILE* from a
descriptor, and fileno() gives a descriptor
from a FILE*. If we want to provide convenience, we should support
creating streams from both a FILE* and
a descriptor. I suggest we should provide convenience.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbpeTCsvvwzjoy2U-R2heebO10V5DERcORccogKu5%2Ba2Q%40mail.gmail.com.

.

------=_Part_1011_225057571.1502098438951
Content-Type: multipart/alternative;
 boundary="----=_Part_1012_2138328637.1502098438951"

------=_Part_1012_2138328637.1502098438951
Content-Type: text/plain; charset="UTF-8"

What would be the motivating use cases for providing both stdio_filebuf and
a native_filebuf rather than extending filebuf
which seems to me like a more simple change?

If you want convenience you could add a FILE* method as well as a file
descriptor based one.
I think to do that you might have to consider the subtle interactions
between FILE* buffering and fstream buffering.

There is already the case of what to do with file operations made via a
file descriptor (or FILE*) rater than via the fstream.
My initial thought was any read, write or seek operation could make the
subsequent state of the fstream undefined (due to differences in buffering
behaviour)
Otherwise we must mandate that filebuf is based on FILE* or filedes to
guarantee it is defined.
Perhaps that is why you prefer stdio_filebuf and native_filebuf?

On Monday, 7 August 2017 09:44:53 UTC+1, Ville Voutilainen wrote:
>
> On 7 August 2017 at 11:35,  <torto...@gmail.com <javascript:>> wrote:
> > I thought something like this had already been proposed but I could not
> find
> > the link. Does anyone recall and previous discussion?
> > I present this as something which could be turned into a proposal if the
> > group thinks there is any merit.
> >
> > Motivation
> >
> > Some operations on a POSIX system, notably locking, require access to a
> > low-level file descriptor.
> >
> > The C++ standard does not mandate any mechanism to contruct a stream
> buffer
> > from a file descriptor
> > or to obtain the underlying file descriptor though it is almost
> certainly
> > accessible in an implementation
> > on a POSIX system.
> > Many implementations of libstdc++ provide their own extensions allowing
> a
> > buffer to be constructed from one
> > directly.
> >
> > The canonical and arguably more portable method of doing this is for the
> > user to derive a new streambuf themselves
> > based on stdio functions. There are a few variants of this available off
> the
> > shelf (e.g. stdio_buffer).
> >
> > This is the typical answer given to the FAQ of how to do this on stack
> > overflow and elsewhere.
> >
> > This is 'portable' because libc and stdio are required if even POSIX is
> not.
>
> In general, yes, please, it would be about time C++ gains this
> functionality in a semi-portable manner.
>
> > Proposal
> >
> > I propose extending std::filebuf with:
> >
> > a constructor accepting a representation of a low level file descriptor
> > a method for obtaining the representation of the underlying low level
> file
> > descriptor
>
> Why not just add a stdio_filebuf and a native_filebuf (for the native
> descriptor)? Why should
> we extend filebuf?
>
> > Options for the low level file descriptor representation:
> >
> > a naked file descriptor. i.e. an integer
> > a FILE*
> > a struct wrapping a file descriptor which in POSIX is just an integer
>
> If we want to be minimal, fdopen() already gives us a FILE* from a
> descriptor, and fileno() gives a descriptor
> from a FILE*. If we want to provide convenience, we should support
> creating streams from both a FILE* and
> a descriptor. I suggest we should provide convenience.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fc563c81-56ce-4b50-aea2-650b72f9afbc%40isocpp.org.

------=_Part_1012_2138328637.1502098438951
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What would be the motivating use cases for providing both =
stdio_filebuf and a native_filebuf rather than extending filebuf<br>which s=
eems to me like a more simple change?<br><br>If you want convenience you co=
uld add a FILE* method as well as a file descriptor based one.<br>I think t=
o do that you might have to consider the subtle interactions between FILE* =
buffering and fstream buffering.<br><br>There is already the case of what t=
o do with file operations made via a file descriptor (or FILE*) rater than =
via the fstream.<br>My initial thought was any read, write or seek operatio=
n could make the subsequent state of the fstream undefined (due to differen=
ces in buffering behaviour)<br>Otherwise we must mandate that filebuf is ba=
sed on FILE* or filedes to guarantee it is defined.<br>Perhaps that is why =
you prefer stdio_filebuf and native_filebuf?<br><br>On Monday, 7 August 201=
7 09:44:53 UTC+1, Ville Voutilainen  wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">On 7 August 2017 at 11:35, =C2=A0&lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"g0EO-mtBBwAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">torto...@gmail.com</a>&gt; wro=
te:
<br>&gt; I thought something like this had already been proposed but I coul=
d not find
<br>&gt; the link. Does anyone recall and previous discussion?
<br>&gt; I present this as something which could be turned into a proposal =
if the
<br>&gt; group thinks there is any merit.
<br>&gt;
<br>&gt; Motivation
<br>&gt;
<br>&gt; Some operations on a POSIX system, notably locking, require access=
 to a
<br>&gt; low-level file descriptor.
<br>&gt;
<br>&gt; The C++ standard does not mandate any mechanism to contruct a stre=
am buffer
<br>&gt; from a file descriptor
<br>&gt; or to obtain the underlying file descriptor though it is almost ce=
rtainly
<br>&gt; accessible in an implementation
<br>&gt; on a POSIX system.
<br>&gt; Many implementations of libstdc++ provide their own extensions all=
owing a
<br>&gt; buffer to be constructed from one
<br>&gt; directly.
<br>&gt;
<br>&gt; The canonical and arguably more portable method of doing this is f=
or the
<br>&gt; user to derive a new streambuf themselves
<br>&gt; based on stdio functions. There are a few variants of this availab=
le off the
<br>&gt; shelf (e.g. stdio_buffer).
<br>&gt;
<br>&gt; This is the typical answer given to the FAQ of how to do this on s=
tack
<br>&gt; overflow and elsewhere.
<br>&gt;
<br>&gt; This is &#39;portable&#39; because libc and stdio are required if =
even POSIX is not.
<br>
<br>In general, yes, please, it would be about time C++ gains this
<br>functionality in a semi-portable manner.
<br>
<br>&gt; Proposal
<br>&gt;
<br>&gt; I propose extending std::filebuf with:
<br>&gt;
<br>&gt; a constructor accepting a representation of a low level file descr=
iptor
<br>&gt; a method for obtaining the representation of the underlying low le=
vel file
<br>&gt; descriptor
<br>
<br>Why not just add a stdio_filebuf and a native_filebuf (for the native
<br>descriptor)? Why should
<br>we extend filebuf?
<br>
<br>&gt; Options for the low level file descriptor representation:
<br>&gt;
<br>&gt; a naked file descriptor. i.e. an integer
<br>&gt; a FILE*
<br>&gt; a struct wrapping a file descriptor which in POSIX is just an inte=
ger
<br>
<br>If we want to be minimal, fdopen() already gives us a FILE* from a
<br>descriptor, and fileno() gives a descriptor
<br>from a FILE*. If we want to provide convenience, we should support
<br>creating streams from both a FILE* and
<br>a descriptor. I suggest we should provide convenience.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fc563c81-56ce-4b50-aea2-650b72f9afbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fc563c81-56ce-4b50-aea2-650b72f9afbc=
%40isocpp.org</a>.<br />

------=_Part_1012_2138328637.1502098438951--

------=_Part_1011_225057571.1502098438951--

.

------=_Part_4694_1071385496.1502234101721
Content-Type: multipart/alternative;
 boundary="----=_Part_4695_1688815133.1502234101721"

------=_Part_4695_1688815133.1502234101721
Content-Type: text/plain; charset="UTF-8"


>
> The primary use case considered is to provide interoperability with the
> POSIX functions
>  fcntl, lockf & fdopen.
>
> Specifically to enable:
>
>    - file locking
>
> Implemented
at https://ned14.github.io/afio/classafio__v2__xxx_1_1io__handle.html#a88689b15e6e8b6ce1f945737dee4369e.

AFIO also provides a "filesystem template algorithms library (the FTL)"
 which implements file locking via multiple
algorithms: https://ned14.github.io/afio/namespaceafio__v2__xxx_1_1algorithm_1_1shared__fs__mutex.html

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c4539f90-d277-4c2c-b23c-29bdaea8cc87%40isocpp.org.

------=_Part_4695_1688815133.1502234101721
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">The primary use case considered is to provide interoperability with the=
 POSIX functions<br>=C2=A0fcntl, lockf &amp; fdopen.<br><br>Specifically to=
 enable:<br><ul><li>file locking</li></ul></div></blockquote><div>Implement=
ed at=C2=A0https://ned14.github.io/afio/classafio__v2__xxx_1_1io__handle.ht=
ml#a88689b15e6e8b6ce1f945737dee4369e.</div><div><br></div><div>AFIO also pr=
ovides a &quot;filesystem template algorithms library (the FTL)&quot; =C2=
=A0which implements file locking via multiple algorithms:=C2=A0https://ned1=
4.github.io/afio/namespaceafio__v2__xxx_1_1algorithm_1_1shared__fs__mutex.h=
tml</div><div><br></div><div>Niall</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c4539f90-d277-4c2c-b23c-29bdaea8cc87%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c4539f90-d277-4c2c-b23c-29bdaea8cc87=
%40isocpp.org</a>.<br />

------=_Part_4695_1688815133.1502234101721--

------=_Part_4694_1071385496.1502234101721--

.

------=_Part_4966_209242579.1502238476938
Content-Type: multipart/alternative;
 boundary="----=_Part_4967_1300353532.1502238476938"

------=_Part_4967_1300353532.1502238476938
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 9 August 2017 00:15:01 UTC+1, Niall Douglas wrote:
>
> The primary use case considered is to provide interoperability with the
>> POSIX functions
>>  fcntl, lockf & fdopen.
>>
>> Specifically to enable:
>>
>>    - file locking
>>
>> Implemented at
> https://ned14.github.io/afio/classafio__v2__xxx_1_1io__handle.html#a88689b15e6e8b6ce1f945737dee4369e
> .
>
> AFIO also provides a "filesystem template algorithms library (the FTL)"
>  which implements file locking via multiple algorithms:
> https://ned14.github.io/afio/namespaceafio__v2__xxx_1_1algorithm_1_1shared__fs__mutex.html
>
> Niall
>

I'm not sure I understand the relevance here. There are many libraries that
provide support for file locking. Is AFIO on track to become part of the
standard?
or are you just suggesting that alternative approaches (like handling
locking entirely independently of fstream) are in general better?
Even if that is true, does it eliminate all realistic uses for accessing
the file descripter of an fstream?

Regards,

Bruce.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba563ff1-fd24-4897-832b-b9b7141545fd%40isocpp.org.

------=_Part_4967_1300353532.1502238476938
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, 9 August 2017 00:15:01 UTC+1, Niall Douglas =
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The primary use case con=
sidered is to provide interoperability with the POSIX functions<br>=C2=A0fc=
ntl, lockf &amp; fdopen.<br><br>Specifically to enable:<br><ul><li>file loc=
king</li></ul></div></blockquote><div>Implemented at=C2=A0<a href=3D"https:=
//ned14.github.io/afio/classafio__v2__xxx_1_1io__handle.html#a88689b15e6e8b=
6ce1f945737dee4369e" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fned14.github.io%=
2Fafio%2Fclassafio__v2__xxx_1_1io__handle.html%23a88689b15e6e8b6ce1f945737d=
ee4369e\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGv2HdM6nI8iPzJ8aAmOVEDDkyXS=
g&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url=
?q\x3dhttps%3A%2F%2Fned14.github.io%2Fafio%2Fclassafio__v2__xxx_1_1io__hand=
le.html%23a88689b15e6e8b6ce1f945737dee4369e\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNGv2HdM6nI8iPzJ8aAmOVEDDkyXSg&#39;;return true;">https://ned14.gith=
ub.io/<wbr>afio/classafio__v2__xxx_1_1io_<wbr>_handle.html#<wbr>a88689b15e6=
e8b6ce1f945737dee43<wbr>69e</a>.</div><div><br></div><div>AFIO also provide=
s a &quot;filesystem template algorithms library (the FTL)&quot; =C2=A0whic=
h implements file locking via multiple algorithms:=C2=A0<a href=3D"https://=
ned14.github.io/afio/namespaceafio__v2__xxx_1_1algorithm_1_1shared__fs__mut=
ex.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;https://www.google.com/url?q\x3dhttps%3A%2F%2Fned14.github.io%2Fafio%2Fnam=
espaceafio__v2__xxx_1_1algorithm_1_1shared__fs__mutex.html\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNGwSV9CTZSv_w9ZG5nSRB1gNw5kAg&#39;;return true;" onc=
lick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fned1=
4.github.io%2Fafio%2Fnamespaceafio__v2__xxx_1_1algorithm_1_1shared__fs__mut=
ex.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGwSV9CTZSv_w9ZG5nSRB1gNw5kA=
g&#39;;return true;">https://ned14.<wbr>github.io/afio/namespaceafio__<wbr>=
v2__xxx_1_1algorithm_1_<wbr>1shared__fs__mutex.html</a></div><div><br></div=
><div>Niall</div></div></blockquote><div><br>I&#39;m not sure I understand =
the relevance here. There are many libraries=20
that provide support for file locking. Is AFIO on track to become part=20
of the standard?<br>or are you just suggesting that alternative=20
approaches (like handling locking entirely independently of fstream) are
 in general better?<br>Even if that is true, does it eliminate all realisti=
c uses for accessing the file descripter of an fstream?<br><br>Regards,<br>=
<br>Bruce. <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ba563ff1-fd24-4897-832b-b9b7141545fd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba563ff1-fd24-4897-832b-b9b7141545fd=
%40isocpp.org</a>.<br />

------=_Part_4967_1300353532.1502238476938--

------=_Part_4966_209242579.1502238476938--

.

------=_Part_4889_1298794075.1502243354860
Content-Type: multipart/alternative;
 boundary="----=_Part_4890_31585841.1502243354860"

------=_Part_4890_31585841.1502243354860
Content-Type: text/plain; charset="UTF-8"


>
>
> I'm not sure I understand the relevance here. There are many libraries
> that provide support for file locking. Is AFIO on track to become part of
> the standard?
> or are you just suggesting that alternative approaches (like handling
> locking entirely independently of fstream) are in general better?
> Even if that is true, does it eliminate all realistic uses for accessing
> the file descripter of an fstream?
>
>
I'm in favour of iostreams exposing the underlying native handle as you
propose.

I am not in favour of any C++ standard proposing any file locking API
except the one AFIO implements. AFIO's is as portable as it can be, and
even then I can tell you in advance that WG21 will be appalled at the lack
of ability to implement consistent behaviours across platforms.

The Filesystem Template Library is my proposal for leveraging C++
genericity to work around those platform specific differences in a viable
way. It's taken many years of work to reach even this stage where I don't
expect AFIO to land before WG21 until at least 2020. This stuff is very
hard to get right, let alone standardise. POSIX has badly ballsed it up
already, and efforts to fix things there have also taken years to get to
now with many years remaining till fixing the standard can land. But we're
all working it as fast as we can. This is all unpaid effort, and inertia to
change is immense.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f0be5921-42bc-4b51-b9ec-f9ac5f586a5a%40isocpp.org.

------=_Part_4890_31585841.1502243354860
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>I&#39;m not sure I understand the relevance here. There are ma=
ny libraries=20
that provide support for file locking. Is AFIO on track to become part=20
of the standard?<br>or are you just suggesting that alternative=20
approaches (like handling locking entirely independently of fstream) are
 in general better?<br>Even if that is true, does it eliminate all realisti=
c uses for accessing the file descripter of an fstream?<br>=C2=A0<br></div>=
</div></blockquote><div>I&#39;m in favour of iostreams exposing the underly=
ing native handle as you propose.</div><div><br></div><div>I am not in favo=
ur of any C++ standard proposing any file locking API except the one AFIO i=
mplements. AFIO&#39;s is as portable as it can be, and even then I can tell=
 you in advance that WG21 will be appalled at the lack of ability to implem=
ent consistent behaviours across platforms.</div><div><br></div><div>The Fi=
lesystem Template Library is my proposal for leveraging C++ genericity to w=
ork around those platform specific differences in a viable way. It&#39;s ta=
ken many years of work to reach even this stage where I don&#39;t expect AF=
IO to land before WG21 until at least 2020. This stuff is very hard to get =
right, let alone standardise. POSIX has badly ballsed it up already, and ef=
forts to fix things there have also taken years to get to now with many yea=
rs remaining till fixing the standard can land. But we&#39;re all working i=
t as fast as we can. This is all unpaid effort, and inertia to change is im=
mense.</div><div><br></div><div>Niall</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f0be5921-42bc-4b51-b9ec-f9ac5f586a5a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f0be5921-42bc-4b51-b9ec-f9ac5f586a5a=
%40isocpp.org</a>.<br />

------=_Part_4890_31585841.1502243354860--

------=_Part_4889_1298794075.1502243354860--

.

------=_Part_4976_1200721766.1502243676347
Content-Type: multipart/alternative;
 boundary="----=_Part_4977_414425000.1502243676347"

------=_Part_4977_414425000.1502243676347
Content-Type: text/plain; charset="UTF-8"


>
>
> I therefore suggest the methods make use of a 'file descriptor' struct
> which is opaque to the standard
> but allows implementation defined access to the low level representation.
>
> On a POSIX system this could be a POD type like:
>
> struct std::file_descriptor
> {
>    int fileDes;
> };
>
>
Also a further data point: this is the file descriptor struct which Boost
peer review consensus came up with after the v1 AFIO peer review:

https://github.com/ned14/afio/blob/master/include/afio/v2.0/native_handle_type.hpp

It's basically a bitfield for metadata and a union for constexpr init, int
fd, int pid and void *handle.

This was felt by the Boost community to be the correct design at the time
of the review.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1fa9ebd9-cd17-4662-b602-5d8166024e5a%40isocpp.org.

------=_Part_4977_414425000.1502243676347
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br>I therefore suggest the methods make use of a &#39;file descriptor&=
#39; struct which is opaque to the standard<br>but allows implementation de=
fined access to the low level representation.<br><br>On a POSIX system this=
 could be a POD type like:<br><br>struct std::file_descriptor<br>{<br>=C2=
=A0=C2=A0 int fileDes;<br>};<br><br></div></blockquote><div><br></div><div>=
Also a further data point: this is the file descriptor struct which Boost p=
eer review consensus came up with after the v1 AFIO peer review:</div><div>=
<br></div><div>https://github.com/ned14/afio/blob/master/include/afio/v2.0/=
native_handle_type.hpp</div><div><br></div><div>It&#39;s basically a bitfie=
ld for metadata and a union for constexpr init, int fd, int pid and void *h=
andle.</div><div><br></div><div>This was felt by the Boost community to be =
the correct design at the time of the review.</div><div><br></div><div>Nial=
l</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1fa9ebd9-cd17-4662-b602-5d8166024e5a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1fa9ebd9-cd17-4662-b602-5d8166024e5a=
%40isocpp.org</a>.<br />

------=_Part_4977_414425000.1502243676347--

------=_Part_4976_1200721766.1502243676347--

.

On Tuesday, 8 August 2017 18:54:36 PDT Niall Douglas wrote:
> It's basically a bitfield for metadata and a union for constexpr init, int
> fd, int pid and void *handle.

What if it's a file descriptor that represents a process? :-)

See FreeBSD's pdfork(2) function and the proposed Linux CLONE_FD[1] (stuck in
review waiting for someone with ptrace knowledge to help us).

[1] https://lkml.org/lkml/2015/3/15/10

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1839264.k51j7ppGOJ%40tjmaciei-mobl1.

.

------=_Part_5068_1586259543.1502250192824
Content-Type: multipart/alternative;
 boundary="----=_Part_5069_1018103694.1502250192824"

------=_Part_5069_1018103694.1502250192824
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 9, 2017 at 4:26:39 AM UTC+1, Thiago Macieira wrote:
>
> On Tuesday, 8 August 2017 18:54:36 PDT Niall Douglas wrote:
> > It's basically a bitfield for metadata and a union for constexpr init,
> int
> > fd, int pid and void *handle.
>
> What if it's a file descriptor that represents a process? :-)
>
> Absolutely right. Some platforms represent process handles differently to
process ids, some view them as the same. And that's even amongst POSIX
implementations, let alone other OSs. QNX for example has the notion of a
"triplet", so machine + process + fd which can, with UB, be squeezed into
an unsigned long long.

AFIO only concerns itself with file i/o, so the native_handle_type linked
to only makes use of that part rather than properly specifying the whole
thing. But the overall design of kind-of-bitfield +
union-of-intish-like-things was the design proposed by the peer review as
they felt my approach in v1 AFIO was completely wrong. I find it acceptable
personally.

In terms of what best suits the OP's design, either he takes the long road
and specifies out properly a native_handle_type which is correct and
everybody would find a great value add, or he takes the short road and just
returns an int. He should be aware that on MSVCRT, he needs to return BOTH
an int AND a void * because MSVCRT wraps up its HANDLE with a partial fd
emulation. And end using code needs to know about both depending on their
use case.

It's for all these reasons this stuff isn't in the standard already. But I
agree with the OP that it should be. Someone just needs to push it over the
line.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/435dc11f-93b6-4023-bf10-5d874a54fde6%40isocpp.org.

------=_Part_5069_1018103694.1502250192824
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, August 9, 2017 at 4:26:39 AM UTC+1, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, 8 Au=
gust 2017 18:54:36 PDT Niall Douglas wrote:
<br>&gt; It&#39;s basically a bitfield for metadata and a union for constex=
pr init, int
<br>&gt; fd, int pid and void *handle.
<br>
<br>What if it&#39;s a file descriptor that represents a process? :-)
<br>
<br></blockquote><div>Absolutely right. Some platforms represent process ha=
ndles differently to process ids, some view them as the same. And that&#39;=
s even amongst POSIX implementations, let alone other OSs. QNX for example =
has the notion of a &quot;triplet&quot;, so machine + process + fd which ca=
n, with UB, be squeezed into an unsigned long long.</div><div><br></div><di=
v>AFIO only concerns itself with file i/o, so the native_handle_type linked=
 to only makes use of that part rather than properly specifying the whole t=
hing. But the overall design of kind-of-bitfield + union-of-intish-like-thi=
ngs was the design proposed by the peer review as they felt my approach in =
v1 AFIO was completely wrong. I find it acceptable personally.</div><div><b=
r></div><div>In terms of what best suits the OP&#39;s design, either he tak=
es the long road and specifies out properly a native_handle_type which is c=
orrect and everybody would find a great value add, or he takes the short ro=
ad and just returns an int. He should be aware that on MSVCRT, he needs to =
return BOTH an int AND a void * because MSVCRT wraps up its HANDLE with a p=
artial fd emulation. And end using code needs to know about both depending =
on their use case.</div><div><br></div><div>It&#39;s for all these reasons =
this stuff isn&#39;t in the standard already. But I agree with the OP that =
it should be. Someone just needs to push it over the line.</div><div><br></=
div><div>Niall</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/435dc11f-93b6-4023-bf10-5d874a54fde6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/435dc11f-93b6-4023-bf10-5d874a54fde6=
%40isocpp.org</a>.<br />

------=_Part_5069_1018103694.1502250192824--

------=_Part_5068_1586259543.1502250192824--

.

------=_Part_4951_1924287133.1502264667267
Content-Type: multipart/alternative;
 boundary="----=_Part_4952_587125184.1502264667267"

------=_Part_4952_587125184.1502264667267
Content-Type: text/plain; charset="UTF-8"



On Wednesday, 9 August 2017 04:43:12 UTC+1, Niall Douglas wrote:
>
> On Wednesday, August 9, 2017 at 4:26:39 AM UTC+1, Thiago Macieira wrote:
>>
>> On Tuesday, 8 August 2017 18:54:36 PDT Niall Douglas wrote:
>> > It's basically a bitfield for metadata and a union for constexpr init,
>> int
>> > fd, int pid and void *handle.
>>
>> What if it's a file descriptor that represents a process? :-)
>>
>> Absolutely right. Some platforms represent process handles differently to
> process ids, some view them as the same. And that's even amongst POSIX
> implementations, let alone other OSs. QNX for example has the notion of a
> "triplet", so machine + process + fd which can, with UB, be squeezed into
> an unsigned long long.
>
> AFIO only concerns itself with file i/o, so the native_handle_type linked
> to only makes use of that part rather than properly specifying the whole
> thing. But the overall design of kind-of-bitfield +
> union-of-intish-like-things was the design proposed by the peer review as
> they felt my approach in v1 AFIO was completely wrong. I find it acceptable
> personally.
>
> In terms of what best suits the OP's design, either he takes the long road
> and specifies out properly a native_handle_type which is correct and
> everybody would find a great value add, or he takes the short road and just
> returns an int. He should be aware that on MSVCRT, he needs to return BOTH
> an int AND a void * because MSVCRT wraps up its HANDLE with a partial fd
> emulation. And end using code needs to know about both depending on their
> use case.
>
> It's for all these reasons this stuff isn't in the standard already. But I
> agree with the OP that it should be. Someone just needs to push it over the
> line.
>
> Niall
>

I'm against returning a naked file no. I put it up there to show it as the
"simple and wrong" answer to be argued against. I was proposing a more
opaque (and thus implementation defined) structure. I don't see that as
incompatible with a proper native hande. It could easily be an incremental
step towards the structure you need. I don't think there is any way I could
justify the PID field at this point. That could be added in a separate
"native file handle" proposal which you sound in a good position to lay the
ground work for.

I was just hoping to fix a simple and obvious defect without being too
ambitious. With that in mind can you suggest good arguments for just
returning the handle versus providing stdio_filebuf and native_filebuf as
Ville suggested?

Regards,

Bruce.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/643208b1-aab9-4815-bfc4-67210ac851ec%40isocpp.org.

------=_Part_4952_587125184.1502264667267
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 9 August 2017 04:43:12 UTC+1, Niall =
Douglas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Wednesday, August 9, 2017 at 4:26:39 AM UTC+1, Thiago Macieira wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Tuesday, 8 August 2017 18:54:36 P=
DT Niall Douglas wrote:
<br>&gt; It&#39;s basically a bitfield for metadata and a union for constex=
pr init, int
<br>&gt; fd, int pid and void *handle.
<br>
<br>What if it&#39;s a file descriptor that represents a process? :-)
<br>
<br></blockquote><div>Absolutely right. Some platforms represent process ha=
ndles differently to process ids, some view them as the same. And that&#39;=
s even amongst POSIX implementations, let alone other OSs. QNX for example =
has the notion of a &quot;triplet&quot;, so machine + process + fd which ca=
n, with UB, be squeezed into an unsigned long long.</div><div><br></div><di=
v>AFIO only concerns itself with file i/o, so the native_handle_type linked=
 to only makes use of that part rather than properly specifying the whole t=
hing. But the overall design of kind-of-bitfield + union-of-intish-like-thi=
ngs was the design proposed by the peer review as they felt my approach in =
v1 AFIO was completely wrong. I find it acceptable personally.</div><div><b=
r></div><div>In terms of what best suits the OP&#39;s design, either he tak=
es the long road and specifies out properly a native_handle_type which is c=
orrect and everybody would find a great value add, or he takes the short ro=
ad and just returns an int. He should be aware that on MSVCRT, he needs to =
return BOTH an int AND a void * because MSVCRT wraps up its HANDLE with a p=
artial fd emulation. And end using code needs to know about both depending =
on their use case.</div><div><br></div><div>It&#39;s for all these reasons =
this stuff isn&#39;t in the standard already. But I agree with the OP that =
it should be. Someone just needs to push it over the line.</div><div><br></=
div><div>Niall</div></div></blockquote><div><br>I&#39;m against returning a=
 naked file no. I put it up there to show it as the &quot;simple and wrong&=
quot; answer to be argued against. I was proposing a more opaque (and thus =
implementation defined) structure. I don&#39;t see that as incompatible wit=
h a proper native hande. It could easily be an incremental step towards the=
 structure you need. I don&#39;t think there is any way I could justify the=
 PID field at this point. That could be added in a separate &quot;native fi=
le handle&quot; proposal which you sound in a good position to lay the grou=
nd work for.<br><br>I was just hoping to fix a simple and obvious defect wi=
thout being too ambitious. With that in mind can you suggest good arguments=
 for just returning the handle versus providing stdio_filebuf and native_fi=
lebuf as Ville suggested?<br><br>Regards,<br><br>Bruce.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/643208b1-aab9-4815-bfc4-67210ac851ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/643208b1-aab9-4815-bfc4-67210ac851ec=
%40isocpp.org</a>.<br />

------=_Part_4952_587125184.1502264667267--

------=_Part_4951_1924287133.1502264667267--

.

------=_Part_1397_1337358265.1502285891570
Content-Type: multipart/alternative;
 boundary="----=_Part_1398_924049485.1502285891570"

------=_Part_1398_924049485.1502285891570
Content-Type: text/plain; charset="UTF-8"


>
> I was just hoping to fix a simple and obvious defect without being too
> ambitious. With that in mind can you suggest good arguments for just
> returning the handle versus providing stdio_filebuf and native_filebuf as
> Ville suggested?
>
>
> I'm also warm on Ville's suggestion.

Most STL implementations use a C FILE * under the bonnet for iostreams
anyway, so his suggestion makes sense.

If you do write up a proposal, every major STL already provides a
proprietary mechanism for retrieving the underlying native handle. It would
useful if all those mechanisms were surveyed before you propose your
standardised mechanism.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c9f44c40-3e34-4094-b3b7-5301bd2c5d93%40isocpp.org.

------=_Part_1398_924049485.1502285891570
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>I was just hoping to fix a simple and obvious defect without being=
 too ambitious. With that in mind can you suggest good arguments for just r=
eturning the handle versus providing stdio_filebuf and native_filebuf as Vi=
lle suggested?<br><br><br></div></div></blockquote><div>I&#39;m also warm o=
n Ville&#39;s suggestion.</div><div><br></div><div>Most STL implementations=
 use a C FILE * under the bonnet for iostreams anyway, so his suggestion ma=
kes sense.</div><div><br></div><div>If you do write up a proposal, every ma=
jor STL already provides a proprietary mechanism for retrieving the underly=
ing native handle. It would useful if all those mechanisms were surveyed be=
fore you propose your standardised mechanism.</div><div><br></div><div>Nial=
l</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c9f44c40-3e34-4094-b3b7-5301bd2c5d93%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c9f44c40-3e34-4094-b3b7-5301bd2c5d93=
%40isocpp.org</a>.<br />

------=_Part_1398_924049485.1502285891570--

------=_Part_1397_1337358265.1502285891570--

.

------=_Part_321_1458307925.1502322589839
Content-Type: multipart/alternative;
 boundary="----=_Part_322_1521871119.1502322589839"

------=_Part_322_1521871119.1502322589839
Content-Type: text/plain; charset="UTF-8"



On Wednesday, 9 August 2017 14:38:11 UTC+1, Niall Douglas wrote:
>
> I was just hoping to fix a simple and obvious defect without being too
>> ambitious. With that in mind can you suggest good arguments for just
>> returning the handle versus providing stdio_filebuf and native_filebuf as
>> Ville suggested?
>>
>>
>> I'm also warm on Ville's suggestion.
>
> Most STL implementations use a C FILE * under the bonnet for iostreams
> anyway, so his suggestion makes sense.
>
> If you do write up a proposal, every major STL already provides a
> proprietary mechanism for retrieving the underlying native handle. It would
> useful if all those mechanisms were surveyed before you propose your
> standardised mechanism.
>
> Niall
>
>
Absolutely. Though C++ 'standard'isation is in an odd (but good) place
these days. It used to be you standardised what people had been doing for
years anyway but nowadays the aim is often to improve on the current
working practice instead.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bf7ffe5f-1976-474a-a03f-e76fe6cc46f2%40isocpp.org.

------=_Part_322_1521871119.1502322589839
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 9 August 2017 14:38:11 UTC+1, Niall =
Douglas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I was just =
hoping to fix a simple and obvious defect without being too ambitious. With=
 that in mind can you suggest good arguments for just returning the handle =
versus providing stdio_filebuf and native_filebuf as Ville suggested?<br><b=
r><br></div></div></blockquote><div>I&#39;m also warm on Ville&#39;s sugges=
tion.</div><div><br></div><div>Most STL implementations use a C FILE * unde=
r the bonnet for iostreams anyway, so his suggestion makes sense.</div><div=
><br></div><div>If you do write up a proposal, every major STL already prov=
ides a proprietary mechanism for retrieving the underlying native handle. I=
t would useful if all those mechanisms were surveyed before you propose you=
r standardised mechanism.</div><div><br></div><div>Niall</div><div><br></di=
v></div></blockquote><div><br>Absolutely. Though C++ &#39;standard&#39;isat=
ion is in an odd (but good) place these days. It used to be you standardise=
d what people had been doing for years anyway but nowadays the aim is often=
 to improve on the current working practice instead.<br></div><div>=C2=A0</=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf7ffe5f-1976-474a-a03f-e76fe6cc46f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf7ffe5f-1976-474a-a03f-e76fe6cc46f2=
%40isocpp.org</a>.<br />

------=_Part_322_1521871119.1502322589839--

------=_Part_321_1458307925.1502322589839--

.

------=_Part_304_2120725028.1502326367618
Content-Type: multipart/alternative;
 boundary="----=_Part_305_665374236.1502326367618"

------=_Part_305_665374236.1502326367618
Content-Type: text/plain; charset="UTF-8"



On Thursday, 10 August 2017 00:49:49 UTC+1, Bruce Adams wrote:
>
>
>
> On Wednesday, 9 August 2017 14:38:11 UTC+1, Niall Douglas wrote:
>>
>> I was just hoping to fix a simple and obvious defect without being too
>>> ambitious. With that in mind can you suggest good arguments for just
>>> returning the handle versus providing stdio_filebuf and native_filebuf as
>>> Ville suggested?
>>>
>>>
>>> I'm also warm on Ville's suggestion.
>>
>> Most STL implementations use a C FILE * under the bonnet for iostreams
>> anyway, so his suggestion makes sense.
>>
>> If you do write up a proposal, every major STL already provides a
>> proprietary mechanism for retrieving the underlying native handle. It would
>> useful if all those mechanisms were surveyed before you propose your
>> standardised mechanism.
>>
>> Niall
>>
>>
> Absolutely. Though C++ 'standard'isation is in an odd (but good) place
> these days. It used to be you standardised what people had been doing for
> years anyway but nowadays the aim is often to improve on the current
> working practice instead.
>
>

For the case where filebuf is implemented as a FILE* or a FD based
streambuf how do we discourage (or make safe) the case where users make
their code less portable by assuming that filebuf is a stdio_buffer or
native_buffer?
I think it would be going too far to mandate that filebuf is in fact a
stdio_buffer and forcing existing implementations that aren't to sacrifice
performance or whatever other gains they may have.

Perhaps the type of buffer should be an additional template parameter to a
basic_fstream?
The new parameter would require a streambuf with close() and is_open()
functions. The open function is a bit more problematic as that is the one
you want to be able to alter for new kinds of file like buffer thing (e.g
pipe, socket, memory mapped file).
It feels like quite a weakly defined concept.

Or perhaps following your suggestion that a file descriptor is a union that
includes FILE* and FD we need only modify filebuf, essentially as I
originally suggested. It would need to be constructable from both a FILE*
and a FD (though not naked).
I am happy with the file_descriptor that goes in being the one that comes
out. I am also happy with extra information being included where its
available (e.g. where FILE* and FDs are easily interchanged via OS APIs)
but presumably there needs to be a way (a template to specialise) for
library vendors to provide implementations using just FILE* and/or just FD
as they see fit.

What platforms beyond POSIXish and Windows need to be considered? Where in
the standard is that documented?

Bruce.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e749626-cb20-4d9f-b81c-4a41cd69c8bb%40isocpp.org.

------=_Part_305_665374236.1502326367618
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, 10 August 2017 00:49:49 UTC+1, Bruce =
Adams  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>On Wednesday, 9 August 2017 14:38:11 UTC+1, Niall Douglas  wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>I was just hoping to fix a simple=
 and obvious defect without being too ambitious. With that in mind can you =
suggest good arguments for just returning the handle versus providing stdio=
_filebuf and native_filebuf as Ville suggested?<br><br><br></div></div></bl=
ockquote><div>I&#39;m also warm on Ville&#39;s suggestion.</div><div><br></=
div><div>Most STL implementations use a C FILE * under the bonnet for iostr=
eams anyway, so his suggestion makes sense.</div><div><br></div><div>If you=
 do write up a proposal, every major STL already provides a proprietary mec=
hanism for retrieving the underlying native handle. It would useful if all =
those mechanisms were surveyed before you propose your standardised mechani=
sm.</div><div><br></div><div>Niall</div><div><br></div></div></blockquote><=
div><br>Absolutely. Though C++ &#39;standard&#39;isation is in an odd (but =
good) place these days. It used to be you standardised what people had been=
 doing for years anyway but nowadays the aim is often to improve on the cur=
rent working practice instead.<br></div><div>=C2=A0</div></div></blockquote=
><div><br>For the case where filebuf is implemented as a FILE* or a FD base=
d streambuf how do we discourage (or make safe) the case where users make t=
heir code less portable by assuming that filebuf is a stdio_buffer or nativ=
e_buffer?<br>I think it would be going too far to mandate that filebuf is i=
n fact a stdio_buffer and forcing existing implementations that aren&#39;t =
to sacrifice performance or whatever other gains they may have.<br><br>Perh=
aps the type of buffer should be an additional template parameter to a basi=
c_fstream?<br>The new parameter would require a streambuf with close() and =
is_open() functions. The open function is a bit more problematic as that is=
 the one you want to be able to alter for new kinds of file like buffer thi=
ng (e.g pipe, socket, memory mapped file).<br>It feels like quite a weakly =
defined concept.<br><br>Or perhaps following your suggestion that a file de=
scriptor is a union that includes FILE* and FD we need only modify filebuf,=
 essentially as I originally suggested. It would need to be constructable f=
rom both a FILE* and a FD (though not naked).<br>I am happy with the file_d=
escriptor that goes in being the one that comes out. I am also happy with e=
xtra information being included where its available (e.g. where FILE* and F=
Ds are easily interchanged via OS APIs)<br>but presumably there needs to be=
 a way (a template to specialise) for library vendors to provide implementa=
tions using just FILE* and/or just FD as they see fit.<br><br>What platform=
s beyond POSIXish and Windows need to be considered? Where in the standard =
is that documented?<br><br>Bruce.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9e749626-cb20-4d9f-b81c-4a41cd69c8bb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e749626-cb20-4d9f-b81c-4a41cd69c8bb=
%40isocpp.org</a>.<br />

------=_Part_305_665374236.1502326367618--

------=_Part_304_2120725028.1502326367618--

.

------=_Part_420_1313606664.1502331848032
Content-Type: multipart/alternative;
 boundary="----=_Part_421_446042180.1502331848032"

------=_Part_421_446042180.1502331848032
Content-Type: text/plain; charset="UTF-8"


>
>
> What platforms beyond POSIXish and Windows need to be considered? Where in
> the standard is that documented?
>
> Historically both C and C++ have taken the view that only POSIX need be
considered. But it's been changing, the Filesystem TS goes far out of its
way to accommodate Windows without saying so explicitly except in
footnotes.

I'd start with int fd's and go from there. Your review of existing practice
is what will persuade that your design is reasonable, and I'm afraid that's
just donkey work of reading lots of documentation and summarising into your
proposal with lists of URLs to the source references.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2f3aa6c7-e30c-4a9b-aa07-b1ae0eb329a8%40isocpp.org.

------=_Part_421_446042180.1502331848032
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>What platforms beyond POSIXish and Windows need to be consider=
ed? Where in the standard is that documented?<br><br></div></div></blockquo=
te><div>Historically both C and C++ have taken the view that only POSIX nee=
d be considered. But it&#39;s been changing, the Filesystem TS goes far out=
 of its way to accommodate Windows without saying so explicitly except in f=
ootnotes.=C2=A0</div><div><br></div><div>I&#39;d start with int fd&#39;s an=
d go from there. Your review of existing practice is what will persuade tha=
t your design is reasonable, and I&#39;m afraid that&#39;s just donkey work=
 of reading lots of documentation and summarising into your proposal with l=
ists of URLs to the source references.</div><div><br></div><div>Niall</div>=
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2f3aa6c7-e30c-4a9b-aa07-b1ae0eb329a8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2f3aa6c7-e30c-4a9b-aa07-b1ae0eb329a8=
%40isocpp.org</a>.<br />

------=_Part_421_446042180.1502331848032--

------=_Part_420_1313606664.1502331848032--

.

------=_Part_487_1125470491.1502335942406
Content-Type: multipart/alternative;
 boundary="----=_Part_488_54050944.1502335942406"

------=_Part_488_54050944.1502335942406
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 9, 2017 at 10:24:08 PM UTC-4, Niall Douglas wrote:
>
>
>> What platforms beyond POSIXish and Windows need to be considered? Where
>> in the standard is that documented?
>>
>> Historically both C and C++ have taken the view that only POSIX need be
> considered.
>

.... they have? I don't recall any specific parts of those standards that
were non-POSIX-hostile. Indeed, the fact that `wchar_t` exists at all (and
is implementation-defined), rather than keeping to the POSIX assumption of
byte-sized `char`s suggests quite a lot of consideration of non-POSIX
systems.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ad21fb55-e188-4126-a5ac-d964ae5ad7c3%40isocpp.org.

------=_Part_488_54050944.1502335942406
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, August 9, 2017 at 10:24:08 PM UTC-4, Niall D=
ouglas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>What plat=
forms beyond POSIXish and Windows need to be considered? Where in the stand=
ard is that documented?<br><br></div></div></blockquote><div>Historically b=
oth C and C++ have taken the view that only POSIX need be considered.</div>=
</div></blockquote><div><br>... they have? I don&#39;t recall any specific =
parts of those standards that were non-POSIX-hostile. Indeed, the fact that=
 `wchar_t` exists at all (and is implementation-defined), rather than keepi=
ng to the POSIX assumption of byte-sized `char`s suggests quite a lot of co=
nsideration of non-POSIX systems.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ad21fb55-e188-4126-a5ac-d964ae5ad7c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad21fb55-e188-4126-a5ac-d964ae5ad7c3=
%40isocpp.org</a>.<br />

------=_Part_488_54050944.1502335942406--

------=_Part_487_1125470491.1502335942406--

.

------=_Part_462_26370131.1502337489150
Content-Type: multipart/alternative;
 boundary="----=_Part_463_2025665212.1502337489150"

------=_Part_463_2025665212.1502337489150
Content-Type: text/plain; charset="UTF-8"


>
>
>>>
>>> Historically both C and C++ have taken the view that only POSIX need be
>> considered.
>>
>
> ... they have? I don't recall any specific parts of those standards that
> were non-POSIX-hostile.
>

There's a fair chunk of the C standard which was painful/impossible to
implement on Windows, even up to the C11 standard.


> Indeed, the fact that `wchar_t` exists at all (and is
> implementation-defined), rather than keeping to the POSIX assumption of
> byte-sized `char`s suggests quite a lot of consideration of non-POSIX
> systems.
>

wchar_t is widely used by Java, Python, lots of other stuff besides Windows.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1dbff718-7d0a-4f15-ba76-3932c0177690%40isocpp.org.

------=_Part_463_2025665212.1502337489150
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div><br><br></div></div></block=
quote><div>Historically both C and C++ have taken the view that only POSIX =
need be considered.</div></div></blockquote><div><br>... they have? I don&#=
39;t recall any specific parts of those standards that were non-POSIX-hosti=
le.</div></div></blockquote><div><br></div><div>There&#39;s a fair chunk of=
 the C standard which was painful/impossible to implement on Windows, even =
up to the C11 standard.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div> Indeed, the fact that `wchar_t` exis=
ts at all (and is implementation-defined), rather than keeping to the POSIX=
 assumption of byte-sized `char`s suggests quite a lot of consideration of =
non-POSIX systems.<br></div></div></blockquote><div><br></div><div>wchar_t =
is widely used by Java, Python, lots of other stuff besides Windows.</div><=
div><br></div><div>Niall=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1dbff718-7d0a-4f15-ba76-3932c0177690%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1dbff718-7d0a-4f15-ba76-3932c0177690=
%40isocpp.org</a>.<br />

------=_Part_463_2025665212.1502337489150--

------=_Part_462_26370131.1502337489150--

.

------=_Part_2827_952806160.1502505041893
Content-Type: multipart/alternative;
 boundary="----=_Part_2828_755335263.1502505041894"

------=_Part_2828_755335263.1502505041894
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 9, 2017 at 8:32:22 PM UTC-7, Nicol Bolas wrote:
>
> On Wednesday, August 9, 2017 at 10:24:08 PM UTC-4, Niall Douglas wrote:
>>
>>
>>> What platforms beyond POSIXish and Windows need to be considered? Where
>>> in the standard is that documented?
>>>
>>> Historically both C and C++ have taken the view that only POSIX need be
>> considered.
>>
>
> ... they have? I don't recall any specific parts of those standards that
> were non-POSIX-hostile. Indeed, the fact that `wchar_t` exists at all (and
> is implementation-defined), rather than keeping to the POSIX assumption of
> byte-sized `char`s suggests quite a lot of consideration of non-POSIX
> systems.
>

^^^ This.  Windows isn't really any more difficult to implement C on than
any other general-purpose operating system.  Probably the weirdest stuff
for Windows would involve stdio's handling of text versus binary files,
which among the popular systems only matters on Windows.

Anyway...

A problem that I see here is that the definition of "native file handle" on
Windows isn't straightforward like it is in the POSIX world.  Microsoft
uses *two* underlying file handles for each FILE or basic_filebuf: the
POSIX-like file number, and the Win32 file handle.

In Windows, something to keep in mind is that the C language isn't
hardwired into the user-mode interface to the operating system.  The POSIX
world tends to have libc as where the kernel system call interfaces are
located, whereas Windows separates the concepts of C runtime and the kernel
interface.  Applications are supposed to provide their own C runtime if one
is needed.

Microsoft's C design implements some of the POSIX file functions within the
C runtime library, not within the operating system.  Microsoft's open()
returns an int, but this int is simply an index into internal tables within
the C runtime library you're using.  This table contains, among other
things, the mapping to the Win32 file handle.  The Win32 file handle is the
true native file handle, usually.  (There is a corner case to this I won't
go into.)  The Win32 file handle is nominally of type HANDLE, which is just
a typedef for void *.

MinGW uses the Microsoft C runtime for the most part.  (It should have
provided its own C runtime, given the "rules" of Windows, but it doesn't.
See https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 )

So I ask: which "native file handle" should such an API return on Windows?

Melissa

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3a244247-f18f-457e-a0e9-2783effb62a6%40isocpp.org.

------=_Part_2828_755335263.1502505041894
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, August 9, 2017 at 8:32:22 PM UTC-7, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On =
Wednesday, August 9, 2017 at 10:24:08 PM UTC-4, Niall Douglas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><br>What platforms beyond POSIXish and=
 Windows need to be considered? Where in the standard is that documented?<b=
r><br></div></div></blockquote><div>Historically both C and C++ have taken =
the view that only POSIX need be considered.</div></div></blockquote><div><=
br>... they have? I don&#39;t recall any specific parts of those standards =
that were non-POSIX-hostile. Indeed, the fact that `wchar_t` exists at all =
(and is implementation-defined), rather than keeping to the POSIX assumptio=
n of byte-sized `char`s suggests quite a lot of consideration of non-POSIX =
systems.<br></div></div></blockquote><div><br>^^^ This.=C2=A0 Windows isn&#=
39;t really any more difficult to implement C on than any other general-pur=
pose operating system.=C2=A0 Probably the weirdest stuff for Windows would =
involve stdio&#39;s handling of text versus binary files, which among the p=
opular systems only matters on Windows.<br><br>Anyway...<br><br>A problem t=
hat I see here is that the definition of &quot;native file handle&quot; on =
Windows isn&#39;t straightforward like it is in the POSIX world.=C2=A0 Micr=
osoft uses <i>two</i> underlying file handles for each FILE or basic_filebu=
f: the POSIX-like file number, and the Win32 file handle.<br><br>In Windows=
, something to keep in mind is that the C language isn&#39;t=20
hardwired into the user-mode interface to the operating system.=C2=A0 The=
=20
POSIX world tends to have libc as where the kernel system call=20
interfaces are located, whereas Windows separates the concepts of C=20
runtime and the kernel interface.=C2=A0 Applications are supposed to provid=
e their own C runtime if one is needed.<br><br>Microsoft&#39;s C design imp=
lements some of the POSIX file functions within the C runtime library, not =
within the operating system.=C2=A0 Microsoft&#39;s open() returns an int, b=
ut this int is simply an index into internal tables within the C runtime li=
brary you&#39;re using.=C2=A0 This table contains, among other things, the =
mapping to the Win32 file handle.=C2=A0 The Win32 file handle is the true n=
ative file handle, usually.=C2=A0 (There is a corner case to this I won&#39=
;t go into.)=C2=A0 The Win32 file handle is nominally of type HANDLE, which=
 is just a typedef for void *.<br><br>MinGW uses the Microsoft C runtime fo=
r the most part.=C2=A0 (It should have provided its own C runtime, given th=
e &quot;rules&quot; of Windows, but it doesn&#39;t.=C2=A0 See https://blogs=
..msdn.microsoft.com/oldnewthing/20140411-00/?p=3D1273 )<br><br>So I ask: wh=
ich &quot;native file handle&quot; should such an API return on Windows?<br=
><br>Melissa<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3a244247-f18f-457e-a0e9-2783effb62a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a244247-f18f-457e-a0e9-2783effb62a6=
%40isocpp.org</a>.<br />

------=_Part_2828_755335263.1502505041894--

------=_Part_2827_952806160.1502505041893--

.

------=_Part_2796_321444742.1502524381632
Content-Type: multipart/alternative;
 boundary="----=_Part_2797_56595720.1502524381633"

------=_Part_2797_56595720.1502524381633
Content-Type: text/plain; charset="UTF-8"



On Saturday, 12 August 2017 03:30:42 UTC+1, Myriachan wrote:
>
> On Wednesday, August 9, 2017 at 8:32:22 PM UTC-7, Nicol Bolas wrote:
>>
>> On Wednesday, August 9, 2017 at 10:24:08 PM UTC-4, Niall Douglas wrote:
>>>
>>>
>>>> What platforms beyond POSIXish and Windows need to be considered? Where
>>>> in the standard is that documented?
>>>>
>>>> Historically both C and C++ have taken the view that only POSIX need be
>>> considered.
>>>
>>
>> ... they have? I don't recall any specific parts of those standards that
>> were non-POSIX-hostile. Indeed, the fact that `wchar_t` exists at all (and
>> is implementation-defined), rather than keeping to the POSIX assumption of
>> byte-sized `char`s suggests quite a lot of consideration of non-POSIX
>> systems.
>>
>
> ^^^ This.  Windows isn't really any more difficult to implement C on than
> any other general-purpose operating system.  Probably the weirdest stuff
> for Windows would involve stdio's handling of text versus binary files,
> which among the popular systems only matters on Windows.
>
> Anyway...
>
> A problem that I see here is that the definition of "native file handle"
> on Windows isn't straightforward like it is in the POSIX world.  Microsoft
> uses *two* underlying file handles for each FILE or basic_filebuf: the
> POSIX-like file number, and the Win32 file handle.
>
> In Windows, something to keep in mind is that the C language isn't
> hardwired into the user-mode interface to the operating system.  The POSIX
> world tends to have libc as where the kernel system call interfaces are
> located, whereas Windows separates the concepts of C runtime and the kernel
> interface.  Applications are supposed to provide their own C runtime if one
> is needed.
>
> Microsoft's C design implements some of the POSIX file functions within
> the C runtime library, not within the operating system.  Microsoft's open()
> returns an int, but this int is simply an index into internal tables within
> the C runtime library you're using.  This table contains, among other
> things, the mapping to the Win32 file handle.  The Win32 file handle is the
> true native file handle, usually.  (There is a corner case to this I won't
> go into.)  The Win32 file handle is nominally of type HANDLE, which is just
> a typedef for void *.
>
> MinGW uses the Microsoft C runtime for the most part.  (It should have
> provided its own C runtime, given the "rules" of Windows, but it doesn't.
> See https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 )
>
> So I ask: which "native file handle" should such an API return on Windows?
>
> Melissa
>

I would say its implementation defined. The minimum interface would be to
allow access to a mostly opaque from the C++ standards point of view (but
not from the implementations point of view) file descriptor type. I would
like to have the standard recognise _POSIX_C_SOURCE
(http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html)
and then mandate that it contains a FD that can be used with fcntl etc. If
we follow the reasoning that one of the important use cases is locking
files then on windows it should contain a HANDLE as that is what the
LockFile() and LockFileEx() functions of win32 take. You can't mandate that
in the standard though unless you also make it recognise Windows and give
it special treatment. I'm assuming you can't define _POSIX_C_SOURCE in
windows so please correct me if I'm wrong.
For arguments sake though why shouldn't FILE* and HANDLE=void* be used
interchangeably? We could require the file descriptor struct contains a
pointer which on Posix is a FILE* and on windows is a HANDLE. You can get
the integer FD on Posix using fileno(). In fact why not go further and have
the opaque file descriptor just be a pointer which is FILE* if
_POSIX_C_SOURCE is defined and HANDLE=void* on Windows. What would that
break and what limits would it impose?
Bruce.




--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b7572ede-bcee-4089-b70a-622d08fa9b6d%40isocpp.org.

------=_Part_2797_56595720.1502524381633
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, 12 August 2017 03:30:42 UTC+1, Myriac=
han  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
 Wednesday, August 9, 2017 at 8:32:22 PM UTC-7, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, August 9, 201=
7 at 10:24:08 PM UTC-4, Niall Douglas wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><br>What platforms beyond POSIXish and Windows need to be con=
sidered? Where in the standard is that documented?<br><br></div></div></blo=
ckquote><div>Historically both C and C++ have taken the view that only POSI=
X need be considered.</div></div></blockquote><div><br>... they have? I don=
&#39;t recall any specific parts of those standards that were non-POSIX-hos=
tile. Indeed, the fact that `wchar_t` exists at all (and is implementation-=
defined), rather than keeping to the POSIX assumption of byte-sized `char`s=
 suggests quite a lot of consideration of non-POSIX systems.<br></div></div=
></blockquote><div><br>^^^ This.=C2=A0 Windows isn&#39;t really any more di=
fficult to implement C on than any other general-purpose operating system.=
=C2=A0 Probably the weirdest stuff for Windows would involve stdio&#39;s ha=
ndling of text versus binary files, which among the popular systems only ma=
tters on Windows.<br><br>Anyway...<br><br>A problem that I see here is that=
 the definition of &quot;native file handle&quot; on Windows isn&#39;t stra=
ightforward like it is in the POSIX world.=C2=A0 Microsoft uses <i>two</i> =
underlying file handles for each FILE or basic_filebuf: the POSIX-like file=
 number, and the Win32 file handle.<br><br>In Windows, something to keep in=
 mind is that the C language isn&#39;t=20
hardwired into the user-mode interface to the operating system.=C2=A0 The=
=20
POSIX world tends to have libc as where the kernel system call=20
interfaces are located, whereas Windows separates the concepts of C=20
runtime and the kernel interface.=C2=A0 Applications are supposed to provid=
e their own C runtime if one is needed.<br><br>Microsoft&#39;s C design imp=
lements some of the POSIX file functions within the C runtime library, not =
within the operating system.=C2=A0 Microsoft&#39;s open() returns an int, b=
ut this int is simply an index into internal tables within the C runtime li=
brary you&#39;re using.=C2=A0 This table contains, among other things, the =
mapping to the Win32 file handle.=C2=A0 The Win32 file handle is the true n=
ative file handle, usually.=C2=A0 (There is a corner case to this I won&#39=
;t go into.)=C2=A0 The Win32 file handle is nominally of type HANDLE, which=
 is just a typedef for void *.<br><br>MinGW uses the Microsoft C runtime fo=
r the most part.=C2=A0 (It should have provided its own C runtime, given th=
e &quot;rules&quot; of Windows, but it doesn&#39;t.=C2=A0 See <a href=3D"ht=
tps://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=3D1273" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fblogs.msdn.microsoft.com%2Foldnewthing%2F20140=
411-00%2F%3Fp%3D1273\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH-MfY0aFvT4GRC=
lbQB8cBl2wjEtA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.g=
oogle.com/url?q\x3dhttps%3A%2F%2Fblogs.msdn.microsoft.com%2Foldnewthing%2F2=
0140411-00%2F%3Fp%3D1273\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH-MfY0aFvT=
4GRClbQB8cBl2wjEtA&#39;;return true;">https://blogs.msdn.microsoft.<wbr>com=
/oldnewthing/20140411-00/?<wbr>p=3D1273</a> )<br><br>So I ask: which &quot;=
native file handle&quot; should such an API return on Windows?<br><br>Melis=
sa<br></div></div></blockquote><div><br><h1 class=3D"title">I would say its=
 implementation defined. The minimum interface would be to allow access to =
a mostly opaque from the C++ standards point of view (but not from the impl=
ementations point of view) file descriptor type. I would like to have the s=
tandard recognise _POSIX_C_SOURCE (http://pubs.opengroup.org/onlinepubs/007=
904975/functions/xsh_chap02_02.html) and then mandate that it contains a FD=
 that can be used with fcntl etc. If we follow the reasoning that one of th=
e important use cases is locking files then on windows it should contain a =
HANDLE as that is what the LockFile() and LockFileEx() functions of win32 t=
ake. You can&#39;t mandate that in the standard though unless you also make=
 it recognise Windows and give it special treatment. I&#39;m assuming you c=
an&#39;t define _POSIX_C_SOURCE in windows so please correct me if I&#39;m =
wrong.</h1><h1 class=3D"title"><br></h1><h1 class=3D"title">For arguments s=
ake though why shouldn&#39;t FILE* and HANDLE=3Dvoid* be used interchangeab=
ly? We could require the file descriptor struct contains a pointer which on=
 Posix is a FILE* and on windows is a HANDLE. You can get the integer FD on=
 Posix using fileno(). In fact why not go further and have the opaque file =
descriptor just be a pointer which is FILE* if _POSIX_C_SOURCE is defined a=
nd HANDLE=3Dvoid* on Windows. What would that break and what limits would i=
t impose?</h1><h1 class=3D"title"><br></h1><h1 class=3D"title">Bruce.<br></=
h1><p><br></p>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b7572ede-bcee-4089-b70a-622d08fa9b6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b7572ede-bcee-4089-b70a-622d08fa9b6d=
%40isocpp.org</a>.<br />

------=_Part_2797_56595720.1502524381633--

------=_Part_2796_321444742.1502524381632--

.

------=_Part_3220_1744452289.1502551672575
Content-Type: multipart/alternative;
 boundary="----=_Part_3221_570518144.1502551672575"

------=_Part_3221_570518144.1502551672575
Content-Type: text/plain; charset="UTF-8"


>
>
> For arguments sake though why shouldn't FILE* and HANDLE=void* be used
> interchangeably? We could require the file descriptor struct contains a
> pointer which on Posix is a FILE* and on windows is a HANDLE. You can get
> the integer FD on Posix using fileno(). In fact why not go further and have
> the opaque file descriptor just be a pointer which is FILE* if
> _POSIX_C_SOURCE is defined and HANDLE=void* on Windows. What would that
> break and what limits would it impose?
>
You may also wish to retrieve the underlying FILE * on Windows.

Also you can't assume HANDLE = void *. If you turn on strict type checking
in windows.h, it won't be.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/687c5b8e-69e4-4239-a4ba-22457041baf4%40isocpp.org.

------=_Part_3221_570518144.1502551672575
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><h1><br></h1><h1>For arguments sake though why shouldn&#39;t FILE*=
 and HANDLE=3Dvoid* be used interchangeably? We could require the file desc=
riptor struct contains a pointer which on Posix is a FILE* and on windows i=
s a HANDLE. You can get the integer FD on Posix using fileno(). In fact why=
 not go further and have the opaque file descriptor just be a pointer which=
 is FILE* if _POSIX_C_SOURCE is defined and HANDLE=3Dvoid* on Windows. What=
 would that break and what limits would it impose?</h1><h1><br></h1></div><=
/div></blockquote><div>You may also wish to retrieve the underlying FILE * =
on Windows.</div><div><br></div><div>Also you can&#39;t assume HANDLE =3D v=
oid *. If you turn on strict type checking in windows.h, it won&#39;t be.</=
div><div><br></div><div>Niall=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/687c5b8e-69e4-4239-a4ba-22457041baf4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/687c5b8e-69e4-4239-a4ba-22457041baf4=
%40isocpp.org</a>.<br />

------=_Part_3221_570518144.1502551672575--

------=_Part_3220_1744452289.1502551672575--

.

On 12 Aug 2017, at 16:27, Niall Douglas <nialldouglas14@gmail.com> wrote:
> You may also wish to retrieve the underlying FILE * on Windows.
>=20
> Also you can't assume HANDLE =3D void *. If you turn on strict type check=
ing in windows.h, it won't be.

Note that the implicit assumption that basic_filebuf has to be implemented =
in terms of FILE* is wrong! Despite the description of the standard definin=
g behavior in terms of <stdio.h> there is no mandate that it is implemented=
 that way. I know that Plauger's *choice* was to do so but other choices ar=
e possible and are arguably more reasonable.

My implementation certainly travels in terms of file descriptors (I never r=
eally cared about Windows). Using a FILE* would imply that either filebuf r=
eally is a FILE (i.e., the buffers are conflated, that's the libstdc++ choi=
ce when based on glibc as far as I know) or that independent buffers are us=
ed making file streams noticably slower. On POSIX it is common that a FILE*=
 can be constructed from a file descriptor. If I had to create a FILE* from=
 a stream it could be done but the underlying buffering data structures wou=
ld be entirely separate.

If there should be access to some underlying structure I'd argue against an=
ything which proposes something different than access to a native handle. T=
hat would be a non-owning representation of a possibly implement defined ty=
pe (rather than an unspecified type). An implement would then chiise what t=
o return: a file descriptor, a FILE*, a HANDLE, or whatever else it sees fi=
t.

If users want to use something different I think they are best off just cre=
ating their own stream buffer in term of whatever file access they see fit.=
 We shouldn't waste much time on a fairly niche requirement and we shall ce=
rtainly not impose any constraints limiting implementation freedom for some=
thing like that! Streams are user-extensible and there is no need to put ev=
erything into them. That is quite different to FILE* based operations which=
 are not user extensible.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/AA817B4A-DB7D-445F-A7B7-EC5BA2F56F78%40gmail.com=
..

.

------=_Part_4393_268821506.1502667564372
Content-Type: multipart/alternative;
 boundary="----=_Part_4394_519313486.1502667564373"

------=_Part_4394_519313486.1502667564373
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Saturday, 12 August 2017 18:27:48 UTC+1, Dietmar K=C3=BChl wrote:
>
> On 12 Aug 2017, at 16:27, Niall Douglas <nialldo...@gmail.com=20
> <javascript:>> wrote:=20
> > You may also wish to retrieve the underlying FILE * on Windows.=20
> >=20
> > Also you can't assume HANDLE =3D void *. If you turn on strict type=20
> checking in windows.h, it won't be.=20
>
> Note that the implicit assumption that basic_filebuf has to be implemente=
d=20
> in terms of FILE* is wrong! Despite the description of the standard=20
> defining behavior in terms of <stdio.h> there is no mandate that it is=20
> implemented that way. I know that Plauger's *choice* was to do so but oth=
er=20
> choices are possible and are arguably more reasonable.=20
>
> I didn't think there was any such assumption (not from me anyway) but let=
s=20
make it explicit that there isn't just to be sure.
=20

> My implementation certainly travels in terms of file descriptors (I never=
=20
> really cared about Windows). Using a FILE* would imply that either filebu=
f=20
> really is a FILE (i.e., the buffers are conflated, that's the libstdc++=
=20
> choice when based on glibc as far as I know) or that independent buffers=
=20
> are used making file streams noticably slower. On POSIX it is common that=
 a=20
> FILE* can be constructed from a file descriptor. If I had to create a FIL=
E*=20
> from a stream it could be done but the underlying buffering data structur=
es=20
> would be entirely separate.=20
>
> If there should be access to some underlying structure I'd argue against=
=20
> anything which proposes something different than access to a native handl=
e.=20
> That would be a non-owning representation of a possibly implement defined=
=20
> type (rather than an unspecified type). An implement would then chiise wh=
at=20
> to return: a file descriptor, a FILE*, a HANDLE, or whatever else it sees=
=20
> fit.=20
>
> If users want to use something different I think they are best off just=
=20
> creating their own stream buffer in term of whatever file access they see=
=20
> fit. We shouldn't waste much time on a fairly niche requirement and we=20
> shall certainly not impose any constraints limiting implementation freedo=
m=20
> for something like that! Streams are user-extensible and there is no need=
=20
> to put everything into them. That is quite different to FILE* based=20
> operations which are not user extensible.



This seems to have come full circle. Let's try and summarise where we are:

Requirement:

* A streambuf for reading and writing a file:
* which has an additional constructor based on a file descriptor of some=20
kind
* and which provides a member function to obtain that descriptor

On a Posix system there needs to be a way of converting the descriptor=20
returned into an integer FD so that functions like fcntl can be invoked.

This requirement must not over constrain the implementation of std::filebuf=
..
If there is any indication of that it should be met by a new derived class=
=20
of streambuf rather than by altering std::filebuf

Two suggestions were given for new streambuf derivatives very similar to=20
filebuf:
* stdio_filebuf - based on a FILE*
* native_filebuf - based on a native file handle

Aside from the type given to the "file descriptor" based constructor and=20
the "file descriptor" getter,
these are identical to each other and to std::filebuf as it is now.

What justification is there for having both a stdio_filebuf and a=20
native_filebuf?

What justification is there for std::filebuf not being the same as=20
native_filebuf?

We have justification that std::filebuf must not be a stdio_filebuf as this=
=20
would constrain implementations too much.

---

I don't see a strong need for stdio_filebuf on a POSIX system.
Assuming native_filebuf is based on a wrapped file descriptor you can=20
construct a native_filebuf from a FILE* using fileno() to get a naked file=
=20
descriptor
which you can then wrap and pass to a native_filebuf.

If std::filebuf is a native_filebuf you can retrieve the FD as required. On=
=20
Posix you can unwrap the naked file descriptor to access fcntl() etc.
If you need to you can (try to) convert it into a FILE* using fdopen().

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a29e059a-bbd9-4ec3-ad7b-5a19b967fb8d%40isocpp.or=
g.

------=_Part_4394_519313486.1502667564373
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, 12 August 2017 18:27:48 UTC+1, Dietma=
r K=C3=BChl  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12 Aug 2=
017, at 16:27, Niall Douglas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"TTqAKY8fCAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">nialldo...@gmail.com</a>&gt; wrote:
<br>&gt; You may also wish to retrieve the underlying FILE * on Windows.
<br>&gt;=20
<br>&gt; Also you can&#39;t assume HANDLE =3D void *. If you turn on strict=
 type checking in windows.h, it won&#39;t be.
<br>
<br>Note that the implicit assumption that basic_filebuf has to be implemen=
ted in terms of FILE* is wrong! Despite the description of the standard def=
ining behavior in terms of &lt;stdio.h&gt; there is no mandate that it is i=
mplemented that way. I know that Plauger&#39;s *choice* was to do so but ot=
her choices are possible and are arguably more reasonable.
<br>
<br></blockquote><div>I didn&#39;t think there was any such assumption (not=
 from me anyway) but lets make it explicit that there isn&#39;t just to be =
sure.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">My im=
plementation certainly travels in terms of file descriptors (I never really=
 cared about Windows). Using a FILE* would imply that either filebuf really=
 is a FILE (i.e., the buffers are conflated, that&#39;s the libstdc++ choic=
e when based on glibc as far as I know) or that independent buffers are use=
d making file streams noticably slower. On POSIX it is common that a FILE* =
can be constructed from a file descriptor. If I had to create a FILE* from =
a stream it could be done but the underlying buffering data structures woul=
d be entirely separate.
<br>
<br>If there should be access to some underlying structure I&#39;d argue ag=
ainst anything which proposes something different than access to a native h=
andle. That would be a non-owning representation of a possibly implement de=
fined type (rather than an unspecified type). An implement would then chiis=
e what to return: a file descriptor, a FILE*, a HANDLE, or whatever else it=
 sees fit.
<br>
<br>If users want to use something different I think they are best off just=
 creating their own stream buffer in term of whatever file access they see =
fit. We shouldn&#39;t waste much time on a fairly niche requirement and we =
shall certainly not impose any constraints limiting implementation freedom =
for something like that! Streams are user-extensible and there is no need t=
o put everything into them. That is quite different to FILE* based operatio=
ns which are not user extensible.</blockquote><div><br><br>This seems to ha=
ve come full circle. Let&#39;s try and summarise where we are:<br><br>Requi=
rement:<br><br>* A streambuf for reading and writing a file:<br>* which has=
 an additional constructor based on a file descriptor of some kind<br>* and=
 which provides a member function to obtain that descriptor<br><br>On a Pos=
ix system there needs to be a way of converting the descriptor returned int=
o an integer FD so that functions like fcntl can be invoked.<br><br>This re=
quirement must not over constrain the implementation of std::filebuf.<br>If=
 there is any indication of that it should be met by a new derived class of=
 streambuf rather than by altering std::filebuf<br><br>Two suggestions were=
 given for new streambuf derivatives very similar to filebuf:<br>* stdio_fi=
lebuf - based on a FILE*<br>* native_filebuf - based on a native file handl=
e<br><br>Aside from the type given to the &quot;file descriptor&quot; based=
 constructor and the &quot;file descriptor&quot; getter,<br>these are ident=
ical to each other and to std::filebuf as it is now.<br><br>What justificat=
ion is there for having both a stdio_filebuf and a native_filebuf?<br><br>W=
hat justification is there for std::filebuf not being the same as native_fi=
lebuf?<br><br>We have justification that std::filebuf must not be a stdio_f=
ilebuf as this would constrain implementations too much.<br><br>---<br><br>=
I don&#39;t see a strong need for stdio_filebuf on a POSIX system.<br>Assum=
ing native_filebuf is based on a wrapped file descriptor you can construct =
a native_filebuf from a FILE* using fileno() to get a naked file descriptor=
<br>which you can then wrap and pass to a native_filebuf.<br><br>If std::fi=
lebuf is a native_filebuf you can retrieve the FD as required. On Posix you=
 can unwrap the naked file descriptor to access fcntl() etc.<br>If you need=
 to you can (try to) convert it into a FILE* using fdopen().<br></div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a29e059a-bbd9-4ec3-ad7b-5a19b967fb8d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a29e059a-bbd9-4ec3-ad7b-5a19b967fb8d=
%40isocpp.org</a>.<br />

------=_Part_4394_519313486.1502667564373--

------=_Part_4393_268821506.1502667564372--

.

On 14 August 2017 at 02:39,  <tortoise741@gmail.com> wrote:
> What justification is there for having both a stdio_filebuf and a
> native_filebuf?

stdio_filebuf's API is completely portable. It doesn't use any
non-portable types.
native_filebuf does.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZGgfJuuCRcxAE9z3Hp1B-QdDhs06edAP3PB4h95WmSOA%40mail.gmail.com.

.

------=_Part_4843_2113268061.1502702784631
Content-Type: multipart/alternative;
 boundary="----=_Part_4844_582623057.1502702784632"

------=_Part_4844_582623057.1502702784632
Content-Type: text/plain; charset="UTF-8"



On Monday, 14 August 2017 05:47:53 UTC+1, Ville Voutilainen wrote:
>
> On 14 August 2017 at 02:39,  <torto...@gmail.com <javascript:>> wrote:
> > What justification is there for having both a stdio_filebuf and a
> > native_filebuf?
>
> stdio_filebuf's API is completely portable. It doesn't use any
> non-portable types.
> native_filebuf does.
>

Portability is not a justification for existence. There needs to be a use
for it as well.
It does allows you to trivially implement a conforming (but non optimal)
std::filestream  but of what use is that?
Does it give any useful guarantees beyond those for std::filebuf?
The only thing I can think of is synchronisation with C stdio, which might
allow the standard to drop sync_with_io() from elsewhere.

I've never quite understood the use for that myself.
I guess it would help if you wanted to use streams while accessing the same
file simultaneously from a C library
but that always sounded like a "bad thing" to me.

I note here http://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio
that it says:

  "By default, all eight standard C++ streams are synchronized with their
respective C streams."

That could imply cin, cout & cerr are filestreams based on stdio_filebuf
rather than native_filebuf. That sounds like it would be limiting (e.g.
performance wise).
You could allow setfilebuf() to switch the type from native_filebuf to
stdio_filebuf but I think that would be painful to implement.

So far the only 'non portable' part of native_filebuf is the file
descripter.
What is wrong with leaving that mostly implementation defined so that use
of that use that part of the API is non-portable?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/558a032e-a860-44a5-bfa0-9c08b79d56f4%40isocpp.org.

------=_Part_4844_582623057.1502702784632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 14 August 2017 05:47:53 UTC+1, Ville Vo=
utilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 August =
2017 at 02:39, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"rHPpgkCTCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">torto...@gmail.com</a>&gt; wrote:
<br>&gt; What justification is there for having both a stdio_filebuf and a
<br>&gt; native_filebuf?
<br>
<br>stdio_filebuf&#39;s API is completely portable. It doesn&#39;t use any
<br>non-portable types.
<br>native_filebuf does.
<br></blockquote><div><br>Portability is not a justification for existence.=
 There needs to be a use for it as well. <br>It does allows you to triviall=
y implement a conforming (but non optimal) std::filestream=C2=A0 but of wha=
t use is that?<br>Does it give any useful guarantees beyond those for std::=
filebuf? <br>The only thing I can think of is synchronisation with C stdio,=
 which might allow the standard to drop sync_with_io() from elsewhere.<br><=
br>I&#39;ve never quite understood the use for that myself. <br>I guess it =
would help if you wanted to use streams while accessing the same file simul=
taneously from a C library <br>but that always sounded like a &quot;bad thi=
ng&quot; to me.<br><br>I note here http://en.cppreference.com/w/cpp/io/ios_=
base/sync_with_stdio that it says:<br><p>=C2=A0 &quot;By default, all eight=
 standard C++ streams are synchronized with their respective C streams.&quo=
t;
</p><br>That could imply cin, cout &amp; cerr are filestreams based on stdi=
o_filebuf rather than native_filebuf. That sounds like it would be limiting=
 (e.g. performance wise).<br>You could allow setfilebuf() to switch the typ=
e from native_filebuf to stdio_filebuf but I think that would be painful to=
 implement.<br><br>So far the only &#39;non portable&#39; part of native_fi=
lebuf is the file descripter. <br>What is wrong with leaving that mostly im=
plementation defined so that use of that use that part of the API is non-po=
rtable?<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/558a032e-a860-44a5-bfa0-9c08b79d56f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/558a032e-a860-44a5-bfa0-9c08b79d56f4=
%40isocpp.org</a>.<br />

------=_Part_4844_582623057.1502702784632--

------=_Part_4843_2113268061.1502702784631--

.

------=_Part_4028_485991077.1502703065295
Content-Type: multipart/alternative;
 boundary="----=_Part_4029_2064471163.1502703065295"

------=_Part_4029_2064471163.1502703065295
Content-Type: text/plain; charset="UTF-8"



On Monday, 14 August 2017 10:26:24 UTC+1, torto...@gmail.com wrote:
>
>
>
> On Monday, 14 August 2017 05:47:53 UTC+1, Ville Voutilainen wrote:
>>
>> On 14 August 2017 at 02:39,  <torto...@gmail.com> wrote:
>> > What justification is there for having both a stdio_filebuf and a
>> > native_filebuf?
>>
>> stdio_filebuf's API is completely portable. It doesn't use any
>> non-portable types.
>> native_filebuf does.
>>
>
> Portability is not a justification for existence. There needs to be a use
> for it as well.
> It does allows you to trivially implement a conforming (but non optimal)
> std::filestream  but of what use is that?
> Does it give any useful guarantees beyond those for std::filebuf?
> The only thing I can think of is synchronisation with C stdio, which might
> allow the standard to drop sync_with_io() from elsewhere.
>
> I've never quite understood the use for that myself.
> I guess it would help if you wanted to use streams while accessing the
> same file simultaneously from a C library
> but that always sounded like a "bad thing" to me.
>
> I note here http://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio
> that it says:
>
>   "By default, all eight standard C++ streams are synchronized with their
> respective C streams."
>
> That could imply cin, cout & cerr are filestreams based on stdio_filebuf
> rather than native_filebuf. That sounds like it would be limiting (e.g.
> performance wise).
> You could allow setfilebuf() to switch the type from native_filebuf to
> stdio_filebuf but I think that would be painful to implement.
>
> So far the only 'non portable' part of native_filebuf is the file
> descripter.
> What is wrong with leaving that mostly implementation defined so that use
> of that use that part of the API is non-portable?
>
>
Incidentally can't you implement sync_with_stdio() by just calling fsync()
on the native descriptor before each stream operation and flush() on the
stream after wards.
Is there some other trick that sync_with_stdio enables better performance?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dd9db4b9-05c2-4caf-8a47-a1fd581a1603%40isocpp.org.

------=_Part_4029_2064471163.1502703065295
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 14 August 2017 10:26:24 UTC+1, torto...=
@gmail.com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br>On Monday, 14 August 2017 05:47:53 UTC+1, Ville Voutilainen  w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">On 14 August 2017 at 02:39, =
=C2=A0&lt;<a rel=3D"nofollow">torto...@gmail.com</a>&gt; wrote:
<br>&gt; What justification is there for having both a stdio_filebuf and a
<br>&gt; native_filebuf?
<br>
<br>stdio_filebuf&#39;s API is completely portable. It doesn&#39;t use any
<br>non-portable types.
<br>native_filebuf does.
<br></blockquote><div><br>Portability is not a justification for existence.=
 There needs to be a use for it as well. <br>It does allows you to triviall=
y implement a conforming (but non optimal) std::filestream=C2=A0 but of wha=
t use is that?<br>Does it give any useful guarantees beyond those for std::=
filebuf? <br>The only thing I can think of is synchronisation with C stdio,=
 which might allow the standard to drop sync_with_io() from elsewhere.<br><=
br>I&#39;ve never quite understood the use for that myself. <br>I guess it =
would help if you wanted to use streams while accessing the same file simul=
taneously from a C library <br>but that always sounded like a &quot;bad thi=
ng&quot; to me.<br><br>I note here <a href=3D"http://en.cppreference.com/w/=
cpp/io/ios_base/sync_with_stdio" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cpp=
reference.com%2Fw%2Fcpp%2Fio%2Fios_base%2Fsync_with_stdio\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEZLslLGJ47lCfexcqskJ7G32OhLQ&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppr=
eference.com%2Fw%2Fcpp%2Fio%2Fios_base%2Fsync_with_stdio\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNEZLslLGJ47lCfexcqskJ7G32OhLQ&#39;;return true;">http:=
//en.cppreference.com/w/<wbr>cpp/io/ios_base/sync_with_<wbr>stdio</a> that =
it says:<br><p>=C2=A0 &quot;By default, all eight standard C++ streams are =
synchronized with their respective C streams.&quot;
</p><br>That could imply cin, cout &amp; cerr are filestreams based on stdi=
o_filebuf rather than native_filebuf. That sounds like it would be limiting=
 (e.g. performance wise).<br>You could allow setfilebuf() to switch the typ=
e from native_filebuf to stdio_filebuf but I think that would be painful to=
 implement.<br><br>So far the only &#39;non portable&#39; part of native_fi=
lebuf is the file descripter. <br>What is wrong with leaving that mostly im=
plementation defined so that use of that use that part of the API is non-po=
rtable?<br><br></div></div></blockquote><div><br>Incidentally can&#39;t you=
 implement sync_with_stdio() by just calling fsync() on the native descript=
or before each stream operation and flush() on the stream after wards.<br>I=
s there some other trick that sync_with_stdio enables better performance?<b=
r></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dd9db4b9-05c2-4caf-8a47-a1fd581a1603%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dd9db4b9-05c2-4caf-8a47-a1fd581a1603=
%40isocpp.org</a>.<br />

------=_Part_4029_2064471163.1502703065295--

------=_Part_4028_485991077.1502703065295--

.

On 14 August 2017 at 12:31,  <tortoise741@gmail.com> wrote:
>>> stdio_filebuf's API is completely portable. It doesn't use any
>>> non-portable types.
>>> native_filebuf does.
>>
>>
>> Portability is not a justification for existence. There needs to be a use
>> for it as well.

The use is C interoperability. Systems that have open FILE*s in flight
cannot wrap
them into iostreams, and then they end up using FILE* and stdio
everywhere, which
kinda blows. Another portability aspect here is that some library
vendors already
ship something like a stdio_filebuf as an extension, but those extensions aren't
agreed on by all vendors. Which is why I think we should standardize
stdio_filebuf.

>> It does allows you to trivially implement a conforming (but non optimal)
>> std::filestream  but of what use is that?

See above. The use of such a thing is C interoperability.

>> So far the only 'non portable' part of native_filebuf is the file
>> descripter.
>> What is wrong with leaving that mostly implementation defined so that use
>> of that use that part of the API is non-portable?

When I see a facility that I know contains no non-portable parts, I
know that I don't
need to worry about platform differences. When I see a facility that I
know contains
non-portable parts, I know that I need to worry about platform
differences. That's why
a) I don't want the native handles anywhere near std::filebuf b) I
don't want them
anywhere near std::stdio_filebuf. Sure, the native_handles in <thread>
et al. are done
differently, as part of the api of the portable thing. We don't need
to repeat that choice.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb1pErhf2Kec84HKFQovpoEj3ffv8p%3D3dxMxJUP7ZMQzg%40mail.gmail.com.

.

------=_Part_4857_328329487.1502720620519
Content-Type: multipart/alternative;
 boundary="----=_Part_4858_2103599039.1502720620519"

------=_Part_4858_2103599039.1502720620519
Content-Type: text/plain; charset="UTF-8"

On Monday, August 14, 2017 at 7:57:50 AM UTC-4, Ville Voutilainen wrote:
>
> On 14 August 2017 at 12:31,  <torto...@gmail.com <javascript:>> wrote:
> >> So far the only 'non portable' part of native_filebuf is the file
> >> descripter.
> >> What is wrong with leaving that mostly implementation defined so that
> use
> >> of that use that part of the API is non-portable?
>
> When I see a facility that I know contains no non-portable parts, I
> know that I don't
> need to worry about platform differences. When I see a facility that I
> know contains
> non-portable parts, I know that I need to worry about platform
> differences. That's why
> a) I don't want the native handles anywhere near std::filebuf b) I
> don't want them
> anywhere near std::stdio_filebuf. Sure, the native_handles in <thread>
> et al. are done
> differently, as part of the api of the portable thing. We don't need
> to repeat that choice.
>

I would add that I feel the enforced native-handle design makes a lot more
sense for `thread` than `filebuf`. `std::thread` is *intended* by the
specification to be the lowest-level portable wrapper around an OS thread.
`filebuf` is not; it's not even the *only* wrapper around OS file IO in the
standard, let alone the "lowest-level portable wrapper".

Another important difference: you cannot create a `std::thread` instance
from a `thread::native_handle_type`. You can only get the handle instance
from an existing `std::thread`, not the other way around. By contrast, I'd
say 90% of the point of these `*_filebuf` APIs is to be able to create an
iostream buffer from an existing handle.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0eb0d2ba-4963-444f-a6c8-33c2e6e62d87%40isocpp.org.

------=_Part_4858_2103599039.1502720620519
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 14, 2017 at 7:57:50 AM UTC-4, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 August 201=
7 at 12:31, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"YGyTv7aqCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">torto...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; So far the only &#39;non portable&#39; part of native_filebuf =
is the file
<br>&gt;&gt; descripter.
<br>&gt;&gt; What is wrong with leaving that mostly implementation defined =
so that use
<br>&gt;&gt; of that use that part of the API is non-portable?
<br>
<br>When I see a facility that I know contains no non-portable parts, I
<br>know that I don&#39;t
<br>need to worry about platform differences. When I see a facility that I
<br>know contains
<br>non-portable parts, I know that I need to worry about platform
<br>differences. That&#39;s why
<br>a) I don&#39;t want the native handles anywhere near std::filebuf b) I
<br>don&#39;t want them
<br>anywhere near std::stdio_filebuf. Sure, the native_handles in &lt;threa=
d&gt;
<br>et al. are done
<br>differently, as part of the api of the portable thing. We don&#39;t nee=
d
<br>to repeat that choice.
<br></blockquote><div><br>I would add that I feel the enforced native-handl=
e design makes a lot more sense for `thread` than `filebuf`. `std::thread` =
is <i>intended</i> by the specification to be the lowest-level portable wra=
pper around an OS thread. `filebuf` is not; it&#39;s not even the <i>only</=
i> wrapper around OS file IO in the standard, let alone the &quot;lowest-le=
vel portable wrapper&quot;.<br><br>Another important difference: you cannot=
 create a `std::thread` instance from a `thread::native_handle_type`. You c=
an only get the handle instance from an existing `std::thread`, not the oth=
er way around. By contrast, I&#39;d say 90% of the point of these `*_filebu=
f` APIs is to be able to create an iostream buffer from an existing handle.=
<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0eb0d2ba-4963-444f-a6c8-33c2e6e62d87%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0eb0d2ba-4963-444f-a6c8-33c2e6e62d87=
%40isocpp.org</a>.<br />

------=_Part_4858_2103599039.1502720620519--

------=_Part_4857_328329487.1502720620519--

.

On 14 August 2017 at 17:23, Nicol Bolas <jmckesson@gmail.com> wrote:
> from an existing `std::thread`, not the other way around. By contrast, I'd
> say 90% of the point of these `*_filebuf` APIs is to be able to create an
> iostream buffer from an existing handle.


Yes, absolutely for the ones I have suggested. It's perhaps a source
of confusion
that std::filebuf doesn't do that; it opens a file - whereas the
suggested new filebufs
would indeed most often be used on already-open files. That's an
important aspect
of the motivation for native_filebuf: there are many things that
open() can do that
we can't necessarily reasonably map into C++, especially not into portable code.
The motivation of stdio_filebuf is different, it's mostly for use
cases where some
other part of your code already gave you a FILE*. And at that point
it's too late
to go back to a descriptor since some things must be done at open(). Conversely,
getting a FILE* from a descriptor doesn't help, because we
specifically have a FILE*
at hand. That's why I think we need both.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbDpr9ovysyiaVsNVsXX0_yYMcKnmVb%2B2phLd%2Bm-5aW0w%40mail.gmail.com.

.

------=_Part_5172_124660517.1502728893095
Content-Type: multipart/alternative;
 boundary="----=_Part_5173_661325206.1502728893095"

------=_Part_5173_661325206.1502728893095
Content-Type: text/plain; charset="UTF-8"


>
>
>>
> Incidentally can't you implement sync_with_stdio() by just calling fsync()
> on the native descriptor before each stream operation and flush() on the
> stream after wards.
> Is there some other trick that sync_with_stdio enables better performance?
>

As much as I support the exposure of the underlying file handle for
iostreams, I do have to question the use cases:

1. Byte range locking has highly non-portable semantics, and is downright
dangerous to use on POSIX with iostreams. Any code using the underlying fd
for byte range locking on POSIX is probably incorrect.

2. fsync() generally does not do what people think it does, or what POSIX
says it must do, and that is an increasing problem with time rather than
decreasing i.e. fsync() is ever more becoming a partial or total noop on
more and more systems. Any code using fsync() is probably incorrect.

What other major use case is there for exposing the native file handle for
iostreams? I suppose maybe handing fds off to child processes. But that's
best implemented by you opening the fds by hand, configuring them, then
wrapping them into iostreams if needed.

That basically leaves twiddling the fd's flags e.g. turning on O_SYNC. But
many POSIX implementations don't permit O_SYNC to be changed after fd open.
So I'm kinda running out of valid use cases now.

I'm open to being corrected, but I've gotta wonder here, if someone wants
to poke the internals of iostreams, perhaps they should just not use
iostreams?

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e8bde0a5-5e5d-47b5-9e3a-0404ae25544b%40isocpp.org.

------=_Part_5173_661325206.1502728893095
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div=
></div></blockquote><div><br>Incidentally can&#39;t you implement sync_with=
_stdio() by just calling fsync() on the native descriptor before each strea=
m operation and flush() on the stream after wards.<br>Is there some other t=
rick that sync_with_stdio enables better performance?<br></div></div></bloc=
kquote><div><br></div><div>As much as I support the exposure of the underly=
ing file handle for iostreams, I do have to question the use cases:</div><d=
iv><br></div><div>1. Byte range locking has highly non-portable semantics, =
and is downright dangerous to use on POSIX with iostreams. Any code using t=
he underlying fd for byte range locking on POSIX is probably incorrect.</di=
v><div><br></div><div>2. fsync() generally does not do what people think it=
 does, or what POSIX says it must do, and that is an increasing problem wit=
h time rather than decreasing i.e. fsync() is ever more becoming a partial =
or total noop on more and more systems. Any code using fsync() is probably =
incorrect.</div><div><br></div><div>What other major use case is there for =
exposing the native file handle for iostreams? I suppose maybe handing fds =
off to child processes. But that&#39;s best implemented by you opening the =
fds by hand, configuring them, then wrapping them into iostreams if needed.=
</div><div><br></div><div>That basically leaves twiddling the fd&#39;s flag=
s e.g. turning on O_SYNC. But many POSIX implementations don&#39;t permit O=
_SYNC to be changed after fd open. So I&#39;m kinda running out of valid us=
e cases now.</div><div><br></div><div>I&#39;m open to being corrected, but =
I&#39;ve gotta wonder here, if someone wants to poke the internals of iostr=
eams, perhaps they should just not use iostreams?</div><div><br></div><div>=
Niall</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8bde0a5-5e5d-47b5-9e3a-0404ae25544b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8bde0a5-5e5d-47b5-9e3a-0404ae25544b=
%40isocpp.org</a>.<br />

------=_Part_5173_661325206.1502728893095--

------=_Part_5172_124660517.1502728893095--

.

On 14 August 2017 at 19:41, Niall Douglas <nialldouglas14@gmail.com> wrote:
> As much as I support the exposure of the underlying file handle for
> iostreams, I do have to question the use cases:
>
> 1. Byte range locking has highly non-portable semantics, and is downright
> dangerous to use on POSIX with iostreams. Any code using the underlying fd
> for byte range locking on POSIX is probably incorrect.
>
> 2. fsync() generally does not do what people think it does, or what POSIX
> says it must do, and that is an increasing problem with time rather than
> decreasing i.e. fsync() is ever more becoming a partial or total noop on
> more and more systems. Any code using fsync() is probably incorrect.
>
> What other major use case is there for exposing the native file handle for
> iostreams? I suppose maybe handing fds off to child processes. But that's
> best implemented by you opening the fds by hand, configuring them, then
> wrapping them into iostreams if needed.
>
> That basically leaves twiddling the fd's flags e.g. turning on O_SYNC. But
> many POSIX implementations don't permit O_SYNC to be changed after fd open.
> So I'm kinda running out of valid use cases now.
>
> I'm open to being corrected, but I've gotta wonder here, if someone wants to
> poke the internals of iostreams, perhaps they should just not use iostreams?


These are yet further reasons to leave iostreams' and filebuf's API
alone. It's not
generally sane to expose the underlying file descriptor at that level.
If you think it's
something to fiddle with, make sure you know that you're dealing with a filebuf
that is willing to expose the descriptor, cast down to that derived
filebuf and get
the descriptor from there.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaoovmUZr9C2SECD6i9-WzrzZ2Hoe0hdVTQWZ054VwprA%40mail.gmail.com.

.

------=_Part_5396_439337504.1502739434996
Content-Type: multipart/alternative;
 boundary="----=_Part_5397_1438059860.1502739434996"

------=_Part_5397_1438059860.1502739434996
Content-Type: text/plain; charset="UTF-8"



On Monday, 14 August 2017 18:50:03 UTC+1, Ville Voutilainen wrote:
>
> On 14 August 2017 at 19:41, Niall Douglas <nialldo...@gmail.com
> <javascript:>> wrote:
> > As much as I support the exposure of the underlying file handle for
> > iostreams, I do have to question the use cases:
> >
> > 1. Byte range locking has highly non-portable semantics, and is
> downright
> > dangerous to use on POSIX with iostreams. Any code using the underlying
> fd
> > for byte range locking on POSIX is probably incorrect.
> >

I think you mean non-portable rather than incorrect. I know of several
implementations that work correctly.
I would not trust them to work correctly on a different platform out of the
box or even a different file-system
on same platform. That doesn't make it a bad thing to do.
They can be made a little more portable with effort.

> 2. fsync() generally does not do what people think it does, or what POSIX
> > says it must do, and that is an increasing problem with time rather than
> > decreasing i.e. fsync() is ever more becoming a partial or total noop on
> > more and more systems. Any code using fsync() is probably incorrect.
> >
> > What other major use case is there for exposing the native file handle
> for
> > iostreams? I suppose maybe handing fds off to child processes. But
> that's
> > best implemented by you opening the fds by hand, configuring them, then
> > wrapping them into iostreams if needed.
> >
>

A pipe is exactly one of the other uses I would have in mind.
However, the semantics of pipe mean it must be an entirely separate class
from filebuf
(obviously as it isn't really a file).

> That basically leaves twiddling the fd's flags e.g. turning on O_SYNC.
But

> > many POSIX implementations don't permit O_SYNC to be changed after fd
> open.
> > So I'm kinda running out of valid use cases now.
> >
> > I'm open to being corrected, but I've gotta wonder here, if someone
> wants to
> > poke the internals of iostreams, perhaps they should just not use
> iostreams?
>
> It is a good thing to be able to use the same abstraction for different
kinds of I/O (provided it has compatible behaviour).
It always feels a little dirty to me when i have to drop down to C or Posix
APIs.
Typically the first thing I do is create wrappers to them (which is being
discussed on this thread
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/file$20locking/std-proposals/83tGrL1GhM4/fL9WnFYRiasJ)


>
> These are yet further reasons to leave iostreams' and filebuf's API
> alone. It's not
> generally sane to expose the underlying file descriptor at that level.
> If you think it's
> something to fiddle with, make sure you know that you're dealing with a
> filebuf
> that is willing to expose the descriptor, cast down to that derived
> filebuf and get
> the descriptor from there.
>

Are you suggesting it should be possible to cast from a filebuf to a
native_filebuf?
If they are really the same thing then requiring an explicit downcast to
native_filebuf isn't much more protection
from "here be dragons" than a similar warning on the method to retrieve the
native file descriptor.

If they are different? What is the significant difference? (in terms of
implementation or abstraction)

There was a remark earlier that filebuf is not the only interface to file
IO in C++.
The only other one I know of is cstdio. I don't really class that as 'C++'
anymore than I would another library with a C binding.
It is in the standard because compatibility with C is not only good but
essential.
I find the earlier arguments convincing that a stdio_buffer would be a good
thing to have.

So that just leaves the native_filebuf == filebuf question.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4b8345b9-13c5-47f1-80df-874e7a47c548%40isocpp.org.

------=_Part_5397_1438059860.1502739434996
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 14 August 2017 18:50:03 UTC+1, Ville Vo=
utilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 August =
2017 at 19:41, Niall Douglas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"1a8KCe-9CAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">nialldo...@gmail.com</a>&gt; wrote:
<br>&gt; As much as I support the exposure of the underlying file handle fo=
r
<br>&gt; iostreams, I do have to question the use cases:
<br>&gt;
<br>&gt; 1. Byte range locking has highly non-portable semantics, and is do=
wnright
<br>&gt; dangerous to use on POSIX with iostreams. Any code using the under=
lying fd
<br>&gt; for byte range locking on POSIX is probably incorrect.
<br>&gt;</blockquote><div>I think you mean non-portable rather than incorre=
ct. I know of several implementations that work correctly.<br>I would not t=
rust them to work correctly on a different platform out of the box or even =
a different file-system<br>on same platform. That doesn&#39;t make it a bad=
 thing to do. <br>They can be made a little more portable with effort.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; 2. fsync() gener=
ally does not do what people think it does, or what POSIX
<br>&gt; says it must do, and that is an increasing problem with time rathe=
r than
<br>&gt; decreasing i.e. fsync() is ever more becoming a partial or total n=
oop on
<br>&gt; more and more systems. Any code using fsync() is probably incorrec=
t.
<br>&gt;
<br>&gt; What other major use case is there for exposing the native file ha=
ndle for
<br>&gt; iostreams? I suppose maybe handing fds off to child processes. But=
 that&#39;s
<br>&gt; best implemented by you opening the fds by hand, configuring them,=
 then
<br>&gt; wrapping them into iostreams if needed.
<br>&gt;
<br></blockquote><div><br>A pipe is exactly one of the other uses I would h=
ave in mind. <br>However, the semantics of pipe mean it must be an entirely=
 separate class from filebuf<br>(obviously as it isn&#39;t really a file).<=
br>=C2=A0<br>&gt; That basically leaves twiddling the fd&#39;s flags e.g. t=
urning on O_SYNC. But
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; many POSIX impl=
ementations don&#39;t permit O_SYNC to be changed after fd open.
<br>&gt; So I&#39;m kinda running out of valid use cases now.
<br>&gt;
<br>&gt; I&#39;m open to being corrected, but I&#39;ve gotta wonder here, i=
f someone wants to
<br>&gt; poke the internals of iostreams, perhaps they should just not use =
iostreams?
<br>
<br></blockquote><div>It is a good thing to be able to use the same abstrac=
tion for different kinds of I/O (provided it has compatible behaviour).<br>=
It always feels a little dirty to me when i have to drop down to C or Posix=
 APIs.<br>Typically
 the first thing I do is create wrappers to them (which is being=20
discussed on this thread=20
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-prop=
osals/file$20locking/std-proposals/83tGrL1GhM4/fL9WnFYRiasJ)<br>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">
<br>These are yet further reasons to leave iostreams&#39; and filebuf&#39;s=
 API
<br>alone. It&#39;s not
<br>generally sane to expose the underlying file descriptor at that level.
<br>If you think it&#39;s
<br>something to fiddle with, make sure you know that you&#39;re dealing wi=
th a filebuf
<br>that is willing to expose the descriptor, cast down to that derived
<br>filebuf and get
<br>the descriptor from there.
<br></blockquote><div><br>Are you suggesting it should be possible to cast =
from a filebuf to a native_filebuf?<br>If they are really the same thing th=
en requiring an explicit downcast to native_filebuf isn&#39;t much more pro=
tection <br>from &quot;here be dragons&quot; than a similar warning on the =
method to retrieve the native file descriptor.<br><br>If they are different=
? What is the significant difference? (in terms of implementation or abstra=
ction)<br><br>There was a remark earlier that filebuf is not the only inter=
face to file IO in C++.<br>The only other one I know of is cstdio. I don&#3=
9;t really class that as &#39;C++&#39; anymore than I would another library=
 with a C binding.<br>It is in the standard because compatibility with C is=
 not only good but essential.<br>I find the earlier arguments convincing th=
at a stdio_buffer would be a good thing to have.<br><br>So that just leaves=
 the native_filebuf =3D=3D filebuf question.<br>=C2=A0<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4b8345b9-13c5-47f1-80df-874e7a47c548%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4b8345b9-13c5-47f1-80df-874e7a47c548=
%40isocpp.org</a>.<br />

------=_Part_5397_1438059860.1502739434996--

------=_Part_5396_439337504.1502739434996--

.

On 14 August 2017 at 22:37,  <tortoise741@gmail.com> wrote:
>> These are yet further reasons to leave iostreams' and filebuf's API
>> alone. It's not
>> generally sane to expose the underlying file descriptor at that level.
>> If you think it's
>> something to fiddle with, make sure you know that you're dealing with a
>> filebuf
>> that is willing to expose the descriptor, cast down to that derived
>> filebuf and get
>> the descriptor from there.
>
>
> Are you suggesting it should be possible to cast from a filebuf to a
> native_filebuf?

Perhaps it shouldn't. If native_filebuf derives from filebuf, the cast becomes
automatically possible because it's just a dynamic_cast.

> If they are really the same thing then requiring an explicit downcast to
> native_filebuf isn't much more protection
> from "here be dragons" than a similar warning on the method to retrieve the
> native file descriptor.

Sure, except that you need to know the target type and explicitly
downcast to it. Sure,
you can also use typeid to query what it really is. That doesn't mean
that filebuf
and native_filebuf are a same thing, and perhaps native_filebuf should
not derive
from filebuf but from streambuf.

> If they are different? What is the significant difference? (in terms of
> implementation or abstraction)

The significant difference is that native_filebuf has a file
descriptor API, whereas filebuf
does not.

> So that just leaves the native_filebuf == filebuf question.

That should evaluate to false, and perhaps even so that you can't cast
a filebuf to a native_filebuf,
i.e. they wouldn't have an inheritance relationship.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaPVUSN7zY9t3u0Y%3Du6vOrL3JBGy7UUddtBR%2BZosTapEQ%40mail.gmail.com.

.

------=_Part_5462_362788024.1502743058535
Content-Type: multipart/alternative;
 boundary="----=_Part_5463_956204098.1502743058536"

------=_Part_5463_956204098.1502743058536
Content-Type: text/plain; charset="UTF-8"

On Monday, August 14, 2017 at 3:37:15 PM UTC-4, Bruce Adams wrote:
>
> There was a remark earlier that filebuf is not the only interface to file
> IO in C++.
> The only other one I know of is cstdio. I don't really class that as 'C++'
> anymore than I would another library with a C binding.
> It is in the standard because compatibility with C is not only good but
> essential.
>

Too many C++ programmers use cstdio instead of iostreams for us to label it
as a for-compatibility-only feature. The availability of `fprintf` alone
makes it too useful of a feature for us to discount it as a thing for
compatibility.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07073785-31f0-42b9-bdd5-0d25fe92d29f%40isocpp.org.

------=_Part_5463_956204098.1502743058536
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 14, 2017 at 3:37:15 PM UTC-4, Bruce Adam=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
There was a remark earlier that filebuf is not the only interface to file I=
O in C++.<br>The only other one I know of is cstdio. I don&#39;t really cla=
ss that as &#39;C++&#39; anymore than I would another library with a C bind=
ing.<br>It is in the standard because compatibility with C is not only good=
 but essential.<br></div></div></blockquote><div><br>Too many C++ programme=
rs use cstdio instead of iostreams for us to label it as a for-compatibilit=
y-only feature. The availability of `fprintf` alone makes it too useful of =
a feature for us to discount it as a thing for compatibility.<br></div></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07073785-31f0-42b9-bdd5-0d25fe92d29f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07073785-31f0-42b9-bdd5-0d25fe92d29f=
%40isocpp.org</a>.<br />

------=_Part_5463_956204098.1502743058536--

------=_Part_5462_362788024.1502743058535--

.

------=_Part_5672_1992800009.1502744971840
Content-Type: multipart/alternative;
 boundary="----=_Part_5673_261008499.1502744971841"

------=_Part_5673_261008499.1502744971841
Content-Type: text/plain; charset="UTF-8"


>
>
>> >
>> > 1. Byte range locking has highly non-portable semantics, and is
>> downright
>> > dangerous to use on POSIX with iostreams. Any code using the underlying
>> fd
>> > for byte range locking on POSIX is probably incorrect.
>> >
>
> I think you mean non-portable rather than incorrect. I know of several
> implementations that work correctly.
>

No, I mean incorrect.

The byte range locking API is so severely broken in POSIX as to make it
impossible to write correct code with it.

It is possible to write correct code if and only if:

1. If you control all file descriptors in the entire process.

2. Files are never big.

3. Files are never on a network drive.

4. You don't care about pathological performance occurring (like, single
digit grants per second).

5. You don't use threads.

6. You don't care about power consumption.

7. You don't switch between shared and exclusive on non-identical ranges.

8. You never recurse into code which needs to take a lock whilst holding a
lock.

9. You can guarantee no third party is permuting the bit of filesystem you
are using.

But if you can meet all those conditions, then almost any other form of
synchronisation is better and faster. The sole thing which byte range locks
have which is useful is that they auto-release if the holding process
suddenly exits. That's it.


> I would not trust them to work correctly on a different platform out of
> the box or even a different file-system
> on same platform. That doesn't make it a bad thing to do.
> They can be made a little more portable with effort.
>

AFIO provides four implementations of afio::algorithm::shared_fs_mutex. It
makes use of byte range locks to implement those, but mostly solely as
sentinels for detecting sudden process exit by another process holding a
lock.

Now, Windows on the other hand really nailed byte range locks beautifully.
Correct design. Amazing performance, Scales beautifully. Doesn't burn the
CPU. Works with threads. Async API. POSIX literally should take the NT byte
range lock design and use it verbatim. It's the right design. Shame about
the mandatory locking though, choice of advisory or mandatory would have
been better.


>
>> >
>> > What other major use case is there for exposing the native file handle
>> for
>> > iostreams? I suppose maybe handing fds off to child processes. But
>> that's
>> > best implemented by you opening the fds by hand, configuring them, then
>> > wrapping them into iostreams if needed.
>> >
>>
>
> A pipe is exactly one of the other uses I would have in mind.
> However, the semantics of pipe mean it must be an entirely separate class
> from filebuf
> (obviously as it isn't really a file).
>

Unless they've removed it, the Networking TS should implement iostreams
integration for pipes. ASIO certainly does. If it's still there, then
you're covered by the TS and can untick that use case too.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5a84ec19-c257-46d1-b6ec-068016f4ced5%40isocpp.org.

------=_Part_5673_261008499.1502744971841
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br>&gt;
<br>&gt; 1. Byte range locking has highly non-portable semantics, and is do=
wnright
<br>&gt; dangerous to use on POSIX with iostreams. Any code using the under=
lying fd
<br>&gt; for byte range locking on POSIX is probably incorrect.
<br>&gt;</blockquote><div>I think you mean non-portable rather than incorre=
ct. I know of several implementations that work correctly.<br></div></div><=
/blockquote><div><br></div><div>No, I mean incorrect.</div><div><br></div><=
div>The byte range locking API is so severely broken in POSIX as to make it=
 impossible to write correct code with it.</div><div><br></div><div>It is p=
ossible to write correct code if and only if:</div><div><br></div><div>1. I=
f you control all file descriptors in the entire process.</div><div><br></d=
iv><div>2. Files are never big.</div><div><br></div><div>3. Files are never=
 on a network drive.</div><div><br></div><div>4. You don&#39;t care about p=
athological performance occurring (like, single digit grants per second).</=
div><div><br></div><div>5. You don&#39;t use threads.</div><div><br></div><=
div>6. You don&#39;t care about power consumption.</div><div><br></div><div=
>7. You don&#39;t switch between shared and exclusive on non-identical rang=
es.</div><div><br></div><div>8. You never recurse into code which needs to =
take a lock whilst holding a lock.</div><div><br></div><div>9. You can guar=
antee no third party is permuting the bit of filesystem you are using.</div=
><div><br></div><div>But if you can meet all those conditions, then almost =
any other form of synchronisation is better and faster. The sole thing whic=
h byte range locks have which is useful is that they auto-release if the ho=
lding process suddenly exits. That&#39;s it.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I would not trus=
t them to work correctly on a different platform out of the box or even a d=
ifferent file-system<br>on same platform. That doesn&#39;t make it a bad th=
ing to do. <br>They can be made a little more portable with effort.<br></di=
v></div></blockquote><div><br></div><div>AFIO provides four implementations=
 of afio::algorithm::shared_fs_mutex. It makes use of byte range locks to i=
mplement those, but mostly solely as sentinels for detecting sudden process=
 exit by another process holding a lock.</div><div><br></div><div>Now, Wind=
ows on the other hand really nailed byte range locks beautifully. Correct d=
esign. Amazing performance, Scales beautifully. Doesn&#39;t burn the CPU. W=
orks with threads. Async API. POSIX literally should take the NT byte range=
 lock design and use it verbatim. It&#39;s the right design. Shame about th=
e mandatory locking though, choice of advisory or mandatory would have been=
 better.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>&gt;
<br>&gt; What other major use case is there for exposing the native file ha=
ndle for
<br>&gt; iostreams? I suppose maybe handing fds off to child processes. But=
 that&#39;s
<br>&gt; best implemented by you opening the fds by hand, configuring them,=
 then
<br>&gt; wrapping them into iostreams if needed.
<br>&gt;
<br></blockquote><div><br>A pipe is exactly one of the other uses I would h=
ave in mind. <br>However, the semantics of pipe mean it must be an entirely=
 separate class from filebuf<br>(obviously as it isn&#39;t really a file).<=
br></div></div></blockquote><div><br></div><div>Unless they&#39;ve removed =
it, the Networking TS should implement iostreams integration for pipes. ASI=
O certainly does. If it&#39;s still there, then you&#39;re covered by the T=
S and can untick that use case too.</div><div><br></div><div>Niall</div><di=
v><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5a84ec19-c257-46d1-b6ec-068016f4ced5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a84ec19-c257-46d1-b6ec-068016f4ced5=
%40isocpp.org</a>.<br />

------=_Part_5673_261008499.1502744971841--

------=_Part_5672_1992800009.1502744971840--

.

------=_Part_5732_1701621515.1502756042445
Content-Type: multipart/alternative;
 boundary="----=_Part_5733_1968264164.1502756042445"

------=_Part_5733_1968264164.1502756042445
Content-Type: text/plain; charset="UTF-8"



On Monday, 14 August 2017 20:48:26 UTC+1, Ville Voutilainen wrote:
>
> On 14 August 2017 at 22:37,  <torto...@gmail.com <javascript:>> wrote:
> >> These are yet further reasons to leave iostreams' and filebuf's API
> >> alone. It's not
> >> generally sane to expose the underlying file descriptor at that level.
> >> If you think it's
> >> something to fiddle with, make sure you know that you're dealing with a
> >> filebuf
> >> that is willing to expose the descriptor, cast down to that derived
> >> filebuf and get
> >> the descriptor from there.
> >
> >
> > Are you suggesting it should be possible to cast from a filebuf to a
> > native_filebuf?
>
> Perhaps it shouldn't. If native_filebuf derives from filebuf, the cast
> becomes
> automatically possible because it's just a dynamic_cast.
>
> > If they are really the same thing then requiring an explicit downcast to
> > native_filebuf isn't much more protection
> > from "here be dragons" than a similar warning on the method to retrieve
> the
> > native file descriptor.
>
> Sure, except that you need to know the target type and explicitly
> downcast to it. Sure,
> you can also use typeid to query what it really is. That doesn't mean
> that filebuf
> and native_filebuf are a same thing, and perhaps native_filebuf should
> not derive
> from filebuf but from streambuf.
>
> > If they are different? What is the significant difference? (in terms of
> > implementation or abstraction)
>
> The significant difference is that native_filebuf has a file
> descriptor API, whereas filebuf
> does not.
>
> That's circular reasoning. Why shouldn't filebuf have a file descriptor
API?


> > So that just leaves the native_filebuf == filebuf question.
>
> That should evaluate to false, and perhaps even so that you can't cast
> a filebuf to a native_filebuf,
> i.e. they wouldn't have an inheritance relationship.
>

I'm still not seeing a clear reason.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3dda2226-82b0-4068-9064-502ef70673d7%40isocpp.org.

------=_Part_5733_1968264164.1502756042445
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 14 August 2017 20:48:26 UTC+1, Ville Vo=
utilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 August =
2017 at 22:37, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"-DIW_GTECAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">torto...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; These are yet further reasons to leave iostreams&#39; and file=
buf&#39;s API
<br>&gt;&gt; alone. It&#39;s not
<br>&gt;&gt; generally sane to expose the underlying file descriptor at tha=
t level.
<br>&gt;&gt; If you think it&#39;s
<br>&gt;&gt; something to fiddle with, make sure you know that you&#39;re d=
ealing with a
<br>&gt;&gt; filebuf
<br>&gt;&gt; that is willing to expose the descriptor, cast down to that de=
rived
<br>&gt;&gt; filebuf and get
<br>&gt;&gt; the descriptor from there.
<br>&gt;
<br>&gt;
<br>&gt; Are you suggesting it should be possible to cast from a filebuf to=
 a
<br>&gt; native_filebuf?
<br>
<br>Perhaps it shouldn&#39;t. If native_filebuf derives from filebuf, the c=
ast becomes
<br>automatically possible because it&#39;s just a dynamic_cast.
<br>
<br>&gt; If they are really the same thing then requiring an explicit downc=
ast to
<br>&gt; native_filebuf isn&#39;t much more protection
<br>&gt; from &quot;here be dragons&quot; than a similar warning on the met=
hod to retrieve the
<br>&gt; native file descriptor.
<br>
<br>Sure, except that you need to know the target type and explicitly
<br>downcast to it. Sure,
<br>you can also use typeid to query what it really is. That doesn&#39;t me=
an
<br>that filebuf
<br>and native_filebuf are a same thing, and perhaps native_filebuf should
<br>not derive
<br>from filebuf but from streambuf.
<br>
<br>&gt; If they are different? What is the significant difference? (in ter=
ms of
<br>&gt; implementation or abstraction)
<br>
<br>The significant difference is that native_filebuf has a file
<br>descriptor API, whereas filebuf
<br>does not.
<br>
<br></blockquote><div>That&#39;s circular reasoning. Why shouldn&#39;t file=
buf have a file descriptor API?<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">&gt; So that just leaves the native_filebuf =3D=3D filebuf=
 question.
<br>
<br>That should evaluate to false, and perhaps even so that you can&#39;t c=
ast
<br>a filebuf to a native_filebuf,
<br>i.e. they wouldn&#39;t have an inheritance relationship.
<br></blockquote><div><br>I&#39;m still not seeing a clear reason. <br></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3dda2226-82b0-4068-9064-502ef70673d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3dda2226-82b0-4068-9064-502ef70673d7=
%40isocpp.org</a>.<br />

------=_Part_5733_1968264164.1502756042445--

------=_Part_5732_1701621515.1502756042445--

.

------=_Part_5806_137053434.1502756240679
Content-Type: multipart/alternative;
 boundary="----=_Part_5807_1649703022.1502756240679"

------=_Part_5807_1649703022.1502756240679
Content-Type: text/plain; charset="UTF-8"



On Monday, 14 August 2017 21:37:38 UTC+1, Nicol Bolas wrote:
>
> On Monday, August 14, 2017 at 3:37:15 PM UTC-4, Bruce Adams wrote:
>>
>> There was a remark earlier that filebuf is not the only interface to file
>> IO in C++.
>> The only other one I know of is cstdio. I don't really class that as
>> 'C++' anymore than I would another library with a C binding.
>> It is in the standard because compatibility with C is not only good but
>> essential.
>>
>
> Too many C++ programmers use cstdio instead of iostreams for us to label
> it as a for-compatibility-only feature. The availability of `fprintf` alone
> makes it too useful of a feature for us to discount it as a thing for
> compatibility.
>

I wasn't suggesting that officially. Its just a matter of personal taste
(caveat C programmers people writing C style programs in C++). Though in
this case I guess its the only way to do unbuffered IO without having a
native_filebuf?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/45f85500-e736-4123-a328-03a7c1c39f05%40isocpp.org.

------=_Part_5807_1649703022.1502756240679
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 14 August 2017 21:37:38 UTC+1, Nicol Bo=
las  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
 Monday, August 14, 2017 at 3:37:15 PM UTC-4, Bruce Adams wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>There was a remark earli=
er that filebuf is not the only interface to file IO in C++.<br>The only ot=
her one I know of is cstdio. I don&#39;t really class that as &#39;C++&#39;=
 anymore than I would another library with a C binding.<br>It is in the sta=
ndard because compatibility with C is not only good but essential.<br></div=
></div></blockquote><div><br>Too many C++ programmers use cstdio instead of=
 iostreams for us to label it as a for-compatibility-only feature. The avai=
lability of `fprintf` alone makes it too useful of a feature for us to disc=
ount it as a thing for compatibility.<br></div></div></blockquote><div><br>=
I wasn&#39;t suggesting that officially. Its just a matter of personal tast=
e (caveat C programmers people writing C style programs in C++). Though in =
this case I guess its the only way to do unbuffered IO without having a nat=
ive_filebuf?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/45f85500-e736-4123-a328-03a7c1c39f05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45f85500-e736-4123-a328-03a7c1c39f05=
%40isocpp.org</a>.<br />

------=_Part_5807_1649703022.1502756240679--

------=_Part_5806_137053434.1502756240679--

.

On 15 August 2017 at 03:14,  <tortoise741@gmail.com> wrote:
>> > If they are different? What is the significant difference? (in terms of
>> > implementation or abstraction)
>>
>> The significant difference is that native_filebuf has a file
>> descriptor API, whereas filebuf
>> does not.
>>
> That's circular reasoning. Why shouldn't filebuf have a file descriptor API?

Because everything in filebuf's API is portable, and it has no
platform-specific parts.
As soon as I see you create a filebuf (and not a filebuf* that might
be something else
due to polymorphism), I know that I'm dealing with a cross-platform
facility, and platform-specific
facilities don't enter the picture.

File descriptors are platform-specific, and have platform-specific
semantics. Since I don't
have to amend the cross-platform API of filebuf with platform-specific
parts, I choose not to.
Every interesting way of getting a file descriptor is
platform-specific; I want to wrap iostreams
on top of descriptors acquired via platform-specific ways. Something
like fileno() is of no
interest to me whatsoever. What is of interest is open(), and whatever
the Windows equivalent
is.

While it might be to some extent convenient to just create a filebuf
directly from a file descriptor,
it becomes less convenient when the filebuf type no longer serves its
purpose as a cross-platform
abstraction that has no platform-specific parts. I can architecturally
separate my cross-platform
parts from my platform-specific parts by using different types in
these different abstraction layers,
and instantly recognize which kinds of operations and types I'm dealing with.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb1qhLgaqUnxedxj80OMrdniC%3DnAK2tMR%2BG%2BSDd8C1sPw%40mail.gmail.com.

.

------=_Part_5621_667399888.1502758026619
Content-Type: multipart/alternative;
 boundary="----=_Part_5622_1452300806.1502758026619"

------=_Part_5622_1452300806.1502758026619
Content-Type: text/plain; charset="UTF-8"



On Monday, 14 August 2017 22:09:31 UTC+1, Niall Douglas wrote:
>
>
>>> >
>>> > 1. Byte range locking has highly non-portable semantics, and is
>>> downright
>>> > dangerous to use on POSIX with iostreams. Any code using the
>>> underlying fd
>>> > for byte range locking on POSIX is probably incorrect.
>>> >
>>
>> I think you mean non-portable rather than incorrect. I know of several
>> implementations that work correctly.
>>
>
> No, I mean incorrect.
>
> The byte range locking API is so severely broken in POSIX as to make it
> impossible to write correct code with it.
>
> It is possible to write correct code if and only if:
>
> 1. If you control all file descriptors in the entire process.
>
> why wouldn't you? or rather why would you think it was a good idea not to
if you are trying to lock things?


> 2. Files are never big.
>
> The reason for this one is less clear? performance perhaps? How big is big?


> 3. Files are never on a network drive.
>
> Yes. File locking 101 - don't use NFS or Samba. Although allegedly it
might work better on NFS4 which no-one has properly implemented yet.
I haven't tried it on other remote file systems like sshfs. But I'm sure it
would be 'interesting'.


> 4. You don't care about pathological performance occurring (like, single
> digit grants per second).
>
> That sounds like it should be the program's fault for locking too often.
i.e. poor design


> 5. You don't use threads.
>
> Just be careful about which thread is doing the locking. Its an issue as
with many other shareable resources.


> 6. You don't care about power consumption.
>
> This one makes little sense to me. Even on an embedded system it should be
a case of flipping a few bit and checking if they're flipped.


> 7. You don't switch between shared and exclusive on non-identical ranges.
>
> That sounds like a potentially bad design too.


> 8. You never recurse into code which needs to take a lock whilst holding a
> lock.
>
> Don't deadlock. Multithreading 101


> 9. You can guarantee no third party is permuting the bit of filesystem you
> are using.
>
> Yes. File locking is for interprocess synchronisation. You have to be in
control of the processes involved in that.


> But if you can meet all those conditions, then almost any other form of
> synchronisation is better and faster. The sole thing which byte range locks
> have which is useful is that they auto-release if the holding process
> suddenly exits. That's it.
>

Wouldn't a lot of other forms of synchronisation have to re-invent advisory
locking for themselves to do this?

>
>
>> I would not trust them to work correctly on a different platform out of
>> the box or even a different file-system
>> on same platform. That doesn't make it a bad thing to do.
>> They can be made a little more portable with effort.
>>
>
> AFIO provides four implementations of afio::algorithm::shared_fs_mutex. It
> makes use of byte range locks to implement those, but mostly solely as
> sentinels for detecting sudden process exit by another process holding a
> lock.
>
> Your need for locks here seems to agree with my assessment above?


> Now, Windows on the other hand really nailed byte range locks beautifully.
> Correct design. Amazing performance, Scales beautifully. Doesn't burn the
> CPU. Works with threads. Async API. POSIX literally should take the NT byte
> range lock design and use it verbatim. It's the right design. Shame about
> the mandatory locking though, choice of advisory or mandatory would have
> been better.
>
>
That is not something I often here about a Windows API but it could perhaps
be a Windows person versus Unix person thing?
Care to elaborate?


>
>>> >
>>> > What other major use case is there for exposing the native file handle
>>> for
>>> > iostreams? I suppose maybe handing fds off to child processes. But
>>> that's
>>> > best implemented by you opening the fds by hand, configuring them,
>>> then
>>> > wrapping them into iostreams if needed.
>>> >
>>>
>>
>> A pipe is exactly one of the other uses I would have in mind.
>> However, the semantics of pipe mean it must be an entirely separate class
>> from filebuf
>> (obviously as it isn't really a file).
>>
>
> Unless they've removed it, the Networking TS should implement iostreams
> integration for pipes. ASIO certainly does. If it's still there, then
> you're covered by the TS and can untick that use case too.
>
> Niall
>
>
Pipes was never ticked for this proposal.

Pipe doesn't appear in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf other
than in reference to sigpipe.
But I think ASIO was split into bits so they might be in another proposal
somewhere.

Bruce.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dec6c726-d590-439c-9d25-c69b79c0d026%40isocpp.org.

------=_Part_5622_1452300806.1502758026619
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 14 August 2017 22:09:31 UTC+1, Niall Do=
uglas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><br>&gt;
<br>&gt; 1. Byte range locking has highly non-portable semantics, and is do=
wnright
<br>&gt; dangerous to use on POSIX with iostreams. Any code using the under=
lying fd
<br>&gt; for byte range locking on POSIX is probably incorrect.
<br>&gt;</blockquote><div>I think you mean non-portable rather than incorre=
ct. I know of several implementations that work correctly.<br></div></div><=
/blockquote><div><br></div><div>No, I mean incorrect.</div><div><br></div><=
div>The byte range locking API is so severely broken in POSIX as to make it=
 impossible to write correct code with it.</div><div><br></div><div>It is p=
ossible to write correct code if and only if:</div><div><br></div><div>1. I=
f you control all file descriptors in the entire process.</div><div><br></d=
iv></div></blockquote><div>why wouldn&#39;t you? or rather why would you th=
ink it was a good idea not to if you are trying to lock things?<br>=C2=A0<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
</div><div>2. Files are never big.</div><div><br></div></div></blockquote><=
div>The reason for this one is less clear? performance perhaps? How big is =
big?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><div>3. Files are never on a network drive.</div><div><=
br></div></div></blockquote><div>Yes. File locking 101 - don&#39;t use NFS =
or Samba. Although allegedly it might work better on NFS4 which no-one has =
properly implemented yet.<br>I haven&#39;t tried it on other remote file sy=
stems like sshfs. But I&#39;m sure it would be &#39;interesting&#39;.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><div>4. You don&#39;t care about pathological performance occurri=
ng (like, single digit grants per second).</div><div><br></div></div></bloc=
kquote><div>That sounds like it should be the program&#39;s fault for locki=
ng too often. i.e. poor design<br>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div></div><div>5. You don&#39;t use threa=
ds.</div><div><br></div></div></blockquote><div>Just be careful about which=
 thread is doing the locking. Its an issue as with many other shareable res=
ources.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div></div><div>6. You don&#39;t care about power consumption.</d=
iv><div><br></div></div></blockquote><div>This one makes little sense to me=
.. Even on an embedded system it should be a case of flipping a few bit and =
checking if they&#39;re flipped.<br>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div></div><div>7. You don&#39;t switch =
between shared and exclusive on non-identical ranges.</div><div><br></div><=
/div></blockquote><div>That sounds like a potentially bad design too.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><div>8. You never recurse into code which needs to take a lock wh=
ilst holding a lock.</div><div><br></div></div></blockquote><div>Don&#39;t =
deadlock. Multithreading 101 <br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div></div><div>9. You can guarantee no thi=
rd party is permuting the bit of filesystem you are using.</div><div><br></=
div></div></blockquote><div>Yes. File locking is for interprocess synchroni=
sation. You have to be in control of the processes involved in that.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
></div><div>But if you can meet all those conditions, then almost any other=
 form of synchronisation is better and faster. The sole thing which byte ra=
nge locks have which is useful is that they auto-release if the holding pro=
cess suddenly exits. That&#39;s it.</div></div></blockquote><div><br>Wouldn=
&#39;t a lot of other forms of synchronisation have to re-invent advisory l=
ocking for themselves to do this? <br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>I would not trust them to work correctly=
 on a different platform out of the box or even a different file-system<br>=
on same platform. That doesn&#39;t make it a bad thing to do. <br>They can =
be made a little more portable with effort.<br></div></div></blockquote><di=
v><br></div><div>AFIO provides four implementations of afio::algorithm::sha=
red_fs_<wbr>mutex. It makes use of byte range locks to implement those, but=
 mostly solely as sentinels for detecting sudden process exit by another pr=
ocess holding a lock.</div><div><br></div></div></blockquote><div>Your need=
 for locks here seems to agree with my assessment above? <br>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div=
>Now, Windows on the other hand really nailed byte range locks beautifully.=
 Correct design. Amazing performance, Scales beautifully. Doesn&#39;t burn =
the CPU. Works with threads. Async API. POSIX literally should take the NT =
byte range lock design and use it verbatim. It&#39;s the right design. Sham=
e about the mandatory locking though, choice of advisory or mandatory would=
 have been better.</div><div>=C2=A0</div></div></blockquote><div>That is no=
t something I often here about a Windows API but it could perhaps be a Wind=
ows person versus Unix person thing?<br>Care to elaborate?<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><br>&gt;
<br>&gt; What other major use case is there for exposing the native file ha=
ndle for
<br>&gt; iostreams? I suppose maybe handing fds off to child processes. But=
 that&#39;s
<br>&gt; best implemented by you opening the fds by hand, configuring them,=
 then
<br>&gt; wrapping them into iostreams if needed.
<br>&gt;
<br></blockquote><div><br>A pipe is exactly one of the other uses I would h=
ave in mind. <br>However, the semantics of pipe mean it must be an entirely=
 separate class from filebuf<br>(obviously as it isn&#39;t really a file).<=
br></div></div></blockquote><div><br></div><div>Unless they&#39;ve removed =
it, the Networking TS should implement iostreams integration for pipes. ASI=
O certainly does. If it&#39;s still there, then you&#39;re covered by the T=
S and can untick that use case too.</div><div><br></div><div>Niall</div><di=
v><br></div></div></blockquote><div><br>Pipes was never ticked for this pro=
posal.<br><br>Pipe doesn&#39;t appear in http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2017/n4656.pdf other than in reference to sigpipe.<br>But =
I think ASIO was split into bits so they might be in another proposal somew=
here.<br><br>Bruce. <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dec6c726-d590-439c-9d25-c69b79c0d026%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dec6c726-d590-439c-9d25-c69b79c0d026=
%40isocpp.org</a>.<br />

------=_Part_5622_1452300806.1502758026619--

------=_Part_5621_667399888.1502758026619--

.

On Monday, 14 August 2017 17:47:06 PDT tortoise741@gmail.com wrote:
> > 1. If you control all file descriptors in the entire process.
> >
>  why wouldn't you? or rather why would you think it was a good idea not to
> if you are trying to lock things?

When you write a library, you don't control the rest of the process.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5493647.ZmdN70EvOZ%40tjmaciei-mobl1.

.

------=_Part_5418_1527891415.1502758793739
Content-Type: multipart/alternative;
 boundary="----=_Part_5419_2017051515.1502758793740"

------=_Part_5419_2017051515.1502758793740
Content-Type: text/plain; charset="UTF-8"



On Tuesday, 15 August 2017 01:31:32 UTC+1, Ville Voutilainen wrote:
>
> On 15 August 2017 at 03:14,  <torto...@gmail.com <javascript:>> wrote:
> >> > If they are different? What is the significant difference? (in terms
> of
> >> > implementation or abstraction)
> >>
> >> The significant difference is that native_filebuf has a file
> >> descriptor API, whereas filebuf
> >> does not.
> >>
> > That's circular reasoning. Why shouldn't filebuf have a file descriptor
> API?
>
> Because everything in filebuf's API is portable, and it has no
> platform-specific parts.
> As soon as I see you create a filebuf (and not a filebuf* that might
> be something else
> due to polymorphism), I know that I'm dealing with a cross-platform
> facility, and platform-specific
> facilities don't enter the picture.
>
> File descriptors are platform-specific, and have platform-specific
> semantics. Since I don't
> have to amend the cross-platform API of filebuf with platform-specific
> parts, I choose not to.
> Every interesting way of getting a file descriptor is
> platform-specific; I want to wrap iostreams
> on top of descriptors acquired via platform-specific ways. Something
> like fileno() is of no
> interest to me whatsoever. What is of interest is open(), and whatever
> the Windows equivalent
> is.
>
> While it might be to some extent convenient to just create a filebuf
> directly from a file descriptor,
> it becomes less convenient when the filebuf type no longer serves its
> purpose as a cross-platform
> abstraction that has no platform-specific parts. I can architecturally
> separate my cross-platform
> parts from my platform-specific parts by using different types in
> these different abstraction layers,
> and instantly recognize which kinds of operations and types I'm dealing
> with.
>

I see what your saying but I'm not sure I buy it here.

Does the rest of the standard separating portable and non-portable classes
or does it just label functions accordingly?

A slightly related issue. You have an extra cognitive burden of needing
another filebuf variant which needs to be specified in full.
I'm not sure that standardese lets you say - exactly like this class but
with two additional functions. Maybe it does?
Adding a couple of functions looks dangerously like derivation but in this
case the derivation is possibly inverted. What is a filebuf if not a
native_filebuf with those
two functions hidden?

I think if we want to make a distinction it has to be on more solid grounds.
Buffering might make sense. If you said a native_filebuf has no buffering
at all and a filebuf has some mandated buffering that might be the
significant difference to justify it.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5667e6c1-7ab5-4c16-ab7a-0b2784ae1168%40isocpp.org.

------=_Part_5419_2017051515.1502758793740
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, 15 August 2017 01:31:32 UTC+1, Ville V=
outilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 15 August=
 2017 at 03:14, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"5Jvtx9fTCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">torto...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; If they are different? What is the significant difference=
? (in terms of
<br>&gt;&gt; &gt; implementation or abstraction)
<br>&gt;&gt;
<br>&gt;&gt; The significant difference is that native_filebuf has a file
<br>&gt;&gt; descriptor API, whereas filebuf
<br>&gt;&gt; does not.
<br>&gt;&gt;
<br>&gt; That&#39;s circular reasoning. Why shouldn&#39;t filebuf have a fi=
le descriptor API?
<br>
<br>Because everything in filebuf&#39;s API is portable, and it has no
<br>platform-specific parts.
<br>As soon as I see you create a filebuf (and not a filebuf* that might
<br>be something else
<br>due to polymorphism), I know that I&#39;m dealing with a cross-platform
<br>facility, and platform-specific
<br>facilities don&#39;t enter the picture.
<br>
<br>File descriptors are platform-specific, and have platform-specific
<br>semantics. Since I don&#39;t
<br>have to amend the cross-platform API of filebuf with platform-specific
<br>parts, I choose not to.
<br>Every interesting way of getting a file descriptor is
<br>platform-specific; I want to wrap iostreams
<br>on top of descriptors acquired via platform-specific ways. Something
<br>like fileno() is of no
<br>interest to me whatsoever. What is of interest is open(), and whatever
<br>the Windows equivalent
<br>is.
<br>
<br>While it might be to some extent convenient to just create a filebuf
<br>directly from a file descriptor,
<br>it becomes less convenient when the filebuf type no longer serves its
<br>purpose as a cross-platform
<br>abstraction that has no platform-specific parts. I can architecturally
<br>separate my cross-platform
<br>parts from my platform-specific parts by using different types in
<br>these different abstraction layers,
<br>and instantly recognize which kinds of operations and types I&#39;m dea=
ling with.
<br></blockquote><div><br>I see what your saying but I&#39;m not sure I buy=
 it here.<br><br>Does the rest of the standard separating portable and non-=
portable classes or does it just label functions accordingly?<br><br>A slig=
htly related issue. You have an extra cognitive burden of needing another f=
ilebuf variant which needs to be specified in full.<br>I&#39;m not sure tha=
t standardese lets you say - exactly like this class but with two additiona=
l functions. Maybe it does?<br>Adding a couple of functions looks dangerous=
ly like derivation but in this case the derivation is possibly inverted. Wh=
at is a filebuf if not a native_filebuf with those<br>two functions hidden?=
<br><br>I think if we want to make a distinction it has to be on more solid=
 grounds.<br>Buffering
 might make sense. If you said a native_filebuf has no buffering at all=20
and a filebuf has some mandated buffering that might be the significant=20
difference to justify it.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5667e6c1-7ab5-4c16-ab7a-0b2784ae1168%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5667e6c1-7ab5-4c16-ab7a-0b2784ae1168=
%40isocpp.org</a>.<br />

------=_Part_5419_2017051515.1502758793740--

------=_Part_5418_1527891415.1502758793739--

.

On Monday, 14 August 2017 17:47:06 PDT tortoise741@gmail.com wrote:
> Pipe doesn't appear in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf other
> than in reference to sigpipe.

Which is another POSIX braindamage (in hindsight), like most of signal
support. You can't handle signals cleanly unless you control the entire
application.

Now, with Linux you can skip SIGPIPE on sockets by always using MSG_NOSIGNAL
when sending, whereas on macOS and NetBSD, you use fcntl for F_SETNOSIGPIPE.
NetBSD also has SOCK_NOSIGPIPE to set the flag atomically.

On Linux, you can't cope with SIGPIPE on pipes unless you ignore the signal
globally, for every pipe and socket in the process.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9560002.cegdTN1SbH%40tjmaciei-mobl1.

.

------=_Part_5838_121265195.1502758977771
Content-Type: multipart/alternative;
 boundary="----=_Part_5839_42663553.1502758977771"

------=_Part_5839_42663553.1502758977771
Content-Type: text/plain; charset="UTF-8"



On Tuesday, 15 August 2017 01:55:46 UTC+1, Thiago Macieira wrote:
>
> On Monday, 14 August 2017 17:47:06 PDT torto...@gmail.com <javascript:>
> wrote:
> > > 1. If you control all file descriptors in the entire process.
> > >
> >  why wouldn't you? or rather why would you think it was a good idea not
> to
> > if you are trying to lock things?
>
> When you write a library, you don't control the rest of the process.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
True but you delegate the decision to your library's users.
Or better yet let them set the locking policy on your library.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/380cf558-f98a-4e6d-bf32-5dc8e0b7a3d3%40isocpp.org.

------=_Part_5839_42663553.1502758977771
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, 15 August 2017 01:55:46 UTC+1, Thiago =
Macieira  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, 14 =
August 2017 17:47:06 PDT <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"btmkUirVCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">torto...@gmail.com</a> wrote:
<br>&gt; &gt; 1. If you control all file descriptors in the entire process.
<br>&gt; &gt;=20
<br>&gt; =C2=A0why wouldn&#39;t you? or rather why would you think it was a=
 good idea not to
<br>&gt; if you are trying to lock things?
<br>
<br>When you write a library, you don&#39;t control the rest of the process=
..
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>True but you delegate the decision to your librar=
y&#39;s users.<br>Or better yet let them set the locking policy on your lib=
rary.<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/380cf558-f98a-4e6d-bf32-5dc8e0b7a3d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/380cf558-f98a-4e6d-bf32-5dc8e0b7a3d3=
%40isocpp.org</a>.<br />

------=_Part_5839_42663553.1502758977771--

------=_Part_5838_121265195.1502758977771--

.

On 15 August 2017 at 03:59,  <tortoise741@gmail.com> wrote:
> I see what your saying but I'm not sure I buy it here.
>
> Does the rest of the standard separating portable and non-portable classes
> or does it just label functions accordingly?

False equivalence. A std::thread creates a thread, and gives you
access to the native handle.
However, this leads to the main difference of filebuf and
native_filebuf. filebuf opens a file
for you. While native_filebuf can be made to do that as well, its main
motivation is to
adopt an existing descriptor to an already open file.

> A slightly related issue. You have an extra cognitive burden of needing
> another filebuf variant which needs to be specified in full.
> I'm not sure that standardese lets you say - exactly like this class but
> with two additional functions. Maybe it does?
> Adding a couple of functions looks dangerously like derivation but in this
> case the derivation is possibly inverted. What is a filebuf if not a
> native_filebuf with those
> two functions hidden?

See above.

> I think if we want to make a distinction it has to be on more solid grounds.
> Buffering might make sense. If you said a native_filebuf has no buffering at
> all and a filebuf has some mandated buffering that might be the significant
> difference to justify it.


That would be complete nonsense. Whether a native_filebuf ends up
doing buffered i/o
depends on how you opened the file. And filebuf has no mandated
buffering, it can hit
the disk on every byte if it so chooses, although that would be a poor
implementation.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYDa3vtLjd3Ropt2%3DNZpu7LNLarAHi%2B8kwT6ZLmndPOTA%40mail.gmail.com.

.

------=_Part_5807_1871703237.1502760714805
Content-Type: multipart/alternative;
 boundary="----=_Part_5808_1961706337.1502760714806"

------=_Part_5808_1961706337.1502760714806
Content-Type: text/plain; charset="UTF-8"

On Monday, August 14, 2017 at 9:02:57 PM UTC-4, Bruce Adams wrote:
>
> On Tuesday, 15 August 2017 01:55:46 UTC+1, Thiago Macieira wrote:
>>
>> On Monday, 14 August 2017 17:47:06 PDT torto...@gmail.com wrote:
>> > > 1. If you control all file descriptors in the entire process.
>> > >
>> >  why wouldn't you? or rather why would you think it was a good idea not
>> to
>> > if you are trying to lock things?
>>
>> When you write a library, you don't control the rest of the process.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>>
> True but you delegate the decision to your library's users.
> Or better yet let them set the locking policy on your library.
>

And what of the libraries that are designed to use cross-platform file IO
(filebuf/FILE*) internally, and therefore are written in complete ignorance
of platform-specific feature like "locking policy" and so forth? Isn't that
essentially admitting to Niall's original point: "The byte range locking
API is so severely broken in POSIX as to make it impossible to write
correct code with it."

Sure, it's not "impossible" (which he goes on to admit to and explain what
you have to do to make it "possible"), but it's certainly not something
that an application can do in a vacuum. Either the *entire* application is
written with an eye to it, or it cannot work.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb1e21fe-923b-4252-81c9-c132b514cf25%40isocpp.org.

------=_Part_5808_1961706337.1502760714806
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 14, 2017 at 9:02:57 PM UTC-4, Bruce Adam=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Tu=
esday, 15 August 2017 01:55:46 UTC+1, Thiago Macieira  wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">On Monday, 14 August 2017 17:47:06 PDT <a rel=3D"=
nofollow">torto...@gmail.com</a> wrote:
<br>&gt; &gt; 1. If you control all file descriptors in the entire process.
<br>&gt; &gt;=20
<br>&gt; =C2=A0why wouldn&#39;t you? or rather why would you think it was a=
 good idea not to
<br>&gt; if you are trying to lock things?
<br>
<br>When you write a library, you don&#39;t control the rest of the process=
..
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>True but you delegate the decision to your librar=
y&#39;s users.<br>Or better yet let them set the locking policy on your lib=
rary.<br></div></div></blockquote><div><br>And what of the libraries that a=
re designed to use cross-platform file=20
IO (filebuf/FILE*) internally, and therefore are written in complete ignora=
nce of platform-specific feature like
 &quot;locking policy&quot; and so forth? Isn&#39;t that essentially admitt=
ing to Niall&#39;s original point: &quot;The byte range locking API is so s=
everely broken in POSIX as to make it impossible to write correct code with=
 it.&quot;<br><br>Sure, it&#39;s not &quot;impossible&quot; (which he goes =
on to admit to and explain what you have to do to make it &quot;possible&qu=
ot;), but it&#39;s certainly not something that an application can do in a =
vacuum. Either the <i>entire</i> application is written with an eye to it, =
or it cannot work.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb1e21fe-923b-4252-81c9-c132b514cf25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb1e21fe-923b-4252-81c9-c132b514cf25=
%40isocpp.org</a>.<br />

------=_Part_5808_1961706337.1502760714806--

------=_Part_5807_1871703237.1502760714805--

.

------=_Part_5615_1876033934.1502761568122
Content-Type: multipart/alternative;
 boundary="----=_Part_5616_1200473212.1502761568122"

------=_Part_5616_1200473212.1502761568122
Content-Type: text/plain; charset="UTF-8"



On Tuesday, 15 August 2017 02:07:55 UTC+1, Ville Voutilainen wrote:
>
> On 15 August 2017 at 03:59,  <torto...@gmail.com <javascript:>> wrote:
> > I see what your saying but I'm not sure I buy it here.
> >
> > Does the rest of the standard separating portable and non-portable
> classes
> > or does it just label functions accordingly?
>
> False equivalence. A std::thread creates a thread, and gives you
> access to the native handle.
>

I am not and have never been thinking of std::thread and filebuf as
equivalent.

There must be quite a few functions that can be used non-portably beyond
those inherited from the C library.

The filesystem ts has functionality relating to symbolic links that might
qualify.
While other bits of it are more portable.

I'm sure there are a few other cases of undefined, unspecified or
implementation defined
that might quality. I recall having problems with the portability of seek()
a while back though
it could have been down to a non-conforming implementation.


> However, this leads to the main difference of filebuf and
> native_filebuf. filebuf opens a file
> for you. While native_filebuf can be made to do that as well, its main
> motivation is to
> adopt an existing descriptor to an already open file.
>
> I disagree. The main motivation for me is to obtain the descriptor for a
file opened using fstream.
Adopting an existing descriptor is a valid use case as well.



> > A slightly related issue. You have an extra cognitive burden of needing
> > another filebuf variant which needs to be specified in full.
> > I'm not sure that standardese lets you say - exactly like this class but
> > with two additional functions. Maybe it does?
> > Adding a couple of functions looks dangerously like derivation but in
> this
> > case the derivation is possibly inverted. What is a filebuf if not a
> > native_filebuf with those
> > two functions hidden?
>
> See above.
>
> > I think if we want to make a distinction it has to be on more solid
> grounds.
> > Buffering might make sense. If you said a native_filebuf has no
> buffering at
> > all and a filebuf has some mandated buffering that might be the
> significant
> > difference to justify it.
>
>
> That would be complete nonsense. Whether a native_filebuf ends up
> doing buffered i/o
> depends on how you opened the file. And filebuf has no mandated
> buffering, it can hit
> the disk on every byte if it so chooses, although that would be a poor
> implementation.
>

True. I didn't think that one through at all.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a7e6ba89-9cd1-4838-83b2-c4adf81cb886%40isocpp.org.

------=_Part_5616_1200473212.1502761568122
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, 15 August 2017 02:07:55 UTC+1, Ville V=
outilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 15 August=
 2017 at 03:59, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"yBde99PVCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">torto...@gmail.com</a>&gt; wrote:
<br>&gt; I see what your saying but I&#39;m not sure I buy it here.
<br>&gt;
<br>&gt; Does the rest of the standard separating portable and non-portable=
 classes
<br>&gt; or does it just label functions accordingly?
<br>
<br>False equivalence. A std::thread creates a thread, and gives you
<br>access to the native handle.
<br></blockquote><div><br>I am not and have never been thinking of std::thr=
ead and filebuf as equivalent.<br><br>There must be quite a few functions t=
hat can be used non-portably beyond<br>those inherited from the C library.<=
br><br>The filesystem ts has functionality relating to symbolic links that =
might qualify.<br>While other bits of it are more portable.<br><br>I&#39;m =
sure there are a few other cases of undefined, unspecified or implementatio=
n defined<br>that might quality. I recall having problems with the portabil=
ity of seek() a while back though<br>it could have been down to a non-confo=
rming implementation. <br>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">However, this leads to the main difference of filebuf and
<br>native_filebuf. filebuf opens a file
<br>for you. While native_filebuf can be made to do that as well, its main
<br>motivation is to
<br>adopt an existing descriptor to an already open file.
<br>
<br></blockquote><div>I disagree. The main motivation for me is to obtain t=
he descriptor for a file opened using fstream.<br>Adopting an existing desc=
riptor is a valid use case as well. <br></div><div><br>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">&gt; A slightly related issue. You hav=
e an extra cognitive burden of needing
<br>&gt; another filebuf variant which needs to be specified in full.
<br>&gt; I&#39;m not sure that standardese lets you say - exactly like this=
 class but
<br>&gt; with two additional functions. Maybe it does?
<br>&gt; Adding a couple of functions looks dangerously like derivation but=
 in this
<br>&gt; case the derivation is possibly inverted. What is a filebuf if not=
 a
<br>&gt; native_filebuf with those
<br>&gt; two functions hidden?
<br>
<br>See above.
<br>
<br>&gt; I think if we want to make a distinction it has to be on more soli=
d grounds.
<br>&gt; Buffering might make sense. If you said a native_filebuf has no bu=
ffering at
<br>&gt; all and a filebuf has some mandated buffering that might be the si=
gnificant
<br>&gt; difference to justify it.
<br>
<br>
<br>That would be complete nonsense. Whether a native_filebuf ends up
<br>doing buffered i/o
<br>depends on how you opened the file. And filebuf has no mandated
<br>buffering, it can hit
<br>the disk on every byte if it so chooses, although that would be a poor
<br>implementation.
<br></blockquote><div><br>True. I didn&#39;t think that one through at all.=
 <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a7e6ba89-9cd1-4838-83b2-c4adf81cb886%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a7e6ba89-9cd1-4838-83b2-c4adf81cb886=
%40isocpp.org</a>.<br />

------=_Part_5616_1200473212.1502761568122--

------=_Part_5615_1876033934.1502761568122--

.

------=_Part_5731_1500584455.1502763777678
Content-Type: multipart/alternative;
 boundary="----=_Part_5732_1206810819.1502763777678"

------=_Part_5732_1206810819.1502763777678
Content-Type: text/plain; charset="UTF-8"


>
>
>>
>> The byte range locking API is so severely broken in POSIX as to make it
>> impossible to write correct code with it.
>>
>> It is possible to write correct code if and only if:
>>
>> 1. If you control all file descriptors in the entire process.
>>
>> why wouldn't you? or rather why would you think it was a good idea not to
> if you are trying to lock things?
>

Almost no software today doesn't make extensive use of third party
libraries, often with source code which cannot be easily modified.

And due to POSIX dropping all byte range locks as soon as *any* fd to that
inode is closed, it makes byte range locks inherently problematic.

Consider for example an implementation of filesystem::path::exists() which
tries to open the path to test for existence. It would open and then close
a fd. If any code elsewhere in the process has byte range locks open on
that inode, they get dropped.

Before you say "just use stat() then", you can't in many cases e.g. if the
filesystem is permuting randomly, because then you can't use paths at all.
Also, incidentally, there is nothing stopping stat() being implemented by
your libc as open()-fstat()-close() like it must be on Windows. Again, game
over thanks to the design of POSIX byte range locks.


>
>
>> 2. Files are never big.
>>
>> The reason for this one is less clear? performance perhaps? How big is
> big?
>

struct flock due to some amazing bad design uses *signed* values, thus
rendering the top half of your file unlockable.

You might think that not important. For filesystem algorithm programmers
who might use the entire 64 bit space as an open hash table using sparse
storage and hole punching, it's a showstopper.

I've also seen implementations fail at offsets after 1<<62 rather than
1<<63. Almost certainly a bug. But not comforting.


>
>
>> 3. Files are never on a network drive.
>>
>> Yes. File locking 101 - don't use NFS or Samba. Although allegedly it
> might work better on NFS4 which no-one has properly implemented yet.
> I haven't tried it on other remote file systems like sshfs. But I'm sure
> it would be 'interesting'.
>

Windows-type oplocks, if implemented correctly, are a much better design.


>
>
>> 4. You don't care about pathological performance occurring (like, single
>> digit grants per second).
>>
>> That sounds like it should be the program's fault for locking too often.
> i.e. poor design
>

No, it's poor quality of implementation in some kernels and/or filing
systems. In some cases they scale exponentially *inverse *to physical CPU
count for example. Wonderful.


>
>
>> 5. You don't use threads.
>>
>> Just be careful about which thread is doing the locking. Its an issue as
> with many other shareable resources.
>

It's not that.

POSIX byte range locks are per-inode, and don't detect attempts to lock the
same region twice, rather they just ignore the second attempt and then
release too early.

You'll probably say now that better design of your code would fix this. But
you don't control the threads in your process increasingly any more,
various third party libraries will spin up threads and go run stuff in the
background out of your control.


>
>
>> 6. You don't care about power consumption.
>>
>> This one makes little sense to me. Even on an embedded system it should
> be a case of flipping a few bit and checking if they're flipped.
>

POSIX byte range locks give you exactly two choices: block until lock
granted, or return immediately.

You can't wait for a timeout. You can't be notified when it's become free.
You can't do other work whilst being blocked.

Thus you end up either spinning on the lock burning CPU, or launching
kernel threads for the sole purpose of waiting on the lock asynchronously.

This hits battery life badly on mobile devices. Lock files are actually
cheaper on power budget, which is sad.


>
>
>> 7. You don't switch between shared and exclusive on non-identical ranges.
>>
>> That sounds like a potentially bad design too.
>

My issue is the lack of specification of atomicity. Implementations don't
say whether shared to exclusive upgrades are atomic, for identical ranges
or overlapping ranges.

It's a common use case to have a region locked for shared use, then you
want to lock some or all of it for exclusive use without anybody else
modifying it before the exclusive lock is granted. The POSIX API isn't fit
for this purpose, it splits and replaces locks instead of laying exclusive
over shared. Unhelpful.

You can't upgrade locks at all on Windows interestingly, but you can
atomically downgrade them i.e. exclusive -> shared atomically. This isn't
as useful, but at least the behaviour is guaranteed.


>
>
>> 8. You never recurse into code which needs to take a lock whilst holding
>> a lock.
>>
>> Don't deadlock. Multithreading 101
>

You don't always control such code. What we'd much prefer to see is EDEADLK
being returned.


>
>
>> 9. You can guarantee no third party is permuting the bit of filesystem
>> you are using.
>>
>> Yes. File locking is for interprocess synchronisation. You have to be in
> control of the processes involved in that.
>

A major attack vector is generating races by maliciously fiddling with
filesystem under IPC usage. TOCTOU etc

You might say "set perms etc" but in fact all that is unnecessary with a
non-broken design. I hate to keep chirping on about Windows, but it won't
let anybody permute part of a filesystem being used for synchronisation,
thus eliminating TOCTOU et al entirely.


>
>
>> But if you can meet all those conditions, then almost any other form of
>> synchronisation is better and faster. The sole thing which byte range locks
>> have which is useful is that they auto-release if the holding process
>> suddenly exits. That's it.
>>
>
> Wouldn't a lot of other forms of synchronisation have to re-invent
> advisory locking for themselves to do this?
>

If the kernel supplied implementation is really lousy - and everywhere but
FreeBSD it is - then you're better off.


>
>>
>>> I would not trust them to work correctly on a different platform out of
>>> the box or even a different file-system
>>> on same platform. That doesn't make it a bad thing to do.
>>> They can be made a little more portable with effort.
>>>
>>
>> AFIO provides four implementations of afio::algorithm::shared_fs_mutex.
>> It makes use of byte range locks to implement those, but mostly solely as
>> sentinels for detecting sudden process exit by another process holding a
>> lock.
>>
>> Your need for locks here seems to agree with my assessment above?
>

When you have multiple processes working on the same data, often you need
to synchronise. You try not to of course, you exploit the natural
synchronisation built into i/o which is actually finally viable as of just
these past months thanks to Microsoft fixing Windows to follow POSIX i/o
concurrency guarantees. You need the very latest Windows 10 however, and a
pretty recent Linux kernel. But it does work, and it's portable-ish.

AFIO uses a list based system for its locking algorithms, so process A says
it'll be locking 5, 22 and 13. Process B says it'll be locking 6, 99, and
13. The synchronisation will happen on the 13.

The numbers are arbitrary and mean whatever the application chooses them to
mean. Under the bonnet, the four implementations have very different
approaches to implementation. Some have amazing performance but are
anti-social. Others scale amazingly. Some are NFS/Samba friendly. Some are
shared memory only.

afio::shared_fs_mutex is an abstract base class, so runtime code can swap
implementations and higher level code doesn't need to care how the locking
works.


>
>
>> Now, Windows on the other hand really nailed byte range locks
>> beautifully. Correct design. Amazing performance, Scales beautifully.
>> Doesn't burn the CPU. Works with threads. Async API. POSIX literally should
>> take the NT byte range lock design and use it verbatim. It's the right
>> design. Shame about the mandatory locking though, choice of advisory or
>> mandatory would have been better.
>>
>>
> That is not something I often here about a Windows API but it could
> perhaps be a Windows person versus Unix person thing?
> Care to elaborate?
>

The Win32 API is generally pants.

But the NT kernel API is lovely. It's really what VMS 6.0 would have been
of course had that team stayed at Digital. Such a lovely kernel API design,
really well thought through, and so very polished. I find it a joy to
program in, but then I always liked VMS's design language.


>
>> Unless they've removed it, the Networking TS should implement iostreams
>> integration for pipes. ASIO certainly does. If it's still there, then
>> you're covered by the TS and can untick that use case too.
>>
>> Niall
>>
>>
> Pipes was never ticked for this proposal.
>
> Pipe doesn't appear in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf other
> than in reference to sigpipe.
> But I think ASIO was split into bits so they might be in another proposal
> somewhere.
>
> I think pipe support makes far more sense next to sockets than to files.

Shame about the removal. I have always wished the Networking TS were much
lower level than what it is, at a different abstraction level. But that
ship has sailed.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b4e5396c-28cc-4b02-9409-92dab7a464f8%40isocpp.org.

------=_Part_5732_1206810819.1502763777678
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><=
/div><div>The byte range locking API is so severely broken in POSIX as to m=
ake it impossible to write correct code with it.</div><div><br></div><div>I=
t is possible to write correct code if and only if:</div><div><br></div><di=
v>1. If you control all file descriptors in the entire process.</div><div><=
br></div></div></blockquote><div>why wouldn&#39;t you? or rather why would =
you think it was a good idea not to if you are trying to lock things?<br></=
div></div></blockquote><div><br></div><div>Almost no software today doesn&#=
39;t make extensive use of third party libraries, often with source code wh=
ich cannot be easily modified.</div><div><br></div><div>And due to POSIX dr=
opping all byte range locks as soon as <i>any</i>=C2=A0fd to that inode is =
closed, it makes byte range locks inherently problematic.</div><div><br></d=
iv><div>Consider for example an implementation of filesystem::path::exists(=
) which tries to open the path to test for existence. It would open and the=
n close a fd. If any code elsewhere in the process has byte range locks ope=
n on that inode, they get dropped.</div><div><br></div><div>Before you say =
&quot;just use stat() then&quot;, you can&#39;t in many cases e.g. if the f=
ilesystem is permuting randomly, because then you can&#39;t use paths at al=
l. Also, incidentally, there is nothing stopping stat() being implemented b=
y your libc as open()-fstat()-close() like it must be on Windows. Again, ga=
me over thanks to the design of POSIX byte range locks.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
</div><div>2. Files are never big.</div><div><br></div></div></blockquote><=
div>The reason for this one is less clear? performance perhaps? How big is =
big?<br></div></div></blockquote><div><br></div><div>struct flock due to so=
me amazing bad design uses <i>signed</i>=C2=A0values, thus rendering the to=
p half of your file unlockable.</div><div><br></div><div>You might think th=
at not important. For filesystem algorithm programmers who might use the en=
tire 64 bit space as an open hash table using sparse storage and hole punch=
ing, it&#39;s a showstopper.</div><div><br></div><div>I&#39;ve also seen im=
plementations fail at offsets after 1&lt;&lt;62 rather than 1&lt;&lt;63. Al=
most certainly a bug. But not comforting.</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>3. Files =
are never on a network drive.</div><div><br></div></div></blockquote><div>Y=
es. File locking 101 - don&#39;t use NFS or Samba. Although allegedly it mi=
ght work better on NFS4 which no-one has properly implemented yet.<br>I hav=
en&#39;t tried it on other remote file systems like sshfs. But I&#39;m sure=
 it would be &#39;interesting&#39;.<br></div></div></blockquote><div><br></=
div><div>Windows-type oplocks, if implemented correctly, are a much better =
design.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div></div><div>4. You don&#39;t care about pathological =
performance occurring (like, single digit grants per second).</div><div><br=
></div></div></blockquote><div>That sounds like it should be the program&#3=
9;s fault for locking too often. i.e. poor design<br></div></div></blockquo=
te><div><br></div><div>No, it&#39;s poor quality of implementation in some =
kernels and/or filing systems. In some cases they scale exponentially <i>in=
verse </i>to physical CPU count for example. Wonderful.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></di=
v><div>5. You don&#39;t use threads.</div><div><br></div></div></blockquote=
><div>Just be careful about which thread is doing the locking. Its an issue=
 as with many other shareable resources.<br></div></div></blockquote><div><=
br></div><div>It&#39;s not that.</div><div><br></div><div>POSIX byte range =
locks are per-inode, and don&#39;t detect attempts to lock the same region =
twice, rather they just ignore the second attempt and then release too earl=
y.</div><div><br></div><div>You&#39;ll probably say now that better design =
of your code would fix this. But you don&#39;t control the threads in your =
process increasingly any more, various third party libraries will spin up t=
hreads and go run stuff in the background out of your control.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv></div><div>6. You don&#39;t care about power consumption.</div><div><br>=
</div></div></blockquote><div>This one makes little sense to me. Even on an=
 embedded system it should be a case of flipping a few bit and checking if =
they&#39;re flipped.<br></div></div></blockquote><div><br></div><div>POSIX =
byte range locks give you exactly two choices: block until lock granted, or=
 return immediately.</div><div><br></div><div>You can&#39;t wait for a time=
out. You can&#39;t be notified when it&#39;s become free. You can&#39;t do =
other work whilst being blocked.</div><div><br></div><div>Thus you end up e=
ither spinning on the lock burning CPU, or launching kernel threads for the=
 sole purpose of waiting on the lock asynchronously.</div><div><br></div><d=
iv>This hits battery life badly on mobile devices. Lock files are actually =
cheaper on power budget, which is sad.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>7. You don&#=
39;t switch between shared and exclusive on non-identical ranges.</div><div=
><br></div></div></blockquote><div>That sounds like a potentially bad desig=
n too.<br></div></div></blockquote><div><br></div><div>My issue is the lack=
 of specification of atomicity. Implementations don&#39;t say whether share=
d to exclusive upgrades are atomic, for identical ranges or overlapping ran=
ges.</div><div><br></div><div>It&#39;s a common use case to have a region l=
ocked for shared use, then you want to lock some or all of it for exclusive=
 use without anybody else modifying it before the exclusive lock is granted=
.. The POSIX API isn&#39;t fit for this purpose, it splits and replaces lock=
s instead of laying exclusive over shared. Unhelpful.</div><div><br></div><=
div>You can&#39;t upgrade locks at all on Windows interestingly, but you ca=
n atomically downgrade them i.e. exclusive -&gt; shared atomically. This is=
n&#39;t as useful, but at least the behaviour is guaranteed.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
</div><div>8. You never recurse into code which needs to take a lock whilst=
 holding a lock.</div><div><br></div></div></blockquote><div>Don&#39;t dead=
lock. Multithreading 101 <br></div></div></blockquote><div><br></div><div>Y=
ou don&#39;t always control such code. What we&#39;d much prefer to see is =
EDEADLK being returned.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><div>9. You can guarantee no thi=
rd party is permuting the bit of filesystem you are using.</div><div><br></=
div></div></blockquote><div>Yes. File locking is for interprocess synchroni=
sation. You have to be in control of the processes involved in that.<br></d=
iv></div></blockquote><div><br></div><div>A major attack vector is generati=
ng races by maliciously fiddling with filesystem under IPC usage. TOCTOU et=
c</div><div><br></div><div>You might say &quot;set perms etc&quot; but in f=
act all that is unnecessary with a non-broken design. I hate to keep chirpi=
ng on about Windows, but it won&#39;t let anybody permute part of a filesys=
tem being used for synchronisation, thus eliminating TOCTOU et al entirely.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div><div>But if you can meet all those conditions, then alm=
ost any other form of synchronisation is better and faster. The sole thing =
which byte range locks have which is useful is that they auto-release if th=
e holding process suddenly exits. That&#39;s it.</div></div></blockquote><d=
iv><br>Wouldn&#39;t a lot of other forms of synchronisation have to re-inve=
nt advisory locking for themselves to do this? <br></div></div></blockquote=
><div><br></div><div>If the kernel supplied implementation is really lousy =
- and everywhere but FreeBSD it is - then you&#39;re better off.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I wo=
uld not trust them to work correctly on a different platform out of the box=
 or even a different file-system<br>on same platform. That doesn&#39;t make=
 it a bad thing to do. <br>They can be made a little more portable with eff=
ort.<br></div></div></blockquote><div><br></div><div>AFIO provides four imp=
lementations of afio::algorithm::shared_fs_<wbr>mutex. It makes use of byte=
 range locks to implement those, but mostly solely as sentinels for detecti=
ng sudden process exit by another process holding a lock.</div><div><br></d=
iv></div></blockquote><div>Your need for locks here seems to agree with my =
assessment above? <br></div></div></blockquote><div><br></div><div>When you=
 have multiple processes working on the same data, often you need to synchr=
onise. You try not to of course, you exploit the natural synchronisation bu=
ilt into i/o which is actually finally viable as of just these past months =
thanks to Microsoft fixing Windows to follow POSIX i/o concurrency guarante=
es. You need the very latest Windows 10 however, and a pretty recent Linux =
kernel. But it does work, and it&#39;s portable-ish.</div><div><br></div><d=
iv>AFIO uses a list based system for its locking algorithms, so process A s=
ays it&#39;ll be locking 5, 22 and 13. Process B says it&#39;ll be locking =
6, 99, and 13. The synchronisation will happen on the 13.</div><div><br></d=
iv><div>The numbers are arbitrary and mean whatever the application chooses=
 them to mean. Under the bonnet, the four implementations have very differe=
nt approaches to implementation. Some have amazing performance but are anti=
-social. Others scale amazingly. Some are NFS/Samba friendly. Some are shar=
ed memory only.</div><div><br></div><div>afio::shared_fs_mutex is an abstra=
ct base class, so runtime code can swap implementations and higher level co=
de doesn&#39;t need to care how the locking works.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>=
Now, Windows on the other hand really nailed byte range locks beautifully. =
Correct design. Amazing performance, Scales beautifully. Doesn&#39;t burn t=
he CPU. Works with threads. Async API. POSIX literally should take the NT b=
yte range lock design and use it verbatim. It&#39;s the right design. Shame=
 about the mandatory locking though, choice of advisory or mandatory would =
have been better.</div><div>=C2=A0</div></div></blockquote><div>That is not=
 something I often here about a Windows API but it could perhaps be a Windo=
ws person versus Unix person thing?<br>Care to elaborate?<br></div></div></=
blockquote><div><br></div><div>The Win32 API is generally pants.</div><div>=
<br></div><div>But the NT kernel API is lovely. It&#39;s really what VMS 6.=
0 would have been of course had that team stayed at Digital. Such a lovely =
kernel API design, really well thought through, and so very polished. I fin=
d it a joy to program in, but then I always liked VMS&#39;s design language=
..</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><br></div><div>Unless they&#39;ve removed it, the Networking TS should im=
plement iostreams integration for pipes. ASIO certainly does. If it&#39;s s=
till there, then you&#39;re covered by the TS and can untick that use case =
too.</div><div><br></div><div>Niall</div><div><br></div></div></blockquote>=
<div><br>Pipes was never ticked for this proposal.<br><br>Pipe doesn&#39;t =
appear in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
7/n4656.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2F=
sc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fn4656.pdf\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHIVIi6XOtUni-jZ5Y3pXFov3k1QA&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fn4656.pdf\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNHIVIi6XOtUni-jZ5Y3pXFov3k1QA&#39;;return true;">http://=
www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2017/<wbr>n4656.pdf</a> ot=
her than in reference to sigpipe.<br>But I think ASIO was split into bits s=
o they might be in another proposal somewhere.<br><br></div></div></blockqu=
ote><div>I think pipe support makes far more sense next to sockets than to =
files.</div><div><br></div><div>Shame about the removal. I have always wish=
ed the Networking TS were much lower level than what it is, at a different =
abstraction level. But that ship has sailed.</div><div><br></div><div>Niall=
</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b4e5396c-28cc-4b02-9409-92dab7a464f8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b4e5396c-28cc-4b02-9409-92dab7a464f8=
%40isocpp.org</a>.<br />

------=_Part_5732_1206810819.1502763777678--

------=_Part_5731_1500584455.1502763777678--

.

On Monday, 14 August 2017 18:02:57 PDT tortoise741@gmail.com wrote:
> On Tuesday, 15 August 2017 01:55:46 UTC+1, Thiago Macieira wrote:
> > On Monday, 14 August 2017 17:47:06 PDT torto...@gmail.com <javascript:>
> >
> > wrote:
> > > > 1. If you control all file descriptors in the entire process.
> > >
> > >  why wouldn't you? or rather why would you think it was a good idea not
> >
> > to
> >
> > > if you are trying to lock things?
> >
> > When you write a library, you don't control the rest of the process.
>
> True but you delegate the decision to your library's users.
> Or better yet let them set the locking policy on your library.

Easier said than done.

It's ok to say something like "don't install a signal handler for SIGPIPE",
since most applications won't do it and any libraries will most likely just
re-ignore it.

It's probably ok to say "don't use getenv/putenv because it's not thread-safe,
use qgetnev and qputenv because they have an internal mutex".

It's not ok to say "don't open other file descriptors". That's REALLY not
something any application has control over.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/11789213.tpSbSFajOm%40tjmaciei-mobl1.

.

On Monday, 14 August 2017 19:22:57 PDT Niall Douglas wrote:
> Consider for example an implementation of filesystem::path::exists() which
> tries to open the path to test for existence. It would open and then close
> a fd. If any code elsewhere in the process has byte range locks open on
> that inode, they get dropped.

Why would it open instead of access() with F_OK?

> Before you say "just use stat() then", you can't in many cases e.g. if the
> filesystem is permuting randomly, because then you can't use paths at all.

The problem here is the attempt to see if the file exists. Why do you want to
know that? If the application wants to know if it can open a file, it should
try to open the file, instead of checking first if it can exists, as you can't
open a file that doesn't exist.

That leads to TOCTOU attacks.

> Also, incidentally, there is nothing stopping stat() being implemented by
> your libc as open()-fstat()-close() like it must be on Windows. Again, game
> over thanks to the design of POSIX byte range locks.

It might be implemented on Windows by way of a CreateFile() call (you need a
handle to get some information), but it doesn't follow that you get a file
descriptor from it. And you said yourself that Windows does implement proper
locking, so I don't see how POSIX's behaviour would apply.

That said, you do have a point: no one in any non-trivial application can
control all the file descriptors.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1820998.RsJxD3lZCq%40tjmaciei-mobl1.

.

------=_Part_5659_1593714812.1502781441020
Content-Type: multipart/alternative;
 boundary="----=_Part_5660_771926344.1502781441020"

------=_Part_5660_771926344.1502781441020
Content-Type: text/plain; charset="UTF-8"



On Tuesday, 15 August 2017 03:22:57 UTC+1, Niall Douglas wrote:
>
>
>>>
>>> The byte range locking API is so severely broken in POSIX as to make it
>>> impossible to write correct code with it.
>>>
>>> It is possible to write correct code if and only if:
>>>
>>> 1. If you control all file descriptors in the entire process.
>>>
>>> why wouldn't you? or rather why would you think it was a good idea not
>> to if you are trying to lock things?
>>
>
> Almost no software today doesn't make extensive use of third party
> libraries, often with source code which cannot be easily modified.
>
> And due to POSIX dropping all byte range locks as soon as *any* fd to
> that inode is closed, it makes byte range locks inherently problematic.
>
> Consider for example an implementation of filesystem::path::exists() which
> tries to open the path to test for existence. It would open and then close
> a fd. If any code elsewhere in the process has byte range locks open on
> that inode, they get dropped.
>
> Before you say "just use stat() then", you can't in many cases e.g. if the
> filesystem is permuting randomly, because then you can't use paths at all.
> Also, incidentally, there is nothing stopping stat() being implemented by
> your libc as open()-fstat()-close() like it must be on Windows. Again, game
> over thanks to the design of POSIX byte range locks.
>
>
I would think not but does that also apply if using access()?

but there are a couple of questions here. Why would you need check if a
file exists if you've just locked it? similarly why would you be separately
opening and closing the same file descriptor?

This sounds like a multi-threading issue. I'd agree that posix is weaker
where threads are concerned as the locking and signalling APIs predate that.
The expectation is that you use processes instead. Its a fundamentally
different philosophy than on windows where processes are expensive and
threads are king.
Processes are much cheaper on Linux than windows (that is of course not
mandated by posix).

This does create a lot of difficulty in trying to write an application that
is portable between windows and Linux.

However, you can work around that by designating only one thread is
responsible for each lock. It works a bit less well for signals.



>>
>>> 2. Files are never big.
>>>
>>> The reason for this one is less clear? performance perhaps? How big is
>> big?
>>
>
> struct flock due to some amazing bad design uses *signed* values, thus
> rendering the top half of your file unlockable.
>
> You might think that not important. For filesystem algorithm programmers
> who might use the entire 64 bit space as an open hash table using sparse
> storage and hole punching, it's a showstopper.
>
> I've also seen implementations fail at offsets after 1<<62 rather than
> 1<<63. Almost certainly a bug. But not comforting.
>
>
I guess this would be because you can lock relative to the current file
position so a signed value is necessary?

Using a 2^64 address space as a hash table strikes me as a bit of a
specialist use case that they wouldn't have had in mind when posix was
defined.
But I agree a improved design could support such use cases better.


>>
>>> 3. Files are never on a network drive.
>>>
>>> Yes. File locking 101 - don't use NFS or Samba. Although allegedly it
>> might work better on NFS4 which no-one has properly implemented yet.
>> I haven't tried it on other remote file systems like sshfs. But I'm sure
>> it would be 'interesting'.
>>
>
> Windows-type oplocks, if implemented correctly, are a much better design.
>
>
The descriptions here
(https://msdn.microsoft.com/en-us/library/windows/desktop/aa365713(v=vs.85).aspx)
a little off putting
The description of locking a file by using a function called CreateFile()
twice on the same file is far from an intuitive API.

Of course it's the semantics that are of interest here and I need to read
more to grok the design.

"For example, in the execution of a batch file, the batch file may be
opened and closed once for each line of the file. A batch opportunistic
lock opens the batch file on the server and keeps it open. As the command
processor "opens" and "closes" the batch file, the network redirector
intercepts the open and close commands."

spoken like a OS that isn't littered with thousands of little scripting
languages :).


>>
>>> 4. You don't care about pathological performance occurring (like, single
>>> digit grants per second).
>>>
>>> That sounds like it should be the program's fault for locking too often.
>> i.e. poor design
>>
>
> No, it's poor quality of implementation in some kernels and/or filing
> systems. In some cases they scale exponentially *inverse *to physical CPU
> count for example. Wonderful.
>
>
That would be a bug report then. Though one requiring a complete re-design
is quite hard to fix.


>
>>
>>> 5. You don't use threads.
>>>
>>> Just be careful about which thread is doing the locking. Its an issue as
>> with many other shareable resources.
>>
>
> It's not that.
>
> POSIX byte range locks are per-inode, and don't detect attempts to lock
> the same region twice, rather they just ignore the second attempt and then
> release too early.
>
> You'll probably say now that better design of your code would fix this.
> But you don't control the threads in your process increasingly any more,
> various third party libraries will spin up threads and go run stuff in the
> background out of your control.
>
>
Do you have any specific examples in mind? This sounds like the realm of
map/reduce frameworks but perhaps you are thinking along different lines.

>
>>
>>> 6. You don't care about power consumption.
>>>
>>> This one makes little sense to me. Even on an embedded system it should
>> be a case of flipping a few bit and checking if they're flipped.
>>
>
> POSIX byte range locks give you exactly two choices: block until lock
> granted, or return immediately.
>
> You can't wait for a timeout. You can't be notified when it's become free.
> You can't do other work whilst being blocked.
>
> Thus you end up either spinning on the lock burning CPU, or launching
> kernel threads for the sole purpose of waiting on the lock asynchronously.
>
> That is a notable absence.


> This hits battery life badly on mobile devices. Lock files are actually
> cheaper on power budget, which is sad.
>
>
Surely a sleeping thread consumes little or no power?

>
>>
>>> 7. You don't switch between shared and exclusive on non-identical ranges.
>>>
>>> That sounds like a potentially bad design too.
>>
>
> My issue is the lack of specification of atomicity. Implementations don't
> say whether shared to exclusive upgrades are atomic, for identical ranges
> or overlapping ranges.
>
> It's a common use case to have a region locked for shared use, then you
> want to lock some or all of it for exclusive use without anybody else
> modifying it before the exclusive lock is granted. The POSIX API isn't fit
> for this purpose, it splits and replaces locks instead of laying exclusive
> over shared. Unhelpful.
>
> You can't upgrade locks at all on Windows interestingly, but you can
> atomically downgrade them i.e. exclusive -> shared atomically. This isn't
> as useful, but at least the behaviour is guaranteed.
>
>
>>
>>
>>> 8. You never recurse into code which needs to take a lock whilst holding
>>> a lock.
>>>
>>> Don't deadlock. Multithreading 101
>>
>
> You don't always control such code. What we'd much prefer to see is
> EDEADLK being returned.
>
>
>>
>>
>>> 9. You can guarantee no third party is permuting the bit of filesystem
>>> you are using.
>>>
>>> Yes. File locking is for interprocess synchronisation. You have to be in
>> control of the processes involved in that.
>>
>
> A major attack vector is generating races by maliciously fiddling with
> filesystem under IPC usage. TOCTOU etc
>
> You might say "set perms etc" but in fact all that is unnecessary with a
> non-broken design. I hate to keep chirping on about Windows, but it won't
> let anybody permute part of a filesystem being used for synchronisation,
> thus eliminating TOCTOU et al entirely.
>
>
>>
>>
>>> But if you can meet all those conditions, then almost any other form of
>>> synchronisation is better and faster. The sole thing which byte range locks
>>> have which is useful is that they auto-release if the holding process
>>> suddenly exits. That's it.
>>>
>>
>> Wouldn't a lot of other forms of synchronisation have to re-invent
>> advisory locking for themselves to do this?
>>
>
> If the kernel supplied implementation is really lousy - and everywhere but
> FreeBSD it is - then you're better off.
>

Is that down to bugs or does FreeBSD tighten up and improve on the basic
posix specification?

>
>
>>
>>>
>>>> I would not trust them to work correctly on a different platform out of
>>>> the box or even a different file-system
>>>> on same platform. That doesn't make it a bad thing to do.
>>>> They can be made a little more portable with effort.
>>>>
>>>
>>> AFIO provides four implementations of afio::algorithm::shared_fs_mutex.
>>> It makes use of byte range locks to implement those, but mostly solely as
>>> sentinels for detecting sudden process exit by another process holding a
>>> lock.
>>>
>>> Your need for locks here seems to agree with my assessment above?
>>
>
> When you have multiple processes working on the same data, often you need
> to synchronise. You try not to of course, you exploit the natural
> synchronisation built into i/o which is actually finally viable as of just
> these past months thanks to Microsoft fixing Windows to follow POSIX i/o
> concurrency guarantees. You need the very latest Windows 10 however, and a
> pretty recent Linux kernel. But it does work, and it's portable-ish.
>
> AFIO uses a list based system for its locking algorithms, so process A
> says it'll be locking 5, 22 and 13. Process B says it'll be locking 6, 99,
> and 13. The synchronisation will happen on the 13.
>
> The numbers are arbitrary and mean whatever the application chooses them
> to mean. Under the bonnet, the four implementations have very different
> approaches to implementation. Some have amazing performance but are
> anti-social. Others scale amazingly. Some are NFS/Samba friendly. Some are
> shared memory only.
>
> afio::shared_fs_mutex is an abstract base class, so runtime code can swap
> implementations and higher level code doesn't need to care how the locking
> works.
>
>
Have you considered trying to specify an improved OS APIs that could be
aspired to?
It is exactly this kind of implementation experience from which such things
tend to drop out.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/31e71f26-0252-45e6-879f-24ac58a9e316%40isocpp.org.

------=_Part_5660_771926344.1502781441020
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, 15 August 2017 03:22:57 UTC+1, Niall D=
ouglas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br><div><br></div><div>The byte ra=
nge locking API is so severely broken in POSIX as to make it impossible to =
write correct code with it.</div><div><br></div><div>It is possible to writ=
e correct code if and only if:</div><div><br></div><div>1. If you control a=
ll file descriptors in the entire process.</div><div><br></div></div></bloc=
kquote><div>why wouldn&#39;t you? or rather why would you think it was a go=
od idea not to if you are trying to lock things?<br></div></div></blockquot=
e><div><br></div><div>Almost no software today doesn&#39;t make extensive u=
se of third party libraries, often with source code which cannot be easily =
modified.</div><div><br></div><div>And due to POSIX dropping all byte range=
 locks as soon as <i>any</i>=C2=A0fd to that inode is closed, it makes byte=
 range locks inherently problematic.</div><div><br></div><div>Consider for =
example an implementation of filesystem::path::exists() which tries to open=
 the path to test for existence. It would open and then close a fd. If any =
code elsewhere in the process has byte range locks open on that inode, they=
 get dropped.</div><div><br></div><div>Before you say &quot;just use stat()=
 then&quot;, you can&#39;t in many cases e.g. if the filesystem is permutin=
g randomly, because then you can&#39;t use paths at all. Also, incidentally=
, there is nothing stopping stat() being implemented by your libc as open()=
-fstat()-close() like it must be on Windows. Again, game over thanks to the=
 design of POSIX byte range locks.</div><div>=C2=A0</div></div></blockquote=
><div>I would think not but does that also apply if using access()?=C2=A0 <=
br><br>but there are a couple of questions here. Why would you need check i=
f a file exists if you&#39;ve just locked it? similarly why would you be se=
parately opening and closing the same file descriptor?<br><br>This sounds l=
ike a multi-threading issue. I&#39;d agree that posix is weaker where threa=
ds are concerned as the locking and signalling APIs predate that.<br>The ex=
pectation is that you use processes instead. Its a fundamentally different =
philosophy than on windows where processes are expensive and threads are ki=
ng.<br>Processes are much cheaper on Linux than windows (that is of course =
not mandated by posix).<br><br>This does create a lot of difficulty in tryi=
ng to write an application that is portable between windows and Linux.<br><=
br>However, you can work around that by designating only one thread is resp=
onsible for each lock. It works a bit less well for signals.<br><br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>2. Files =
are never big.</div><div><br></div></div></blockquote><div>The reason for t=
his one is less clear? performance perhaps? How big is big?<br></div></div>=
</blockquote><div><br></div><div>struct flock due to some amazing bad desig=
n uses <i>signed</i>=C2=A0values, thus rendering the top half of your file =
unlockable.</div><div><br></div><div>You might think that not important. Fo=
r filesystem algorithm programmers who might use the entire 64 bit space as=
 an open hash table using sparse storage and hole punching, it&#39;s a show=
stopper.</div><div><br></div><div>I&#39;ve also seen implementations fail a=
t offsets after 1&lt;&lt;62 rather than 1&lt;&lt;63. Almost certainly a bug=
.. But not comforting.</div><div>=C2=A0</div></div></blockquote><div>I guess=
 this would be because you can lock relative to the current file position s=
o a signed value is necessary?<br><br>Using a 2^64 address space as a hash =
table strikes me as a bit of a specialist use case that they wouldn&#39;t h=
ave had in mind when posix was defined.<br>But I agree a improved design co=
uld support such use cases better.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div></div><div>3. Files are never on a network drive.</d=
iv><div><br></div></div></blockquote><div>Yes. File locking 101 - don&#39;t=
 use NFS or Samba. Although allegedly it might work better on NFS4 which no=
-one has properly implemented yet.<br>I haven&#39;t tried it on other remot=
e file systems like sshfs. But I&#39;m sure it would be &#39;interesting&#3=
9;.<br></div></div></blockquote><div><br></div><div>Windows-type oplocks, i=
f implemented correctly, are a much better design.</div><div>=C2=A0</div></=
div></blockquote><div>The descriptions here (https://msdn.microsoft.com/en-=
us/library/windows/desktop/aa365713(v=3Dvs.85).aspx) a little off putting<b=
r>The description of locking a file by using a function called CreateFile()=
 twice on the same file is far from an intuitive API.<br><br>Of course it&#=
39;s the semantics that are of interest here and I need to read more to gro=
k the design. <br><br>&quot;For example, in the execution of a batch file, =
the batch file may be=20
opened and closed once for each line of the file. A batch opportunistic=20
lock opens the batch file on the server and keeps it open. As the=20
command processor &quot;opens&quot; and &quot;closes&quot; the batch file, =
the network=20
redirector intercepts the open and close commands.&quot;<br>=C2=A0<br>spoke=
n like a OS that isn&#39;t littered with thousands of little scripting lang=
uages :).<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></di=
v><div>4. You don&#39;t care about pathological performance occurring (like=
, single digit grants per second).</div><div><br></div></div></blockquote><=
div>That sounds like it should be the program&#39;s fault for locking too o=
ften. i.e. poor design<br></div></div></blockquote><div><br></div><div>No, =
it&#39;s poor quality of implementation in some kernels and/or filing syste=
ms. In some cases they scale exponentially <i>inverse </i>to physical CPU c=
ount for example. Wonderful.</div><div>=C2=A0</div></div></blockquote><div>=
That would be a bug report then. Though one requiring a complete re-design =
is quite hard to fix.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div></div><div>5. You don&#39;t use threads.</div><div><br></div></di=
v></blockquote><div>Just be careful about which thread is doing the locking=
.. Its an issue as with many other shareable resources.<br></div></div></blo=
ckquote><div><br></div><div>It&#39;s not that.</div><div><br></div><div>POS=
IX byte range locks are per-inode, and don&#39;t detect attempts to lock th=
e same region twice, rather they just ignore the second attempt and then re=
lease too early.</div><div><br></div><div>You&#39;ll probably say now that =
better design of your code would fix this. But you don&#39;t control the th=
reads in your process increasingly any more, various third party libraries =
will spin up threads and go run stuff in the background out of your control=
..</div><div>=C2=A0</div></div></blockquote><div>Do you have any specific ex=
amples in mind? This sounds like the realm of map/reduce frameworks but per=
haps you are thinking along different lines.<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div></div><div>6. You don&#39;t care about power con=
sumption.</div><div><br></div></div></blockquote><div>This one makes little=
 sense to me. Even on an embedded system it should be a case of flipping a =
few bit and checking if they&#39;re flipped.<br></div></div></blockquote><d=
iv><br></div><div>POSIX byte range locks give you exactly two choices: bloc=
k until lock granted, or return immediately.</div><div><br></div><div>You c=
an&#39;t wait for a timeout. You can&#39;t be notified when it&#39;s become=
 free. You can&#39;t do other work whilst being blocked.</div><div><br></di=
v><div>Thus you end up either spinning on the lock burning CPU, or launchin=
g kernel threads for the sole purpose of waiting on the lock asynchronously=
..</div><div><br></div></div></blockquote><div>That is a notable absence.<br=
>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div></div><div>This hits battery life badly on mobile devices. Lock fi=
les are actually cheaper on power budget, which is sad.</div><div>=C2=A0</d=
iv></div></blockquote><div>Surely a sleeping thread consumes little or no p=
ower?<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>7=
.. You don&#39;t switch between shared and exclusive on non-identical ranges=
..</div><div><br></div></div></blockquote><div>That sounds like a potentiall=
y bad design too.<br></div></div></blockquote><div><br></div><div>My issue =
is the lack of specification of atomicity. Implementations don&#39;t say wh=
ether shared to exclusive upgrades are atomic, for identical ranges or over=
lapping ranges.</div><div><br></div><div>It&#39;s a common use case to have=
 a region locked for shared use, then you want to lock some or all of it fo=
r exclusive use without anybody else modifying it before the exclusive lock=
 is granted. The POSIX API isn&#39;t fit for this purpose, it splits and re=
places locks instead of laying exclusive over shared. Unhelpful.</div><div>=
<br></div></div></blockquote><div></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div></div><div>You can&#39;t upgrade locks at a=
ll on Windows interestingly, but you can atomically downgrade them i.e. exc=
lusive -&gt; shared atomically. This isn&#39;t as useful, but at least the =
behaviour is guaranteed.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div></div><div>8. You never recurse into code =
which needs to take a lock whilst holding a lock.</div><div><br></div></div=
></blockquote><div>Don&#39;t deadlock. Multithreading 101 <br></div></div><=
/blockquote><div><br></div><div>You don&#39;t always control such code. Wha=
t we&#39;d much prefer to see is EDEADLK being returned.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>9. You can guarantee no third party is permuting the bit of filesystem you=
 are using.</div><div><br></div></div></blockquote><div>Yes. File locking i=
s for interprocess synchronisation. You have to be in control of the proces=
ses involved in that.<br></div></div></blockquote><div><br></div><div>A maj=
or attack vector is generating races by maliciously fiddling with filesyste=
m under IPC usage. TOCTOU etc</div><div><br></div><div>You might say &quot;=
set perms etc&quot; but in fact all that is unnecessary with a non-broken d=
esign. I hate to keep chirping on about Windows, but it won&#39;t let anybo=
dy permute part of a filesystem being used for synchronisation, thus elimin=
ating TOCTOU et al entirely.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><div>But if you can meet all tho=
se conditions, then almost any other form of synchronisation is better and =
faster. The sole thing which byte range locks have which is useful is that =
they auto-release if the holding process suddenly exits. That&#39;s it.</di=
v></div></blockquote><div><br>Wouldn&#39;t a lot of other forms of synchron=
isation have to re-invent advisory locking for themselves to do this? <br><=
/div></div></blockquote><div><br></div><div>If the kernel supplied implemen=
tation is really lousy - and everywhere but FreeBSD it is - then you&#39;re=
 better off.</div><div></div></div></blockquote><div><br>Is that down to bu=
gs or does FreeBSD tighten up and improve on the basic posix specification?=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I would=
 not trust them to work correctly on a different platform out of the box or=
 even a different file-system<br>on same platform. That doesn&#39;t make it=
 a bad thing to do. <br>They can be made a little more portable with effort=
..<br></div></div></blockquote><div><br></div><div>AFIO provides four implem=
entations of afio::algorithm::shared_fs_<wbr>mutex. It makes use of byte ra=
nge locks to implement those, but mostly solely as sentinels for detecting =
sudden process exit by another process holding a lock.</div><div><br></div>=
</div></blockquote><div>Your need for locks here seems to agree with my ass=
essment above? <br></div></div></blockquote><div><br></div><div>When you ha=
ve multiple processes working on the same data, often you need to synchroni=
se. You try not to of course, you exploit the natural synchronisation built=
 into i/o which is actually finally viable as of just these past months tha=
nks to Microsoft fixing Windows to follow POSIX i/o concurrency guarantees.=
 You need the very latest Windows 10 however, and a pretty recent Linux ker=
nel. But it does work, and it&#39;s portable-ish.</div><div><br></div><div>=
AFIO uses a list based system for its locking algorithms, so process A says=
 it&#39;ll be locking 5, 22 and 13. Process B says it&#39;ll be locking 6, =
99, and 13. The synchronisation will happen on the 13.</div><div><br></div>=
<div>The numbers are arbitrary and mean whatever the application chooses th=
em to mean. Under the bonnet, the four implementations have very different =
approaches to implementation. Some have amazing performance but are anti-so=
cial. Others scale amazingly. Some are NFS/Samba friendly. Some are shared =
memory only.</div><div><br></div><div>afio::shared_fs_mutex is an abstract =
base class, so runtime code can swap implementations and higher level code =
doesn&#39;t need to care how the locking works.</div><div>=C2=A0</div></div=
></blockquote><div>Have you considered trying to specify an improved OS API=
s that could be aspired to?<br>It is exactly this kind of implementation ex=
perience from which such things tend to drop out. </div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/31e71f26-0252-45e6-879f-24ac58a9e316%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/31e71f26-0252-45e6-879f-24ac58a9e316=
%40isocpp.org</a>.<br />

------=_Part_5660_771926344.1502781441020--

------=_Part_5659_1593714812.1502781441020--

.

------=_Part_6198_534544610.1502810382678
Content-Type: multipart/alternative;
 boundary="----=_Part_6199_1359121378.1502810382678"

------=_Part_6199_1359121378.1502810382678
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 15, 2017 at 3:49:01 AM UTC+1, Thiago Macieira wrote:
>
> On Monday, 14 August 2017 19:22:57 PDT Niall Douglas wrote:
> > Consider for example an implementation of filesystem::path::exists()
> which
> > tries to open the path to test for existence. It would open and then
> close
> > a fd. If any code elsewhere in the process has byte range locks open on
> > that inode, they get dropped.
>
> Why would it open instead of access() with F_OK?
>

access() is an enormous security hole. I really wish it could be eliminated.

open()-close() is slow, but safe. Indeed Windows internally does exactly
this when checking for a file to exist.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7a77a54f-7ebc-4a80-9f24-de193563cad2%40isocpp.org.

------=_Part_6199_1359121378.1502810382678
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 15, 2017 at 3:49:01 AM UTC+1, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, 14 Aug=
ust 2017 19:22:57 PDT Niall Douglas wrote:
<br>&gt; Consider for example an implementation of filesystem::path::exists=
() which
<br>&gt; tries to open the path to test for existence. It would open and th=
en close
<br>&gt; a fd. If any code elsewhere in the process has byte range locks op=
en on
<br>&gt; that inode, they get dropped.
<br>
<br>Why would it open instead of access() with F_OK?
<br></blockquote><div><br></div><div>access() is an enormous security hole.=
 I really wish it could be eliminated.</div><div><br></div><div>open()-clos=
e() is slow, but safe. Indeed Windows internally does exactly this when che=
cking for a file to exist.</div><div><br></div><div>Niall</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7a77a54f-7ebc-4a80-9f24-de193563cad2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a77a54f-7ebc-4a80-9f24-de193563cad2=
%40isocpp.org</a>.<br />

------=_Part_6199_1359121378.1502810382678--

------=_Part_6198_534544610.1502810382678--

.

On Tuesday, 15 August 2017 08:19:42 PDT Niall Douglas wrote:
> access() is an enormous security hole. I really wish it could be eliminated.

Explain. Are you refering to a TOCTOU attack?

And how do you implement X_OK?

> open()-close() is slow, but safe. Indeed Windows internally does exactly
> this when checking for a file to exist.

For that matter, trying W_OK by opening for write is also a bad idea, since it
modifies the file (atime update) and could run afoul of sharing violation on
Windows.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/30718482.SR16gFt61r%40tjmaciei-mobl1.

.

------=_Part_6295_1536115422.1502812430977
Content-Type: multipart/alternative;
 boundary="----=_Part_6296_1345016454.1502812430978"

------=_Part_6296_1345016454.1502812430978
Content-Type: text/plain; charset="UTF-8"


>
>
> but there are a couple of questions here. Why would you need check if a
> file exists if you've just locked it? similarly why would you be separately
> opening and closing the same file descriptor?
>

It's more that other code, say in a library, may just happen to open-close
an inode you have byte range locks open on. At which point, all your locks
drop.


>
> This sounds like a multi-threading issue. I'd agree that posix is weaker
> where threads are concerned as the locking and signalling APIs predate that.
>

It has nothing to do with threads. It has to do with inability to prevent
different bits of code interacting in unpredictable ways.

Jeff ... (I forget his last name, he's well known in storage circles) has
implemented less broken POSIX locks into recent Linux kernels. They are
called OFD locks. They lock by fd, not by inode. A lot better, but still
with all the other remaining problems. On the Austin Working Group
reflector I have argued for completely new locks. Me and Jeff were supposed
to write a paper, but then I got in a work contract, and it fell by the
wayside.


> The expectation is that you use processes instead. Its a fundamentally
> different philosophy than on windows where processes are expensive and
> threads are king.
> Processes are much cheaper on Linux than windows (that is of course not
> mandated by posix).
>

That's a misconception. NT processes are actually just as light as POSIX
ones. You can fork a process at the NT kernel level no problem.

It's actually all the Win32 stuff. MSVCRT in particularly blows up
*spectacularly* if you fork it. But it could be easily fixed if Microsoft
wanted to. You'd then find COM, Advapi and all that would then blow up on
fork. The Win32 stuff was simply never designed for it.

If you run the Linux Subsystem for Windows, there you'll see fork working
lovely. I just wish they'd implement file locks for WSL, right now
databases just corrupt in front of you because the Linux syscall emulation
flat out lies.


>
> This does create a lot of difficulty in trying to write an application
> that is portable between windows and Linux.
>
> However, you can work around that by designating only one thread is
> responsible for each lock. It works a bit less well for signals.
>

Or just use AFIO which was designed for portable sub-1us latency filesystem
algorithms in modern i.e. threaded code, and is post a Boost peer review
already, so it's about one quarter of the way to getting into the standard
:)


>
>>
> The descriptions here (
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365713(v=vs.85).aspx)
> a little off putting
> The description of locking a file by using a function called CreateFile()
> twice on the same file is far from an intuitive API.
>
> Of course it's the semantics that are of interest here and I need to read
> more to grok the design.
>
> "For example, in the execution of a batch file, the batch file may be
> opened and closed once for each line of the file. A batch opportunistic
> lock opens the batch file on the server and keeps it open. As the command
> processor "opens" and "closes" the batch file, the network redirector
> intercepts the open and close commands."
>
> spoken like a OS that isn't littered with thousands of little scripting
> languages :).
>

Ignore the Microsoft documentation. Most of it is wrong.

Trust the Samba documentation and especially its code. It's correct.

Oplocks work very well over a reliable network, but go pathological if even
a little packet loss appears. But they're the right approach, they
distribute the locking across the network giving optimum (i.e. local)
performance whenever possible. Very clever.


>
>> No, it's poor quality of implementation in some kernels and/or filing
>> systems. In some cases they scale exponentially *inverse *to physical
>> CPU count for example. Wonderful.
>>
>>
> That would be a bug report then. Though one requiring a complete re-design
> is quite hard to fix.
>

The API provided meets the POSIX specification. So it'll be a wontfix.


>
>> If the kernel supplied implementation is really lousy - and everywhere
>> but FreeBSD it is - then you're better off.
>>
>
> Is that down to bugs or does FreeBSD tighten up and improve on the basic
> posix specification?
>

FreeBSD's kernel leadership really care about the filesystem. That hasn't
traditionally been the case in Linux.

FreeBSD contains lots of great improvements over POSIX e.g. kqueues, which
if it weren't for Linus then Linux would also have gained years ago because
it's the correct design. I really wish POSIX would just standardise it
already, but it's contentious. A lot of influential people oppose kqueues.

FreeBSD also contains a best in class file i/o implementation. Very close
to the POSIX spec. Very high quality implementation of locks etc. Async i/o
design throughout, auto DMA friendly like Windows, it's easy to write high
performance filesystem code for Windows and FreeBSD which performs very
similarly.

Linux is and has always been the worst to support of them all. Highly
nonconforming, lousy implementation of locks, doesn't implement O_SYNC
right, the list goes on. Though its O_DIRECT is now finally sane and can be
trusted, again, despite Linus' best efforts.

OS X is infamous for frequent showstopper bugs like writes to a mmap not
being written to disc ever. But once reported, they do fix them quick. And
apart from the awful async i/o implementation, OS X is pretty good
otherwise, though they took forever to implement the race free POSIX API.
Oh, and fsync is non blocking :(.


>
>> When you have multiple processes working on the same data, often you need
>> to synchronise. You try not to of course, you exploit the natural
>> synchronisation built into i/o which is actually finally viable as of just
>> these past months thanks to Microsoft fixing Windows to follow POSIX i/o
>> concurrency guarantees. You need the very latest Windows 10 however, and a
>> pretty recent Linux kernel. But it does work, and it's portable-ish.
>>
>> AFIO uses a list based system for its locking algorithms, so process A
>> says it'll be locking 5, 22 and 13. Process B says it'll be locking 6, 99,
>> and 13. The synchronisation will happen on the 13.
>>
>> The numbers are arbitrary and mean whatever the application chooses them
>> to mean. Under the bonnet, the four implementations have very different
>> approaches to implementation. Some have amazing performance but are
>> anti-social. Others scale amazingly. Some are NFS/Samba friendly. Some are
>> shared memory only.
>>
>> afio::shared_fs_mutex is an abstract base class, so runtime code can swap
>> implementations and higher level code doesn't need to care how the locking
>> works.
>>
>>
> Have you considered trying to specify an improved OS APIs that could be
> aspired to?
> It is exactly this kind of implementation experience from which such
> things tend to drop out.
>

I'm new to WG21, but have been involved in standards for a long time.
Indeed, I was once the SC22 mirror convenor for my country.

But ultimately it comes down to spare capacity. You see lots of progress
when I'm between contracts like now. But having been without income since
Christmas, another 12-18 months of paying work beckons soon during which
there will be no progress. Gotta go earn. I've been working on AFIO since
2012. I expect it won't land before WG21 until 2020 or so. Best I can do
without a sponsor.

And we can't persuade POSIX to change until some major implementation makes
the changes existing practice. C++ counts. So, if we standardise AFIO into
C++, that lets us fix POSIX. Until then they'll reject all changes as
having no existing practice.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a40e582c-7b5c-4bc4-ad8a-86ea8dc65eab%40isocpp.org.

------=_Part_6296_1345016454.1502812430978
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>=C2=A0<br>but there are a couple of questions here. Why would you =
need check if a file exists if you&#39;ve just locked it? similarly why wou=
ld you be separately opening and closing the same file descriptor?<br></div=
></div></blockquote><div><br></div><div>It&#39;s more that other code, say =
in a library, may just happen to open-close an inode you have byte range lo=
cks open on. At which point, all your locks drop.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>This so=
unds like a multi-threading issue. I&#39;d agree that posix is weaker where=
 threads are concerned as the locking and signalling APIs predate that.<br>=
</div></div></blockquote><div><br></div><div>It has nothing to do with thre=
ads. It has to do with inability to prevent different bits of code interact=
ing in unpredictable ways.</div><div><br></div><div>Jeff ... (I forget his =
last name, he&#39;s well known in storage circles) has implemented less bro=
ken POSIX locks into recent Linux kernels. They are called OFD locks. They =
lock by fd, not by inode. A lot better, but still with all the other remain=
ing problems. On the Austin Working Group reflector I have argued for compl=
etely new locks. Me and Jeff were supposed to write a paper, but then I got=
 in a work contract, and it fell by the wayside.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The expectat=
ion is that you use processes instead. Its a fundamentally different philos=
ophy than on windows where processes are expensive and threads are king.<br=
>Processes are much cheaper on Linux than windows (that is of course not ma=
ndated by posix).<br></div></div></blockquote><div><br></div><div>That&#39;=
s a misconception. NT processes are actually just as light as POSIX ones. Y=
ou can fork a process at the NT kernel level no problem.</div><div><br></di=
v><div>It&#39;s actually all the Win32 stuff. MSVCRT in particularly blows =
up <b>spectacularly</b>=C2=A0if you fork it. But it could be easily fixed i=
f Microsoft wanted to. You&#39;d then find COM, Advapi and all that would t=
hen blow up on fork. The Win32 stuff was simply never designed for it.</div=
><div><br></div><div>If you run the Linux Subsystem for Windows, there you&=
#39;ll see fork working lovely. I just wish they&#39;d implement file locks=
 for WSL, right now databases just corrupt in front of you because the Linu=
x syscall emulation flat out lies.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>This does create a lo=
t of difficulty in trying to write an application that is portable between =
windows and Linux.<br><br>However, you can work around that by designating =
only one thread is responsible for each lock. It works a bit less well for =
signals.<br></div></div></blockquote><div><br></div><div>Or just use AFIO w=
hich was designed for portable sub-1us latency filesystem algorithms in mod=
ern i.e. threaded code, and is post a Boost peer review already, so it&#39;=
s about one quarter of the way to getting into the standard :)</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div></=
div></blockquote><div>The descriptions here (<a href=3D"https://msdn.micros=
oft.com/en-us/library/windows/desktop/aa365713(v=3Dvs.85).aspx" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2=
Fdesktop%2Faa365713(v%3Dvs.85).aspx\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NFDwidwyK3WliQe_qg3kvzzIWcPfw&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://www.google.com/url?q\x3dhttps%3A%2F%2Fmsdn.microsoft.com%2Fen-us%=
2Flibrary%2Fwindows%2Fdesktop%2Faa365713(v%3Dvs.85).aspx\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNFDwidwyK3WliQe_qg3kvzzIWcPfw&#39;;return true;">https=
://msdn.microsoft.com/<wbr>en-us/library/windows/desktop/<wbr>aa365713(v=3D=
vs.85).aspx</a>) a little off putting<br>The description of locking a file =
by using a function called CreateFile() twice on the same file is far from =
an intuitive API.<br><br>Of course it&#39;s the semantics that are of inter=
est here and I need to read more to grok the design. <br><br>&quot;For exam=
ple, in the execution of a batch file, the batch file may be=20
opened and closed once for each line of the file. A batch opportunistic=20
lock opens the batch file on the server and keeps it open. As the=20
command processor &quot;opens&quot; and &quot;closes&quot; the batch file, =
the network=20
redirector intercepts the open and close commands.&quot;<br>=C2=A0<br>spoke=
n like a OS that isn&#39;t littered with thousands of little scripting lang=
uages :).<br></div></div></blockquote><div><br></div><div>Ignore the Micros=
oft documentation. Most of it is wrong.</div><div><br></div><div>Trust the =
Samba documentation and especially its code. It&#39;s correct.</div><div><b=
r></div><div>Oplocks work very well over a reliable network, but go patholo=
gical if even a little packet loss appears. But they&#39;re the right appro=
ach, they distribute the locking across the network giving optimum (i.e. lo=
cal) performance whenever possible. Very clever.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>No, it&#39;s po=
or quality of implementation in some kernels and/or filing systems. In some=
 cases they scale exponentially <i>inverse </i>to physical CPU count for ex=
ample. Wonderful.</div><div>=C2=A0</div></div></blockquote><div>That would =
be a bug report then. Though one requiring a complete re-design is quite ha=
rd to fix.<br></div></div></blockquote><div><br></div><div>The API provided=
 meets the POSIX specification. So it&#39;ll be a wontfix.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>If th=
e kernel supplied implementation is really lousy - and everywhere but FreeB=
SD it is - then you&#39;re better off.</div><div></div></div></blockquote><=
div><br>Is that down to bugs or does FreeBSD tighten up and improve on the =
basic posix specification?<br></div></div></blockquote><div><br></div><div>=
FreeBSD&#39;s kernel leadership really care about the filesystem. That hasn=
&#39;t traditionally been the case in Linux.</div><div><br></div><div>FreeB=
SD contains lots of great improvements over POSIX e.g. kqueues, which if it=
 weren&#39;t for Linus then Linux would also have gained years ago because =
it&#39;s the correct design. I really wish POSIX would just standardise it =
already, but it&#39;s contentious. A lot of influential people oppose kqueu=
es.</div><div><br></div><div>FreeBSD also contains a best in class file i/o=
 implementation. Very close to the POSIX spec. Very high quality implementa=
tion of locks etc. Async i/o design throughout, auto DMA friendly like Wind=
ows, it&#39;s easy to write high performance filesystem code for Windows an=
d FreeBSD which performs very similarly.</div><div><br></div><div>Linux is =
and has always been the worst to support of them all. Highly nonconforming,=
 lousy implementation of locks, doesn&#39;t implement O_SYNC right, the lis=
t goes on. Though its O_DIRECT is now finally sane and can be trusted, agai=
n, despite Linus&#39; best efforts.</div><div><br></div><div>OS X is infamo=
us for frequent showstopper bugs like writes to a mmap not being written to=
 disc ever. But once reported, they do fix them quick. And apart from the a=
wful async i/o implementation, OS X is pretty good otherwise, though they t=
ook forever to implement the race free POSIX API. Oh, and fsync is non bloc=
king :(.</div><div>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div><br></div><div>When you have multiple processes working on the s=
ame data, often you need to synchronise. You try not to of course, you expl=
oit the natural synchronisation built into i/o which is actually finally vi=
able as of just these past months thanks to Microsoft fixing Windows to fol=
low POSIX i/o concurrency guarantees. You need the very latest Windows 10 h=
owever, and a pretty recent Linux kernel. But it does work, and it&#39;s po=
rtable-ish.</div><div><br></div><div>AFIO uses a list based system for its =
locking algorithms, so process A says it&#39;ll be locking 5, 22 and 13. Pr=
ocess B says it&#39;ll be locking 6, 99, and 13. The synchronisation will h=
appen on the 13.</div><div><br></div><div>The numbers are arbitrary and mea=
n whatever the application chooses them to mean. Under the bonnet, the four=
 implementations have very different approaches to implementation. Some hav=
e amazing performance but are anti-social. Others scale amazingly. Some are=
 NFS/Samba friendly. Some are shared memory only.</div><div><br></div><div>=
afio::shared_fs_mutex is an abstract base class, so runtime code can swap i=
mplementations and higher level code doesn&#39;t need to care how the locki=
ng works.</div><div>=C2=A0</div></div></blockquote><div>Have you considered=
 trying to specify an improved OS APIs that could be aspired to?<br>It is e=
xactly this kind of implementation experience from which such things tend t=
o drop out.</div></div></blockquote><div><br></div><div>I&#39;m new to WG21=
, but have been involved in standards for a long time. Indeed, I was once t=
he SC22 mirror convenor for my country.</div><div><br></div><div>But ultima=
tely it comes down to spare capacity. You see lots of progress when I&#39;m=
 between contracts like now. But having been without income since Christmas=
, another 12-18 months of paying work beckons soon during which there will =
be no progress. Gotta go earn. I&#39;ve been working on AFIO since 2012. I =
expect it won&#39;t land before WG21 until 2020 or so. Best I can do withou=
t a sponsor.</div><div><br></div><div>And we can&#39;t persuade POSIX to ch=
ange until some major implementation makes the changes existing practice. C=
++ counts. So, if we standardise AFIO into C++, that lets us fix POSIX. Unt=
il then they&#39;ll reject all changes as having no existing practice.</div=
><div><br></div><div>Niall</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a40e582c-7b5c-4bc4-ad8a-86ea8dc65eab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a40e582c-7b5c-4bc4-ad8a-86ea8dc65eab=
%40isocpp.org</a>.<br />

------=_Part_6296_1345016454.1502812430978--

------=_Part_6295_1536115422.1502812430977--

.

------=_Part_1822_203724618.1502812764957
Content-Type: multipart/alternative;
 boundary="----=_Part_1823_1123066377.1502812764958"

------=_Part_1823_1123066377.1502812764958
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 15, 2017 at 4:30:00 PM UTC+1, Thiago Macieira wrote:
>
> On Tuesday, 15 August 2017 08:19:42 PDT Niall Douglas wrote:
> > access() is an enormous security hole. I really wish it could be
> eliminated.
>
> Explain. Are you refering to a TOCTOU attack?
>

Mainly. But access() is problematic in lots of other ways too. One should
really not implement exists() with it, it's the wrong API.


>
> > open()-close() is slow, but safe. Indeed Windows internally does exactly
> > this when checking for a file to exist.
>
> For that matter, trying W_OK by opening for write is also a bad idea,
> since it
> modifies the file (atime update) and could run afoul of sharing violation
> on
> Windows.
>

Just open the file without any permissions to do anything including update
metadata (which is an individual permission on Windows). Windows implements
this with a special quick fast path, normal NtCreateFile() takes tens of
microseconds, unprivileged NtCreateFile() is usually single digit
microseconds.

POSIX has a problem of course because O_RDONLY is usually zero.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8e1cbb42-f25c-4e78-8ddc-e8d84e37fc80%40isocpp.org.

------=_Part_1823_1123066377.1502812764958
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 15, 2017 at 4:30:00 PM UTC+1, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, 15 Au=
gust 2017 08:19:42 PDT Niall Douglas wrote:
<br>&gt; access() is an enormous security hole. I really wish it could be e=
liminated.
<br>
<br>Explain. Are you refering to a TOCTOU attack?
<br></blockquote><div><br></div><div>Mainly. But access() is problematic in=
 lots of other ways too. One should really not implement exists() with it, =
it&#39;s the wrong API.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
<br>&gt; open()-close() is slow, but safe. Indeed Windows internally does e=
xactly
<br>&gt; this when checking for a file to exist.
<br>
<br>For that matter, trying W_OK by opening for write is also a bad idea, s=
ince it=20
<br>modifies the file (atime update) and could run afoul of sharing violati=
on on=20
<br>Windows.
<br>
</blockquote><div><br></div><div>Just open the file without any permissions=
 to do anything including update metadata (which is an individual permissio=
n on Windows). Windows implements this with a special quick fast path, norm=
al NtCreateFile() takes tens of microseconds, unprivileged NtCreateFile() i=
s usually single digit microseconds.</div><div><br></div><div>POSIX has a p=
roblem of course because O_RDONLY is usually zero.</div><div><br></div><div=
>Niall</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8e1cbb42-f25c-4e78-8ddc-e8d84e37fc80%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e1cbb42-f25c-4e78-8ddc-e8d84e37fc80=
%40isocpp.org</a>.<br />

------=_Part_1823_1123066377.1502812764958--

------=_Part_1822_203724618.1502812764957--

.

On Tuesday, 15 August 2017 08:59:24 PDT Niall Douglas wrote:
> On Tuesday, August 15, 2017 at 4:30:00 PM UTC+1, Thiago Macieira wrote:
> > On Tuesday, 15 August 2017 08:19:42 PDT Niall Douglas wrote:
> > > access() is an enormous security hole. I really wish it could be
> >
> > eliminated.
> >
> > Explain. Are you refering to a TOCTOU attack?
>
> Mainly. But access() is problematic in lots of other ways too. One should
> really not implement exists() with it, it's the wrong API.

The TOCTOU attack is not the fault of the library or the access() function,
but that of the upper code that checked for existence before trying the
operation it was going to do if the file existed.

So you have two choices: provide a function that returns the existence of the
file or force the user to not check for it. If you choose to provide it, then
you have to use either access(F_OK) or stat(), but the latter is more
expensive than the former.

> > > open()-close() is slow, but safe. Indeed Windows internally does exactly
> > > this when checking for a file to exist.
> >
> > For that matter, trying W_OK by opening for write is also a bad idea,
> > since it
> > modifies the file (atime update) and could run afoul of sharing violation
> > on
> > Windows.
>
> Just open the file without any permissions to do anything including update
> metadata (which is an individual permission on Windows). Windows implements
> this with a special quick fast path, normal NtCreateFile() takes tens of
> microseconds, unprivileged NtCreateFile() is usually single digit
> microseconds.
>
> POSIX has a problem of course because O_RDONLY is usually zero.

You can even emulate F_OK on an unreadable file by checking that you got an
EPERM or EACCES error instead of ENOENT or ENAMETOOLONG or ELOOP. The problem
is what happens if you succeed and the file is a FIFO: you can't close it
again, lest the other side of the pipe be notified of the closure.

That doesn't solve the problem of X_OK.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2288540.TWo8OSVWay%40tjmaciei-mobl1.

.

------=_Part_6714_634551032.1502832729022
Content-Type: multipart/alternative;
 boundary="----=_Part_6715_2138171263.1502832729023"

------=_Part_6715_2138171263.1502832729023
Content-Type: text/plain; charset="UTF-8"


>
>
> > Mainly. But access() is problematic in lots of other ways too. One
> should
> > really not implement exists() with it, it's the wrong API.
>
> The TOCTOU attack is not the fault of the library or the access()
> function,
> but that of the upper code that checked for existence before trying the
> operation it was going to do if the file existed.
>
> So you have two choices: provide a function that returns the existence of
> the
> file or force the user to not check for it. If you choose to provide it,
> then
> you have to use either access(F_OK) or stat(), but the latter is more
> expensive than the former.
>

Neither choice is sound.

The correct choice is to ban the use of absolute paths everywhere except
the open() syscall. That encourages programmers to not write racy code.

You'll see this in AFIO. We never store a path. Paths = race conditions. It
also means that all of AFIO's classes have trivial storage, which in turn
means no mallocs and no performance surprises which is important when you
have a 1 microsecond budget.

Also, absolute paths are *slow*. Most kernels implement a mutex per inode,
so traversing a fifteen deep path means fifteen mutex locks and unlocks
minimum, and inode mutexs tend to be of the more heavy RW type mutex.
FreeBSD even implements a "path cache" to speed up path-to-inode lookups
for recently traversed paths, so even more overhead.

Finally, the very fastest way of checking for existence of a file is
actually to enumerate its containing directory via faccessat on POSIX or a
single file globbed enumeration call on Windows. Orders of magnitude faster
than access() or anything which works with paths.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1bd39209-1074-49ba-94e7-56b07e065316%40isocpp.org.

------=_Part_6715_2138171263.1502832729023
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=C2=A0<br>&gt=
; Mainly. But access() is problematic in lots of other ways too. One should
<br>&gt; really not implement exists() with it, it&#39;s the wrong API.
<br>
<br>The TOCTOU attack is not the fault of the library or the access() funct=
ion,=20
<br>but that of the upper code that checked for existence before trying the=
=20
<br>operation it was going to do if the file existed.
<br>
<br>So you have two choices: provide a function that returns the existence =
of the=20
<br>file or force the user to not check for it. If you choose to provide it=
, then=20
<br>you have to use either access(F_OK) or stat(), but the latter is more=
=20
<br>expensive than the former.
<br></blockquote><div><br></div><div>Neither choice is sound.</div><div><br=
></div><div>The correct choice is to ban the use of absolute paths everywhe=
re except the open() syscall. That encourages programmers to not write racy=
 code.</div><div><br></div><div>You&#39;ll see this in AFIO. We never store=
 a path. Paths =3D race conditions. It also means that all of AFIO&#39;s cl=
asses have trivial storage, which in turn means no mallocs and no performan=
ce surprises which is important when you have a 1 microsecond budget.</div>=
<div><br></div><div>Also, absolute paths are <i>slow</i>. Most kernels impl=
ement a mutex per inode, so traversing a fifteen deep path means fifteen mu=
tex locks and unlocks minimum, and inode mutexs tend to be of the more heav=
y RW type mutex. FreeBSD even implements a &quot;path cache&quot; to speed =
up path-to-inode lookups for recently traversed paths, so even more overhea=
d.</div><div><br></div><div>Finally, the very fastest way of checking for e=
xistence of a file is actually to enumerate its containing directory via fa=
ccessat on POSIX or a single file globbed enumeration call on Windows. Orde=
rs of magnitude faster than access() or anything which works with paths.</d=
iv><div><br></div><div>Niall</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1bd39209-1074-49ba-94e7-56b07e065316%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1bd39209-1074-49ba-94e7-56b07e065316=
%40isocpp.org</a>.<br />

------=_Part_6715_2138171263.1502832729023--

------=_Part_6714_634551032.1502832729022--

.

On Tuesday, 15 August 2017 14:32:08 PDT Niall Douglas wrote:
> > So you have two choices: provide a function that returns the existence =
of
> > the
> > file or force the user to not check for it. If you choose to provide it=
,
> > then
> > you have to use either access(F_OK) or stat(), but the latter is more
> > expensive than the former.
>=20
> Neither choice is sound.
>=20
> The correct choice is to ban the use of absolute paths everywhere except
> the open() syscall. That encourages programmers to not write racy code.

That is telling the programmer to open the file, not check if it exists or =
is=20
readable without opening it.

If you have an API that allows checking for the existence without opening,=
=20
then it is racy. But if you have that API, there's nothing better than acce=
ss=20
or faccessat.

> You'll see this in AFIO. We never store a path. Paths =3D race conditions=
.. It
> also means that all of AFIO's classes have trivial storage, which in turn
> means no mallocs and no performance surprises which is important when you
> have a 1 microsecond budget.

Path, whether relative or absolute, is not the issue. I was reading Raymond=
=20
Chen's post yesterday on hardlinking, which is relevant to this discussion:
https://blogs.msdn.microsoft.com/oldnewthing/20170707-00/?p=3D96555

One of the commenters asks=20
"According to the well-known UX guidelines (context) menu entries which can=
=E2=80=99t=20
be executed should not be shown to the user. [...] So: how should a proper=
=20
implemented shell extension handle it?"

That's similar to the case here. Sometimes the user needs to know if a file=
=20
exists before trying to open it. I know it's racy, but if the UX requires i=
t,=20
the programmer needs to implement it. That means the library needs to provi=
de=20
an API to check if the file exists.=20

The fact that you checked that the file is readable does not imply you will=
 be=20
able to open it later. Regardless of how it's implemented.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1716835.lTM4JDLVGC%40tjmaciei-mobl1.

.

------=_Part_6955_2144154661.1502850380055
Content-Type: multipart/alternative;
 boundary="----=_Part_6956_2132240502.1502850380055"

------=_Part_6956_2132240502.1502850380055
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


>
>
> > You'll see this in AFIO. We never store a path. Paths =3D race conditio=
ns.=20
> It=20
> > also means that all of AFIO's classes have trivial storage, which in=20
> turn=20
> > means no mallocs and no performance surprises which is important when=
=20
> you=20
> > have a 1 microsecond budget.=20
>
> Path, whether relative or absolute, is not the issue.


People tend to use absolute paths despite that they are (a) slower (b)=20
racier.

I'm a great believer in that programmers are lazy, and will take the least=
=20
effort approach. So AFIO makes using absolute paths annoying, and relative=
=20
paths easy. Plus we sprinkle over the docs "don't use absolute paths unless=
=20
you really have to".
=20

> I was reading Raymond=20
> Chen's post yesterday on hardlinking, which is relevant to this=20
> discussion:=20
> https://blogs.msdn.microsoft.com/oldnewthing/20170707-00/?p=3D96555=20
>

His answer incidentally is severely flawed. NTFS implements a relatively=20
low maximum 1023 hard link limit. It's easy to run into, and would confound=
=20
his "easy" solution.
=20

>
> One of the commenters asks=20
> "According to the well-known UX guidelines (context) menu entries which=
=20
> can=E2=80=99t=20
> be executed should not be shown to the user. [...] So: how should a prope=
r=20
> implemented shell extension handle it?"=20
>
> That's similar to the case here. Sometimes the user needs to know if a=20
> file=20
> exists before trying to open it. I know it's racy, but if the UX requires=
=20
> it,=20
> the programmer needs to implement it. That means the library needs to=20
> provide=20
> an API to check if the file exists.=20
>
=20
I am not disagreeing. That API ought to be enumeration of the containing=20
directory i.e. faccessat(). It's the least worst design.

Niall

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5fe02a97-293a-48e3-b7fb-ffb52f03ddc0%40isocpp.or=
g.

------=_Part_6956_2132240502.1502850380055
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt; You&=
#39;ll see this in AFIO. We never store a path. Paths =3D race conditions. =
It
<br>&gt; also means that all of AFIO&#39;s classes have trivial storage, wh=
ich in turn
<br>&gt; means no mallocs and no performance surprises which is important w=
hen you
<br>&gt; have a 1 microsecond budget.
<br>
<br>Path, whether relative or absolute, is not the issue.</blockquote><div>=
<br></div><div>People tend to use absolute paths despite that they are (a) =
slower (b) racier.</div><div><br></div><div>I&#39;m a great believer in tha=
t programmers are lazy, and will take the least effort approach. So AFIO ma=
kes using absolute paths annoying, and relative paths easy. Plus we sprinkl=
e over the docs &quot;don&#39;t use absolute paths unless you really have t=
o&quot;.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
> I was reading Raymond=20
<br>Chen&#39;s post yesterday on hardlinking, which is relevant to this dis=
cussion:
<br><a href=3D"https://blogs.msdn.microsoft.com/oldnewthing/20170707-00/?p=
=3D96555" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;https://www.google.com/url?q\x3dhttps%3A%2F%2Fblogs.msdn.microsoft.com%2F=
oldnewthing%2F20170707-00%2F%3Fp%3D96555\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNF53LIHpnbfPZYVxYAjT4WqXWIS8g&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fblogs.msdn.microsoft.=
com%2Foldnewthing%2F20170707-00%2F%3Fp%3D96555\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNF53LIHpnbfPZYVxYAjT4WqXWIS8g&#39;;return true;">https://blogs.m=
sdn.microsoft.<wbr>com/oldnewthing/20170707-00/?<wbr>p=3D96555</a>
<br></blockquote><div><br></div><div>His answer incidentally is severely fl=
awed. NTFS implements a relatively low maximum 1023 hard link limit. It&#39=
;s easy to run into, and would confound his &quot;easy&quot; solution.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>One of the commenters asks=20
<br>&quot;According to the well-known UX guidelines (context) menu entries =
which can=E2=80=99t=20
<br>be executed should not be shown to the user. [...] So: how should a pro=
per=20
<br>implemented shell extension handle it?&quot;
<br>
<br>That&#39;s similar to the case here. Sometimes the user needs to know i=
f a file=20
<br>exists before trying to open it. I know it&#39;s racy, but if the UX re=
quires it,=20
<br>the programmer needs to implement it. That means the library needs to p=
rovide=20
<br>an API to check if the file exists.=20
<br>
</blockquote><div>=C2=A0</div><div>I am not disagreeing. That API ought to =
be enumeration of the containing directory i.e. faccessat(). It&#39;s the l=
east worst design.</div><div><br></div><div>Niall</div><div><br></div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5fe02a97-293a-48e3-b7fb-ffb52f03ddc0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5fe02a97-293a-48e3-b7fb-ffb52f03ddc0=
%40isocpp.org</a>.<br />

------=_Part_6956_2132240502.1502850380055--

------=_Part_6955_2144154661.1502850380055--

.

------=_Part_3925_146879663.1503335257622
Content-Type: multipart/alternative;
 boundary="----=_Part_3926_600236874.1503335257622"

------=_Part_3926_600236874.1503335257622
Content-Type: text/plain; charset="UTF-8"

Earlier in this thread it was suggested I survey some existing
implementations of std::basic_filebuf to see what they do.
I have done some work in this direction and the results are below.

I've stuck to open source implementations I could easily get hold of and
visual c++ as the big player on windows and as the prime non-POSIX exemplar.


*libstdc++ from GNU g++*

filebuf is implemented on top of a file handle class "__basic_file<char>"
which is implemented on top of __c_file* which turns out to be a typedef
for FILE*

It also provides out of the box two extensions relevant here:

libstdc++-v3/include/ext/stdio_filebuf.h  - implemented directly over FILE*
libstdc++-v3/include/ext/stdio_sync_filebuf.h  - implemented over FILE* and
POSIX integer FD

both are derived from std::basic_filebuf

stdio_sync_filebuf has operations:
      constructor accepting POSIX fd
      constructor accepting FILE*
      fd()    - to return the POSIX fd
      file()   - to return a C FILE*

stdio_filebuf has:
      constructor accepting FILE*
      file()   - to return a C FILE*

The 'sync' variant provides numerous sync functions (hence the name).


*clang*

fstream is implemented in terms of FILE*

libcxx-4.0.1.src/include/fstream
    FILE* __file_;

It does not accept a FILE* constructor not provide a getter function.


*apache stdcxx* (the Roguewave standard library implementation was imported
in 2007)

implementation is based on FILE*

std::filebuf has (non-standard) constructors accepting either FILE* or FD
and functions:

int fd()  -  returning a POSIX fd
attach(int fd) - to attach to an existing fd
dettach() - to detach from and close the underyling fd


*open watcom v2*
not sure this is widely used but it is at least open source and therefore
easy to assess.

filebuf is implemented in terms of filedesc which is a integer fd.

It has attach() and fd() methods accepting and returning a POSIX style FD.



*visual c++*from MSDN you can see the API but not the private members.
Surprisingly access to POSIX style integer FDs appear to be supported out
of the box

filedesc fd() const;
filebuf* attach( filedesc fd );
https://msdn.microsoft.com/en-us/library/aa243812(v=vs.60).aspx
https://msdn.microsoft.com/en-us/library/aa243810(v=vs.60).aspx

I can't actually find these in the implementation so it may be squirrelled
away in the POSIX subsystem.

To access the implementation I had download and install vc++ build tools on
windows

fstream contains basic_filebuf implemented over _Filet*

Filet* turns out to be:

yvals.h:
  #define _Filet FILE

Not a HANDLE in sight!

I would be interested in data points from other implementations to which I
don't have access
or pointers to others I could easily find online and should consider.

To summarise my admittedly far from thorough implementation review it would
seem that:

Posix only implementations are typically based on integer FDs.
All other implementations are ultimately based on FILE*

Accessing the underlying implementation is a common extension.
g++ has required it to be via a downcast as suggested earlier.
The others that allow it, allow it directly.

A separate stdio_filebuf was previously justified on the grounds that
implementations should not be forced to be based on FILE*.
Does this still stand?

I have not found an implementation where FILE* would not be accessible in
principle.
If we have a posix FD we can (mostly) get a FILE* and visa versa.

Does this mean we don't need native_filebuf either?

Another justification for stdio_filebuf and native_filebuf would be to keep
the interface of filebuf free
from platform & implementation dependent parts.
Does FILE* count as it is part of cstdio?

What harm would exposing a FILE* API directly cause?
Perhaps "who would be harmed?" is a better question as I don't think the
implementations I've surveyed so far would be.

Likewise what harm would exposing an FD based API if _POSIX_C_SOURCE is
defined cause?

Bruce.






--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5138b24b-9c23-4570-9242-6b711c1ac090%40isocpp.org.

------=_Part_3926_600236874.1503335257622
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Earlier in this thread it was suggested I survey some exis=
ting implementations of std::basic_filebuf to see what they do.<br>I have d=
one some work in this direction and the results are below.<br><br>I&#39;ve =
stuck to open source implementations I could easily get hold of and visual =
c++ as the big player on windows and as the prime non-POSIX exemplar.<br><b=
r><br><u>libstdc++ from GNU g++</u><br><br>filebuf is implemented on top of=
 a file handle class &quot;__basic_file&lt;char&gt;&quot;<br>which is imple=
mented on top of __c_file* which turns out to be a typedef for FILE*<br><br=
>It also provides out of the box two extensions relevant here:<br><br>libst=
dc++-v3/include/ext/stdio_filebuf.h=C2=A0 - implemented directly over FILE*=
<br>libstdc++-v3/include/ext/stdio_sync_filebuf.h=C2=A0 - implemented over =
FILE* and POSIX integer FD<br><br>both are derived from std::basic_filebuf<=
br><br>stdio_sync_filebuf has operations:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 constructor accepting POSIX fd<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 construct=
or accepting FILE*<br>=C2=A0 =C2=A0 =C2=A0 fd()=C2=A0=C2=A0=C2=A0 - to retu=
rn the POSIX fd<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 file()=C2=A0=C2=A0 - to r=
eturn a C FILE*<br><br>stdio_filebuf has:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 constructor accepting FILE*<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 file()=C2=A0=
=C2=A0 - to return a C FILE*<br><br>The &#39;sync&#39; variant provides num=
erous sync functions (hence the name).<br><u><br><br>clang</u><br><br>fstre=
am is implemented in terms of FILE*<br><br>libcxx-4.0.1.src/include/fstream=
<br>=C2=A0=C2=A0=C2=A0 FILE* __file_;<br><br>It does not accept a FILE* con=
structor not provide a getter function.<br><br><br><u>apache stdcxx</u> (th=
e Roguewave standard library implementation was imported in 2007)<br><br>im=
plementation is based on FILE*<br><br>std::filebuf has (non-standard) const=
ructors accepting either FILE* or FD<br>and functions:<br><br>int fd()=C2=
=A0 -=C2=A0 returning a POSIX fd<br>attach(int fd) - to attach to an existi=
ng fd<br>dettach() - to detach from and close the underyling fd<br><br><u><=
br>open watcom v2</u><br>not sure this is widely used but it is at least op=
en source and therefore easy to assess.<br><br>filebuf is implemented in te=
rms of filedesc which is a integer fd.<br><br>It has attach() and fd() meth=
ods accepting and returning a POSIX style FD.<br><br><u><br>visual c++<br><=
/u>from MSDN you can see the API but not the private members.<br>Surprising=
ly access to POSIX style integer FDs appear to be supported out of the box =
<br><br>filedesc fd() const;<br>filebuf* attach( filedesc fd );<br>https://=
msdn.microsoft.com/en-us/library/aa243812(v=3Dvs.60).aspx<br>https://msdn.m=
icrosoft.com/en-us/library/aa243810(v=3Dvs.60).aspx<br><br>I can&#39;t actu=
ally find these in the implementation so it may be squirrelled away in the =
POSIX subsystem.<br><br>To access the implementation I had download and ins=
tall vc++ build tools on windows<br><br>fstream contains basic_filebuf impl=
emented over _Filet*<br><br>Filet* turns out to be:<br><br>yvals.h:<br>=C2=
=A0 #define _Filet FILE<br><br>Not a HANDLE in sight!<br><br>I would be int=
erested in data points from other implementations to which I don&#39;t have=
 access<br>or pointers to others I could easily find online and should cons=
ider.<br><br>To summarise my admittedly far from thorough implementation re=
view it would seem that:<br><br>Posix only implementations are typically ba=
sed on integer FDs.<br>All other implementations are ultimately based on FI=
LE*<br><br>Accessing the underlying implementation is a common extension.<b=
r>g++ has required it to be via a downcast as suggested earlier.<br>The oth=
ers that allow it, allow it directly.<br><br>A separate stdio_filebuf was p=
reviously justified on the grounds that implementations should not be force=
d to be based on FILE*.<br>Does this still stand? <br><br>I have not found =
an implementation where FILE* would not be accessible in principle.<br>If w=
e have a posix FD we can (mostly) get a FILE* and visa versa.<br><br>Does t=
his mean we don&#39;t need native_filebuf either?<br><br>Another justificat=
ion for stdio_filebuf and native_filebuf would be to keep the interface of =
filebuf free<br>from platform &amp; implementation dependent parts.<br>Does=
 FILE* count as it is part of cstdio?<br><br>What harm would exposing a FIL=
E* API directly cause?<br>Perhaps &quot;who would be harmed?&quot; is a bet=
ter question as I don&#39;t think the implementations I&#39;ve surveyed so =
far would be.<br><br>Likewise what harm would exposing an FD based API if _=
POSIX_C_SOURCE is defined cause?<br><br>Bruce.<br><br><br><br><br><br><br><=
u></u></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5138b24b-9c23-4570-9242-6b711c1ac090%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5138b24b-9c23-4570-9242-6b711c1ac090=
%40isocpp.org</a>.<br />

------=_Part_3926_600236874.1503335257622--

------=_Part_3925_146879663.1503335257622--

.

------=_Part_8159_1801183512.1503389477894
Content-Type: multipart/alternative;
 boundary="----=_Part_8160_843476987.1503389477894"

------=_Part_8160_843476987.1503389477894
Content-Type: text/plain; charset="UTF-8"


On Monday, 21 August 2017 18:07:37 UTC+1, Bruce Adams wrote:
>
> Earlier in this thread it was suggested I survey some existing
> implementations of std::basic_filebuf to see what they do.
> I have done some work in this direction and the results are below.
>
> I've stuck to open source implementations I could easily get hold of and
> visual c++ as the big player on windows and as the prime non-POSIX exemplar.
>
>
> *libstdc++ from GNU g++*
>
> filebuf is implemented on top of a file handle class "__basic_file<char>"
> which is implemented on top of __c_file* which turns out to be a typedef
> for FILE*
>
> It also provides out of the box two extensions relevant here:
>
> libstdc++-v3/include/ext/stdio_filebuf.h  - implemented directly over FILE*
> libstdc++-v3/include/ext/stdio_sync_filebuf.h  - implemented over FILE*
> and POSIX integer FD
>
> both are derived from std::basic_filebuf
>
> stdio_sync_filebuf has operations:
>       constructor accepting POSIX fd
>       constructor accepting FILE*
>       fd()    - to return the POSIX fd
>       file()   - to return a C FILE*
>
> stdio_filebuf has:
>       constructor accepting FILE*
>       file()   - to return a C FILE*
>
> The 'sync' variant provides numerous sync functions (hence the name).
>
>
> *clang*
>
> fstream is implemented in terms of FILE*
>
> libcxx-4.0.1.src/include/fstream
>     FILE* __file_;
>
> It does not accept a FILE* constructor not provide a getter function.
>
>
> *apache stdcxx* (the Roguewave standard library implementation was
> imported in 2007)
>
> implementation is based on FILE*
>
> std::filebuf has (non-standard) constructors accepting either FILE* or FD
> and functions:
>
> int fd()  -  returning a POSIX fd
> attach(int fd) - to attach to an existing fd
> dettach() - to detach from and close the underyling fd
>
>
> *open watcom v2*
> not sure this is widely used but it is at least open source and therefore
> easy to assess.
>
> filebuf is implemented in terms of filedesc which is a integer fd.
>
> It has attach() and fd() methods accepting and returning a POSIX style FD.
>
>
>
> *visual c++*from MSDN you can see the API but not the private members.
> Surprisingly access to POSIX style integer FDs appear to be supported out
> of the box
>
> filedesc fd() const;
> filebuf* attach( filedesc fd );
> https://msdn.microsoft.com/en-us/library/aa243812(v=vs.60).aspx
> https://msdn.microsoft.com/en-us/library/aa243810(v=vs.60).aspx
>
> I can't actually find these in the implementation so it may be squirrelled
> away in the POSIX subsystem.
>
> To access the implementation I had download and install vc++ build tools
> on windows
>
> fstream contains basic_filebuf implemented over _Filet*
>
> Filet* turns out to be:
>
> yvals.h:
>   #define _Filet FILE
>
> Not a HANDLE in sight!
>
> I would be interested in data points from other implementations to which I
> don't have access
> or pointers to others I could easily find online and should consider.
>
> To summarise my admittedly far from thorough implementation review it
> would seem that:
>
> Posix only implementations are typically based on integer FDs.
> All other implementations are ultimately based on FILE*
>
> Accessing the underlying implementation is a common extension.
> g++ has required it to be via a downcast as suggested earlier.
> The others that allow it, allow it directly.
>
> A separate stdio_filebuf was previously justified on the grounds that
> implementations should not be forced to be based on FILE*.
> Does this still stand?
>
> I have not found an implementation where FILE* would not be accessible in
> principle.
> If we have a posix FD we can (mostly) get a FILE* and visa versa.
>
> Does this mean we don't need native_filebuf either?
>
> Another justification for stdio_filebuf and native_filebuf would be to
> keep the interface of filebuf free
> from platform & implementation dependent parts.
> Does FILE* count as it is part of cstdio?
>
> What harm would exposing a FILE* API directly cause?
> Perhaps "who would be harmed?" is a better question as I don't think the
> implementations I've surveyed so far would be.
>
> Likewise what harm would exposing an FD based API if _POSIX_C_SOURCE is
> defined cause?
>
> Bruce.
>
>
Note that I am not advocating one approach over the other but require
arguments to justify additional complexity.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/efae4746-8a09-4d03-88dd-0765b413584d%40isocpp.org.

------=_Part_8160_843476987.1503389477894
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Monday, 21 August 2017 18:07:37 UTC+1, Bruce Adams =
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Earlie=
r in this thread it was suggested I survey some existing implementations of=
 std::basic_filebuf to see what they do.<br>I have done some work in this d=
irection and the results are below.<br><br>I&#39;ve stuck to open source im=
plementations I could easily get hold of and visual c++ as the big player o=
n windows and as the prime non-POSIX exemplar.<br><br><br><u>libstdc++ from=
 GNU g++</u><br><br>filebuf is implemented on top of a file handle class &q=
uot;__basic_file&lt;char&gt;&quot;<br>which is implemented on top of __c_fi=
le* which turns out to be a typedef for FILE*<br><br>It also provides out o=
f the box two extensions relevant here:<br><br>libstdc++-v3/include/ext/<wb=
r>stdio_filebuf.h=C2=A0 - implemented directly over FILE*<br>libstdc++-v3/i=
nclude/ext/<wbr>stdio_sync_filebuf.h=C2=A0 - implemented over FILE* and POS=
IX integer FD<br><br>both are derived from std::basic_filebuf<br><br>stdio_=
sync_filebuf has operations:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 constructor =
accepting POSIX fd<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 constructor accepting =
FILE*<br>=C2=A0 =C2=A0 =C2=A0 fd()=C2=A0=C2=A0=C2=A0 - to return the POSIX =
fd<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 file()=C2=A0=C2=A0 - to return a C FIL=
E*<br><br>stdio_filebuf has:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 constructor =
accepting FILE*<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 file()=C2=A0=C2=A0 - to r=
eturn a C FILE*<br><br>The &#39;sync&#39; variant provides numerous sync fu=
nctions (hence the name).<br><u><br><br>clang</u><br><br>fstream is impleme=
nted in terms of FILE*<br><br>libcxx-4.0.1.src/include/<wbr>fstream<br>=C2=
=A0=C2=A0=C2=A0 FILE* __file_;<br><br>It does not accept a FILE* constructo=
r not provide a getter function.<br><br><br><u>apache stdcxx</u> (the Rogue=
wave standard library implementation was imported in 2007)<br><br>implement=
ation is based on FILE*<br><br>std::filebuf has (non-standard) constructors=
 accepting either FILE* or FD<br>and functions:<br><br>int fd()=C2=A0 -=C2=
=A0 returning a POSIX fd<br>attach(int fd) - to attach to an existing fd<br=
>dettach() - to detach from and close the underyling fd<br><br><u><br>open =
watcom v2</u><br>not sure this is widely used but it is at least open sourc=
e and therefore easy to assess.<br><br>filebuf is implemented in terms of f=
iledesc which is a integer fd.<br><br>It has attach() and fd() methods acce=
pting and returning a POSIX style FD.<br><br><u><br>visual c++<br></u>from =
MSDN you can see the API but not the private members.<br>Surprisingly acces=
s to POSIX style integer FDs appear to be supported out of the box <br><br>=
filedesc fd() const;<br>filebuf* attach( filedesc fd );<br><a href=3D"https=
://msdn.microsoft.com/en-us/library/aa243812(v=3Dvs.60).aspx" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Faa243812(v%=
3Dvs.60).aspx\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGJfyKN9IE4GNZ67dekhOb=
bJICv9A&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.c=
om/url?q\x3dhttps%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Faa243812(v=
%3Dvs.60).aspx\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGJfyKN9IE4GNZ67dekhO=
bbJICv9A&#39;;return true;">https://msdn.microsoft.com/en-<wbr>us/library/a=
a243812(v=3Dvs.60).<wbr>aspx</a><br><a href=3D"https://msdn.microsoft.com/e=
n-us/library/aa243810(v=3Dvs.60).aspx" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Faa243810(v%3Dvs.60).aspx\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNFD_WFS3_v8SKzzdKKyx2FerWyoXw&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F=
%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Faa243810(v%3Dvs.60).aspx\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNFD_WFS3_v8SKzzdKKyx2FerWyoXw&#39;;return tr=
ue;">https://msdn.microsoft.com/en-<wbr>us/library/aa243810(v=3Dvs.60).<wbr=
>aspx</a><br><br>I can&#39;t actually find these in the implementation so i=
t may be squirrelled away in the POSIX subsystem.<br><br>To access the impl=
ementation I had download and install vc++ build tools on windows<br><br>fs=
tream contains basic_filebuf implemented over _Filet*<br><br>Filet* turns o=
ut to be:<br><br>yvals.h:<br>=C2=A0 #define _Filet FILE<br><br>Not a HANDLE=
 in sight!<br><br>I would be interested in data points from other implement=
ations to which I don&#39;t have access<br>or pointers to others I could ea=
sily find online and should consider.<br><br>To summarise my admittedly far=
 from thorough implementation review it would seem that:<br><br>Posix only =
implementations are typically based on integer FDs.<br>All other implementa=
tions are ultimately based on FILE*<br><br>Accessing the underlying impleme=
ntation is a common extension.<br>g++ has required it to be via a downcast =
as suggested earlier.<br>The others that allow it, allow it directly.<br><b=
r>A separate stdio_filebuf was previously justified on the grounds that imp=
lementations should not be forced to be based on FILE*.<br>Does this still =
stand? <br><br>I have not found an implementation where FILE* would not be =
accessible in principle.<br>If we have a posix FD we can (mostly) get a FIL=
E* and visa versa.<br><br>Does this mean we don&#39;t need native_filebuf e=
ither?<br><br>Another justification for stdio_filebuf and native_filebuf wo=
uld be to keep the interface of filebuf free<br>from platform &amp; impleme=
ntation dependent parts.<br>Does FILE* count as it is part of cstdio?<br><b=
r>What harm would exposing a FILE* API directly cause?<br>Perhaps &quot;who=
 would be harmed?&quot; is a better question as I don&#39;t think the imple=
mentations I&#39;ve surveyed so far would be.<br><br>Likewise what harm wou=
ld exposing an FD based API if _POSIX_C_SOURCE is defined cause?<br><br>Bru=
ce.<br><br></div></blockquote><div><br></div><div>Note that I am not advoca=
ting one approach over the other but require arguments to justify additiona=
l complexity.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/efae4746-8a09-4d03-88dd-0765b413584d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/efae4746-8a09-4d03-88dd-0765b413584d=
%40isocpp.org</a>.<br />

------=_Part_8160_843476987.1503389477894--

------=_Part_8159_1801183512.1503389477894--

.

------=_Part_8966_2119421559.1503451253085
Content-Type: multipart/alternative;
 boundary="----=_Part_8967_1566128847.1503451253085"

------=_Part_8967_1566128847.1503451253085
Content-Type: text/plain; charset="UTF-8"

Earlier in this thread it was suggested that requiring std::filebuf to be a
stdio_filebuf would unnecessarily constrain the implementation.
I am not sure that this is the case. My reasoning is as follows. Please
point out if and where it is flawed.

assertion: iosteams must be implemented in terms of FILE* or a lower level
'native' file descriptor

consider any hypothetical operating system that implements file system IO.
At minimum it must provide an interface like the following (ignoring many
embellishments that would be necessary):

   FileHandle os_file_open(const char* file);
   int os_file_read(FileHandle, size_t size, void* buffer);
   int os_file_write(FileHandle, size_t size, void* buffer);

FileHandle could be:
* a integer (Posix style fd)
* a pointer to something (OSHandle* not necessily FILE*)
* a value type "struct OSHandle"

How does this OS implement cstdio?
In particular consider:

FILE* fopen(const char *path, const char *mode);

There must be a mapping from FileHandle to FILE*
E.g.

FILE* fopen(const char *path, const char *mode)
{
   FileHandle handle = os_file_open(path);  //ignore mode for simplicity
   return CFile_from_FileHandle(handle);
}

Now consider the implementation of std::filebuf

filebuf* open (const char* filename,  ios_base::openmode mode);

filebuf must contain either FileHandle in order to use the low level
functions:

class filebuf
{
public:
   filebuf* open (const char* filename,  ios_base::openmode mode)
   {
      this->handle = os_file_open(filename); //ignoring mode for brevity
      return this;
   }
private:
   FileHandle handle;
};

or it can use cstdio FILE*:

class filebuf
{
public:
   filebuf* open (const char* filename,  ios_base::openmode mode)
   {
      this->cfile = fopen(filename,to_stdio_mode(mode)); //ignoring mode
for brevity
      return this;
   }
private:
   FILE* cfile;
};

Given that CFile_from_FileHandle(handle) must exist. It is trivial to
implement:

FILE* std::filebuf::file() const
{
   return CFile_from_FileHandle(this->handle);
}

or:

FILE* std::filebuf::file() const
{
   return this->cfile;
}

as necessary.

Likewise to implement:

   size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);

in terms of:

   int os_file_read(FileHandle, size_t size, void* buffer);

there must be functionality to create a FileHandle from a FILE*, for
example:;

size_t fread(const void *ptr, size_t size, size_t nmemb,
              FILE *stream)
{
   return os_file_read(FileHandle_To_CFile(stream),size,ptr); //nmemb
ignored for brevity
}

This means it should be straight forward to implement a std::filebuf
constructor taking a FILE*.

By the same logic #ifdef _POSIX_C_SOURCE should imply accessing the FD is
equally straight forward.

I see no constraints on the implementation here.

Is filebuf <--> FILE* a dangerously leaky abstraction?

filebuf <--> fd is 'dangerous' because an fd might not be a file
descriptor. It could be a plain integer or a socket, fifo or pipe for
example.

C++ permits us to be low-level and accept the consequences. Is there
actually any need to wrap these conversions to make them safer?
I think the case can be made for a FD as a naked integer is not type-safe
but not anything else.

If I was to write this as a proposal what do stdio_filebuf and or
native_filebuf make possible or prevent that altering std::filebuf would
not?

Bruce.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0c636790-a766-4097-b3f8-cafb580dc84c%40isocpp.org.

------=_Part_8967_1566128847.1503451253085
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Earlier in this thread it was suggested that requiring std=
::filebuf to be a stdio_filebuf would unnecessarily constrain the implement=
ation.<br>I am not sure that this is the case. My reasoning is as follows. =
Please point out if and where it is flawed.<br><br>assertion: iosteams must=
 be implemented in terms of FILE* or a lower level &#39;native&#39; file de=
scriptor<br><br>consider any hypothetical operating system that implements =
file system IO.<br>At minimum it must provide an interface like the followi=
ng (ignoring many embellishments that would be necessary):<br><br>=C2=A0=C2=
=A0 FileHandle os_file_open(const char* file);<br>=C2=A0=C2=A0 int os_file_=
read(FileHandle, size_t size, void* buffer);<br>=C2=A0=C2=A0 int os_file_wr=
ite(FileHandle, size_t size, void* buffer);<br><br>FileHandle could be:<br>=
* a integer (Posix style fd)<br>* a pointer to something (OSHandle* not nec=
essily FILE*)<br>* a value type &quot;struct OSHandle&quot;<br><br>How does=
 this OS implement cstdio?<br>In particular consider:<br><br>FILE* fopen(co=
nst char *path, const char *mode);<br><br>There must be a mapping from File=
Handle to FILE*<br>E.g.<br><br>FILE* fopen(const char *path, const char *mo=
de)<br>{<br>=C2=A0=C2=A0 FileHandle handle =3D os_file_open(path);=C2=A0 //=
ignore mode for simplicity<br>=C2=A0=C2=A0 return CFile_from_FileHandle(han=
dle);<br>}<br><br>Now consider the implementation of std::filebuf<br><br>fi=
lebuf* open (const char* filename,=C2=A0 ios_base::openmode mode);<br><br>f=
ilebuf must contain either FileHandle in order to use the low level functio=
ns:<br><br>class filebuf<br>{<br>public:<br>=C2=A0=C2=A0 filebuf* open (con=
st char* filename,=C2=A0 ios_base::openmode mode)<br>=C2=A0=C2=A0 {<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 this-&gt;handle =3D os_file_open(filename); //i=
gnoring mode for brevity<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return this;<br>=
=C2=A0=C2=A0 }<br>private:<br>=C2=A0=C2=A0 FileHandle handle;<br>};<br><br>=
or it can use cstdio FILE*:<br><br>class filebuf<br>{<br>public:<br>=C2=A0=
=C2=A0 filebuf* open (const char* filename,=C2=A0 ios_base::openmode mode)<=
br>=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this-&gt;cfile =3D fope=
n(filename,to_stdio_mode(mode)); //ignoring mode for brevity<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 return this;<br>=C2=A0=C2=A0 }<br>private:<br>=C2=A0=
=C2=A0 FILE* cfile;<br>};<br><br>Given that CFile_from_FileHandle(handle) m=
ust exist. It is trivial to implement:<br><br>FILE* std::filebuf::file() co=
nst<br>{<br>=C2=A0=C2=A0 return CFile_from_FileHandle(this-&gt;handle);<br>=
}<br><br>or:<br><br>FILE* std::filebuf::file() const<br>{<br>=C2=A0=C2=A0 r=
eturn this-&gt;cfile;<br>}<br><br>as necessary.<br><br>Likewise to implemen=
t:<br><br>=C2=A0=C2=A0 size_t fread(void *ptr, size_t size, size_t nmemb, F=
ILE *stream);<br><br>in terms of:<br><br>=C2=A0=C2=A0 int os_file_read(File=
Handle, size_t size, void* buffer);<br><br>there must be functionality to c=
reate a FileHandle from a FILE*, for example:;<br><br>size_t fread(const vo=
id *ptr, size_t size, size_t nmemb,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FILE *stream)<br>{<br>=C2=A0=C2=
=A0 return os_file_read(FileHandle_To_CFile(stream),size,ptr); //nmemb igno=
red for brevity<br>}<br><br>This means it should be straight forward to imp=
lement a std::filebuf constructor taking a FILE*.<br><br>By the same logic =
#ifdef _POSIX_C_SOURCE should imply accessing the FD is equally straight fo=
rward.<br><br>I see no constraints on the implementation here.<br><br>Is fi=
lebuf &lt;--&gt; FILE* a dangerously leaky abstraction?<br><br>filebuf &lt;=
--&gt; fd is &#39;dangerous&#39; because an fd might not be a file descript=
or. It could be a plain integer or a socket, fifo or pipe for example.<br><=
br>C++ permits us to be low-level and accept the consequences. Is there act=
ually any need to wrap these conversions to make them safer?<br>I think the=
 case can be made for a FD as a naked integer is not type-safe but not anyt=
hing else.<br><br>If I was to write this as a proposal what do stdio_filebu=
f and or native_filebuf make possible or prevent that altering std::filebuf=
 would not?<br><br>Bruce.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0c636790-a766-4097-b3f8-cafb580dc84c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c636790-a766-4097-b3f8-cafb580dc84c=
%40isocpp.org</a>.<br />

------=_Part_8967_1566128847.1503451253085--

------=_Part_8966_2119421559.1503451253085--

.

------=_Part_5081_379286837.1503467234070
Content-Type: multipart/alternative;
 boundary="----=_Part_5082_1968734799.1503467234070"

------=_Part_5082_1968734799.1503467234070
Content-Type: text/plain; charset="UTF-8"

The problem with your argument is that CFile_from_FileHandle need not
return the same FILE* when called multiple times with the same file handle
value, but your file() had better return the same value when called
multiple times.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5eaecc51-9cef-497f-bc78-277e08df33f4%40isocpp.org.

------=_Part_5082_1968734799.1503467234070
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The problem with your argument is that CFile_from_FileHand=
le need not return the same FILE* when called multiple times with the same =
file handle value, but your file() had better return the same value when ca=
lled multiple times.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5eaecc51-9cef-497f-bc78-277e08df33f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5eaecc51-9cef-497f-bc78-277e08df33f4=
%40isocpp.org</a>.<br />

------=_Part_5082_1968734799.1503467234070--

------=_Part_5081_379286837.1503467234070--

.

------=_Part_9941_603075193.1503474475667
Content-Type: multipart/alternative;
 boundary="----=_Part_9942_1852587694.1503474475667"

------=_Part_9942_1852587694.1503474475667
Content-Type: text/plain; charset="UTF-8"



On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C. wrote:
>
> The problem with your argument is that CFile_from_FileHandle need not
> return the same FILE* when called multiple times with the same file handle
> value, but your file() had better return the same value when called
> multiple times.
>

Can you give an example where it legitimately could not?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/57c87667-512b-4b5e-a276-49476322209d%40isocpp.org.

------=_Part_9942_1852587694.1503474475667
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C.=
  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The p=
roblem with your argument is that CFile_from_FileHandle need not return the=
 same FILE* when called multiple times with the same file handle value, but=
 your file() had better return the same value when called multiple times.</=
div></blockquote><div><br></div><div>Can you give an example where it legit=
imately could not?</div><div><br></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/57c87667-512b-4b5e-a276-49476322209d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/57c87667-512b-4b5e-a276-49476322209d=
%40isocpp.org</a>.<br />

------=_Part_9942_1852587694.1503474475667--

------=_Part_9941_603075193.1503474475667--

.

------=_Part_9872_1976385687.1503475902420
Content-Type: multipart/alternative;
 boundary="----=_Part_9873_2074858588.1503475902420"

------=_Part_9873_2074858588.1503475902420
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 23, 2017 at 3:47:55 AM UTC-4, Bruce Adams wrote:
>
>
>
> On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C. wrote:
>>
>> The problem with your argument is that CFile_from_FileHandle need not
>> return the same FILE* when called multiple times with the same file handle
>> value, but your file() had better return the same value when called
>> multiple times.
>>
>
> Can you give an example where it legitimately could not?
>
>
> CFile_from_FileHandle is not a trivial mapping. A FILE* points to a FILE,
which, while opaque in the standard, typically contains additional data
beyond the native file handle (e.g., pointers to buffers). To implement
fopen(), it suffices to malloc() a FILE, initialize it appropriately and
return a pointer to it (freeing it in fclose()). You can't do that in your
file().

So...how do you plan to do it without maintaining a global fd-to-FILE* map?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/604c1b44-2294-43bb-bc67-6462ec6be637%40isocpp.org.

------=_Part_9873_2074858588.1503475902420
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, August 23, 2017 at 3:47:55 AM UTC-4,=
 Bruce Adams wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br>On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C.  wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The problem with your=
 argument is that CFile_from_FileHandle need not return the same FILE* when=
 called multiple times with the same file handle value, but your file() had=
 better return the same value when called multiple times.</div></blockquote=
><div><br></div><div>Can you give an example where it legitimately could no=
t?</div><div><br></div><div><br></div></div></blockquote><div>CFile_from_Fi=
leHandle is not a trivial mapping. A FILE* points to a FILE, which, while o=
paque in the standard, typically contains additional data beyond the native=
 file handle (e.g., pointers to buffers). To implement fopen(), it suffices=
 to malloc() a FILE, initialize it appropriately and return a pointer to it=
 (freeing it in fclose()). You can&#39;t do that in your file().</div><div>=
<br></div><div>So...how do you plan to do it without maintaining a global f=
d-to-FILE* map?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/604c1b44-2294-43bb-bc67-6462ec6be637%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/604c1b44-2294-43bb-bc67-6462ec6be637=
%40isocpp.org</a>.<br />

------=_Part_9873_2074858588.1503475902420--

------=_Part_9872_1976385687.1503475902420--

.

------=_Part_9827_922431947.1503476592050
Content-Type: multipart/alternative;
 boundary="----=_Part_9828_47600362.1503476592050"

------=_Part_9828_47600362.1503476592050
Content-Type: text/plain; charset="UTF-8"



On Wednesday, 23 August 2017 09:11:42 UTC+1, T. C. wrote:
>
>
>
> On Wednesday, August 23, 2017 at 3:47:55 AM UTC-4, Bruce Adams wrote:
>>
>>
>>
>> On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C. wrote:
>>>
>>> The problem with your argument is that CFile_from_FileHandle need not
>>> return the same FILE* when called multiple times with the same file handle
>>> value, but your file() had better return the same value when called
>>> multiple times.
>>>
>>
>> Can you give an example where it legitimately could not?
>>
>>
>> CFile_from_FileHandle is not a trivial mapping. A FILE* points to a FILE,
> which, while opaque in the standard, typically contains additional data
> beyond the native file handle (e.g., pointers to buffers). To implement
> fopen(), it suffices to malloc() a FILE, initialize it appropriately and
> return a pointer to it (freeing it in fclose()). You can't do that in your
> file().
>
> So...how do you plan to do it without maintaining a global fd-to-FILE* map?
>

The C runtime for the OS must do that anyway to implement stdio. The OS
could have low-level functionality of its own to do that. In a C based OS
they may well be one and the same but it is not required.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7efda7b0-cf5a-43b3-8e70-9a85663e60b7%40isocpp.org.

------=_Part_9828_47600362.1503476592050
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 23 August 2017 09:11:42 UTC+1, T. C.=
  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><=
br>On Wednesday, August 23, 2017 at 3:47:55 AM UTC-4, Bruce Adams wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday,=
 23 August 2017 06:47:14 UTC+1, T. C.  wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">The problem with your argument is that CFile_fro=
m_FileHandle need not return the same FILE* when called multiple times with=
 the same file handle value, but your file() had better return the same val=
ue when called multiple times.</div></blockquote><div><br></div><div>Can yo=
u give an example where it legitimately could not?</div><div><br></div><div=
><br></div></div></blockquote><div>CFile_from_FileHandle is not a trivial m=
apping. A FILE* points to a FILE, which, while opaque in the standard, typi=
cally contains additional data beyond the native file handle (e.g., pointer=
s to buffers). To implement fopen(), it suffices to malloc() a FILE, initia=
lize it appropriately and return a pointer to it (freeing it in fclose()). =
You can&#39;t do that in your file().</div><div><br></div><div>So...how do =
you plan to do it without maintaining a global fd-to-FILE* map?</div></div>=
</blockquote><div><br></div><div>The C runtime for the OS must do that anyw=
ay to implement stdio. The OS could have low-level functionality of its own=
 to do that. In a C based OS they may well be one and the same but it is no=
t required.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7efda7b0-cf5a-43b3-8e70-9a85663e60b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7efda7b0-cf5a-43b3-8e70-9a85663e60b7=
%40isocpp.org</a>.<br />

------=_Part_9828_47600362.1503476592050--

------=_Part_9827_922431947.1503476592050--

.

------=_Part_558_1152552494.1503477578610
Content-Type: multipart/alternative;
 boundary="----=_Part_559_1658939833.1503477578610"

------=_Part_559_1658939833.1503477578610
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 23, 2017 at 4:23:12 AM UTC-4, Bruce Adams wrote:
>
>
>
> On Wednesday, 23 August 2017 09:11:42 UTC+1, T. C. wrote:
>>
>>
>>
>> On Wednesday, August 23, 2017 at 3:47:55 AM UTC-4, Bruce Adams wrote:
>>>
>>>
>>>
>>> On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C. wrote:
>>>>
>>>> The problem with your argument is that CFile_from_FileHandle need not
>>>> return the same FILE* when called multiple times with the same file handle
>>>> value, but your file() had better return the same value when called
>>>> multiple times.
>>>>
>>>
>>> Can you give an example where it legitimately could not?
>>>
>>>
>>> CFile_from_FileHandle is not a trivial mapping. A FILE* points to a
>> FILE, which, while opaque in the standard, typically contains additional
>> data beyond the native file handle (e.g., pointers to buffers). To
>> implement fopen(), it suffices to malloc() a FILE, initialize it
>> appropriately and return a pointer to it (freeing it in fclose()). You
>> can't do that in your file().
>>
>> So...how do you plan to do it without maintaining a global fd-to-FILE*
>> map?
>>
>
> The C runtime for the OS must do that anyway to implement stdio.
>

The C runtime does not need to maintain a data structure that allows you to
lookup a FILE* given a file handle. Your CFile_from_FileHandle need only be
called once per file handle, in fopen. Everything in the C library receives
FILE*, and to call into the OS it suffices to be able to retrieve the file
handle from a FILE*, not the other way around.

If you still insist that this is possible, can you provide a toy
implementation on, say, linux+glibc?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc467f22-3eac-4162-9f37-730712cafc40%40isocpp.org.

------=_Part_559_1658939833.1503477578610
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, August 23, 2017 at 4:23:12 AM UTC-4,=
 Bruce Adams wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br>On Wednesday, 23 August 2017 09:11:42 UTC+1, T. C.  wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday,=
 August 23, 2017 at 3:47:55 AM UTC-4, Bruce Adams wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, 23 August 201=
7 06:47:14 UTC+1, T. C.  wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">The problem with your argument is that CFile_from_FileHandle n=
eed not return the same FILE* when called multiple times with the same file=
 handle value, but your file() had better return the same value when called=
 multiple times.</div></blockquote><div><br></div><div>Can you give an exam=
ple where it legitimately could not?</div><div><br></div><div><br></div></d=
iv></blockquote><div>CFile_from_FileHandle is not a trivial mapping. A FILE=
* points to a FILE, which, while opaque in the standard, typically contains=
 additional data beyond the native file handle (e.g., pointers to buffers).=
 To implement fopen(), it suffices to malloc() a FILE, initialize it approp=
riately and return a pointer to it (freeing it in fclose()). You can&#39;t =
do that in your file().</div><div><br></div><div>So...how do you plan to do=
 it without maintaining a global fd-to-FILE* map?</div></div></blockquote><=
div><br></div><div>The C runtime for the OS must do that anyway to implemen=
t stdio.</div></div></blockquote><div><br></div><div>The C runtime does not=
 need to maintain a data structure that allows you to lookup a FILE* given =
a file handle. Your CFile_from_FileHandle need only be called once per file=
 handle, in fopen. Everything in the C library receives FILE*, and to call =
into the OS it suffices to be able to retrieve the file handle from a FILE*=
, not the other way around.</div><div><br></div><div>If you still insist th=
at this is possible, can you provide a toy implementation on, say, linux+gl=
ibc?</div><div><br></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cc467f22-3eac-4162-9f37-730712cafc40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc467f22-3eac-4162-9f37-730712cafc40=
%40isocpp.org</a>.<br />

------=_Part_559_1658939833.1503477578610--

------=_Part_558_1152552494.1503477578610--

.

------=_Part_9799_988280282.1503514487808
Content-Type: multipart/alternative;
 boundary="----=_Part_9800_639501595.1503514487808"

------=_Part_9800_639501595.1503514487808
Content-Type: text/plain; charset="UTF-8"



On Wednesday, 23 August 2017 09:39:38 UTC+1, T. C. wrote:
>
>
>
> On Wednesday, August 23, 2017 at 4:23:12 AM UTC-4, Bruce Adams wrote:
>>
>>
>>
>> On Wednesday, 23 August 2017 09:11:42 UTC+1, T. C. wrote:
>>>
>>>
>>>
>>> On Wednesday, August 23, 2017 at 3:47:55 AM UTC-4, Bruce Adams wrote:
>>>>
>>>>
>>>>
>>>> On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C. wrote:
>>>>>
>>>>> The problem with your argument is that CFile_from_FileHandle need not
>>>>> return the same FILE* when called multiple times with the same file handle
>>>>> value, but your file() had better return the same value when called
>>>>> multiple times.
>>>>>
>>>>
>>>> Can you give an example where it legitimately could not?
>>>>
>>>>
>>>> CFile_from_FileHandle is not a trivial mapping. A FILE* points to a
>>> FILE, which, while opaque in the standard, typically contains additional
>>> data beyond the native file handle (e.g., pointers to buffers). To
>>> implement fopen(), it suffices to malloc() a FILE, initialize it
>>> appropriately and return a pointer to it (freeing it in fclose()). You
>>> can't do that in your file().
>>>
>>> So...how do you plan to do it without maintaining a global fd-to-FILE*
>>> map?
>>>
>>
>> The C runtime for the OS must do that anyway to implement stdio.
>>
>
> The C runtime does not need to maintain a data structure that allows you
> to lookup a FILE* given a file handle. Your CFile_from_FileHandle need only
> be called once per file handle, in fopen. Everything in the C library
> receives FILE*, and to call into the OS it suffices to be able to retrieve
> the file handle from a FILE*, not the other way around.
>
> If you still insist that this is possible, can you provide a toy
> implementation on, say, linux+glibc?
>
> With regards to glibc there is no need for a toy implementation. The
current implementation can already do it - see
libstdc++-v3/include/ext/stdio_filebuf.h
Indeed I suspect its trivial (but open to misuse) on any sane POSIX
implementation supporting fileno() & fdopen().

You seem to asserting that the mapping is not symmetrical. That may be
difficult to achieve in practice.
I have only used Handle->CFile. You seem to be suggesting the CFile->Handle
is trivial but Handle->CFile is not.
How would you implement fopen() without Handle->CFile?

What could be different in the code used by std::fopen() that makes it
illegal to use in filebuf::file() ?




--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c5b2d851-0d03-4efb-b2f7-11a113a06ae6%40isocpp.org.

------=_Part_9800_639501595.1503514487808
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 23 August 2017 09:39:38 UTC+1, T. C.=
  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><=
br>On Wednesday, August 23, 2017 at 4:23:12 AM UTC-4, Bruce Adams wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday,=
 23 August 2017 09:11:42 UTC+1, T. C.  wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, August 23, 2017 at 3:47:55=
 AM UTC-4, Bruce Adams wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><br><br>On Wednesday, 23 August 2017 06:47:14 UTC+1, T. C.  wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The problem with=
 your argument is that CFile_from_FileHandle need not return the same FILE*=
 when called multiple times with the same file handle value, but your file(=
) had better return the same value when called multiple times.</div></block=
quote><div><br></div><div>Can you give an example where it legitimately cou=
ld not?</div><div><br></div><div><br></div></div></blockquote><div>CFile_fr=
om_FileHandle is not a trivial mapping. A FILE* points to a FILE, which, wh=
ile opaque in the standard, typically contains additional data beyond the n=
ative file handle (e.g., pointers to buffers). To implement fopen(), it suf=
fices to malloc() a FILE, initialize it appropriately and return a pointer =
to it (freeing it in fclose()). You can&#39;t do that in your file().</div>=
<div><br></div><div>So...how do you plan to do it without maintaining a glo=
bal fd-to-FILE* map?</div></div></blockquote><div><br></div><div>The C runt=
ime for the OS must do that anyway to implement stdio.</div></div></blockqu=
ote><div><br></div><div>The C runtime does not need to maintain a data stru=
cture that allows you to lookup a FILE* given a file handle. Your CFile_fro=
m_FileHandle need only be called once per file handle, in fopen. Everything=
 in the C library receives FILE*, and to call into the OS it suffices to be=
 able to retrieve the file handle from a FILE*, not the other way around.</=
div><div><br></div><div>If you still insist that this is possible, can you =
provide a toy implementation on, say, linux+glibc?</div><div><br></div></di=
v></blockquote><div><div>With regards to glibc there is no need for a toy i=
mplementation.=20
The current implementation can already do it - see=20
libstdc++-v3/include/ext/stdio_filebuf.h<br></div><div>Indeed I suspect its=
 trivial (but open to misuse) on any sane POSIX implementation supporting f=
ileno() &amp; fdopen().</div><div><br></div></div><div>You seem to assertin=
g that the mapping is not symmetrical. That may be difficult to achieve in =
practice.</div><div>I have only used Handle-&gt;CFile. You seem to be sugge=
sting the CFile-&gt;Handle is trivial but Handle-&gt;CFile is not.<br></div=
><div>How would you implement fopen() without Handle-&gt;CFile?<br></div><d=
iv><br></div><div>What could be different in the code used by std::fopen() =
that makes it illegal to use in filebuf::file() ?<br></div><div><br></div><=
br>=C2=A0</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c5b2d851-0d03-4efb-b2f7-11a113a06ae6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c5b2d851-0d03-4efb-b2f7-11a113a06ae6=
%40isocpp.org</a>.<br />

------=_Part_9800_639501595.1503514487808--

------=_Part_9799_988280282.1503514487808--

.

------=_Part_3745_1327363138.1503514821978
Content-Type: multipart/alternative;
 boundary="----=_Part_3746_1968099553.1503514821978"

------=_Part_3746_1968099553.1503514821978
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 23, 2017 at 2:54:47 PM UTC-4, Bruce Adams wrote:
>
> With regards to glibc there is no need for a toy implementation.
>

A toy implementation that only stores a file descriptor and converts to
FILE* on demand. stdio_filebuf is not that.


> What could be different in the code used by std::fopen() that makes it
> illegal to use in filebuf::file() ?
>
> I told you what. Several times. fopen can just malloc a FILE and return a
pointer to that. Likewise for fdopen. Your file() cannot, because multiple
calls to it need to return the same FILE*.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dffd57c2-39a5-4bac-be49-7b77493f1081%40isocpp.org.

------=_Part_3746_1968099553.1503514821978
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, August 23, 2017 at 2:54:47 PM UTC-4,=
 Bruce Adams wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div>With regards to glibc there is no need for a toy implementa=
tion. </div></div></div></blockquote><div><br></div><div>A toy implementati=
on that only stores a file descriptor and converts to FILE* on demand. stdi=
o_filebuf is not that.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>What could be different i=
n the code used by std::fopen() that makes it illegal to use in filebuf::fi=
le() ?<br></div><div><br></div></div></blockquote><div>I told you what. Sev=
eral times. fopen can just malloc a FILE and return a pointer to that. Like=
wise for fdopen. Your file() cannot, because multiple calls to it need to r=
eturn the same FILE*.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dffd57c2-39a5-4bac-be49-7b77493f1081%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dffd57c2-39a5-4bac-be49-7b77493f1081=
%40isocpp.org</a>.<br />

------=_Part_3746_1968099553.1503514821978--

------=_Part_3745_1327363138.1503514821978--

.

------=_Part_239_1761421949.1503532663587
Content-Type: multipart/alternative;
 boundary="----=_Part_240_2116814805.1503532663587"

------=_Part_240_2116814805.1503532663587
Content-Type: text/plain; charset="UTF-8"



On Wednesday, 23 August 2017 20:00:22 UTC+1, T. C. wrote:
>
>
>
> On Wednesday, August 23, 2017 at 2:54:47 PM UTC-4, Bruce Adams wrote:
>>
>> With regards to glibc there is no need for a toy implementation.
>>
>
> A toy implementation that only stores a file descriptor and converts to
> FILE* on demand. stdio_filebuf is not that.
>
> You are suggesting a toy implementation is more useful than a real working
implementation?


>
>> What could be different in the code used by std::fopen() that makes it
>> illegal to use in filebuf::file() ?
>>
>> I told you what. Several times. fopen can just malloc a FILE and return a
> pointer to that. Likewise for fdopen. Your file() cannot, because multiple
> calls to it need to return the same FILE*.
>

 Okay lets work through that scenario:

FILE* fopen(const char *path, const char *mode)
{
   FileHandle handle = os_file_open(path);  //ignore mode for simplicity
   FILE* stdHandle = NULL;
   mallocate(stdHandle);
   initialiseStdioHandleFromOsHandle(stdHandle, handle);
   return stdHandle;
}

Lets ignore the case where std::filebuf is implemented on top of FILE* and
assume it uses FileHandle:

class filebuf
{
public:
   filebuf():
      handle(),
      stdioHandle(nullptr)
   {
   }

   filebuf* open (const char* filename,  ios_base::openmode mode)
   {
      this->handle = os_file_open(filename); //ignoring mode for brevity
      return this;
   }

   FILE* file()
   {
      if (this->stdHandle == nullptr)
      {
         mallocate(this->stdHandle);
         initialiseStdioHandleFromOsHandle(this->stdHandle, this->handle);
      }
      return this->stdHandle;
   }

private:
   FileHandle handle;
   FILE* stdHandle;
};

Okay so I've been forced to add a FILE* member which is initialised on
demand.
That is one possible implementation with a slight bloat to filebuf.
Is that a constraint too far?

Now there is a problem with this if you want to add a filebuf constructor
from a native FileHandle which already maps to some other FILE* object.
i.e.
  FILE* myFile = open(fileName...);
  FileHandle handle = getNativeHandle(myFile);
  filebuf myBuff(FileHandle).
  FILE* myBuffsFile = myBuff.file();
  assert(myBuffsFile != myFile);

However, if you know that's true you would be better of using a FILE*
constructor:

filebuf::filebuf(FILE* stdFile):
   handle(getNativeHandle(stdFile),
   stdioHandle(stdFile)
{
}

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fbaa10be-1d69-43e7-ade6-6b392f347147%40isocpp.org.

------=_Part_240_2116814805.1503532663587
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 23 August 2017 20:00:22 UTC+1, T. C.=
  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><=
br>On Wednesday, August 23, 2017 at 2:54:47 PM UTC-4, Bruce Adams wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>With regard=
s to glibc there is no need for a toy implementation. </div></div></div></b=
lockquote><div><br></div><div>A toy implementation that only stores a file =
descriptor and converts to FILE* on demand. stdio_filebuf is not that.</div=
><div><br></div></div></blockquote><div>You are suggesting a toy implementa=
tion is more useful than a real working implementation? <br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></=
div><div>What could be different in the code used by std::fopen() that make=
s it illegal to use in filebuf::file() ?<br></div><div><br></div></div></bl=
ockquote><div>I told you what. Several times. fopen can just malloc a FILE =
and return a pointer to that. Likewise for fdopen. Your file() cannot, beca=
use multiple calls to it need to return the same FILE*.</div></div></blockq=
uote><div><br></div><div>=C2=A0Okay lets work through that scenario:</div><=
div><br></div><div>FILE* fopen(const char *path, const char *mode)<br>{<br>=
=C2=A0=C2=A0 FileHandle handle =3D os_file_open(path);=C2=A0 //ignore mode =
for simplicity<br></div><div>=C2=A0=C2=A0 FILE* stdHandle =3D NULL;</div><d=
iv>=C2=A0=C2=A0 mallocate(stdHandle);</div><div>=C2=A0=C2=A0 initialiseStdi=
oHandleFromOsHandle(stdHandle, handle);<br></div><div>=C2=A0=C2=A0 return s=
tdHandle;<br>}<br><br>Lets ignore the case where std::filebuf is implemente=
d on top of FILE* and assume it uses FileHandle:<br><br>class filebuf<br>{<=
br>public:</div><div>=C2=A0=C2=A0 filebuf():</div><div>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 handle(),</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 stdioHandle=
(nullptr)</div><div>=C2=A0=C2=A0 {<br></div><div>=C2=A0=C2=A0 }<br></div><d=
iv><br>=C2=A0=C2=A0 filebuf* open (const char* filename,=C2=A0 ios_base::op=
enmode mode)<br>=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this-&gt;h=
andle =3D os_file_open(filename); //ignoring mode for brevity<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 return this;<br>=C2=A0=C2=A0 }<br></div><div><br></di=
v><div>=C2=A0=C2=A0 FILE* file()</div><div>=C2=A0=C2=A0 {</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 if (this-&gt;stdHandle =3D=3D nullptr)</div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br></div><div>=C2=A0 =C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0 mallocate(this-&gt;stdHandle);<div>=C2=A0 =C2=A0=C2=A0 =C2=A0 =
=C2=A0 initialiseStdioHandleFromOsHandle(this-&gt;stdHandle, this-&gt;handl=
e);</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br></div>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 return this-&gt;stdHandle;</div><div>=C2=A0=C2=A0 }</div><div>=
<br></div><div>private:<br>=C2=A0=C2=A0 FileHandle handle;<br></div><div>=
=C2=A0=C2=A0 FILE* stdHandle;<br></div><div>};<br><br>Okay so I&#39;ve been=
 forced to add a FILE* member which is initialised on demand.</div><div>Tha=
t is one possible implementation with a slight bloat to filebuf.</div><div>=
Is that a constraint too far?<br></div><div><br></div><div>Now there is a p=
roblem with this if you want to add a filebuf constructor from a native Fil=
eHandle which already maps to some other FILE* object.</div><div>i.e.</div>=
<div>=C2=A0 FILE* myFile =3D open(fileName...);<br></div><div>=C2=A0 FileHa=
ndle handle =3D getNativeHandle(myFile);<br></div><div>=C2=A0 filebuf myBuf=
f(FileHandle).</div><div>=C2=A0 FILE* myBuffsFile =3D myBuff.file();</div><=
div>=C2=A0 assert(myBuffsFile !=3D myFile); <br></div><div><br></div><div>H=
owever, if you know that&#39;s true you would be better of using a FILE* co=
nstructor:</div><div><br></div><div>filebuf::filebuf(FILE* stdFile):</div><=
div>=C2=A0=C2=A0 handle(getNativeHandle(stdFile),</div><div>=C2=A0=C2=A0 st=
dioHandle(stdFile)<br></div><div>{</div><div>}</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fbaa10be-1d69-43e7-ade6-6b392f347147%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fbaa10be-1d69-43e7-ade6-6b392f347147=
%40isocpp.org</a>.<br />

------=_Part_240_2116814805.1503532663587--

------=_Part_239_1761421949.1503532663587--

.

On Wednesday, 23 August 2017 16:57:43 PDT tortoise741@gmail.com wrote:
> That is one possible implementation with a slight bloat to filebuf.
> Is that a constraint too far?

There's one very important difference between using FILE* and using the
underlying OS: the stdio buffers. Unless you remember to flush, this may come
out in the wrong order:

 fwrite("Hello", 5, 1, buf->file());
 buf->write("World", 5);

An implementation that always uses FILE* will always be synchronised. An
implementation that can run without FILE* will need to have two codepaths: one
for when it doesn't have FILE* and one for when it does. That leads me to the
conclusion that it's better to just use FILE* directly and avoid the native
codepath.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1722963.h7fJErj5fn%40tjmaciei-mobl1.

.

------=_Part_34_1568316548.1503561124211
Content-Type: multipart/alternative;
 boundary="----=_Part_35_978130353.1503561124211"

------=_Part_35_978130353.1503561124211
Content-Type: text/plain; charset="UTF-8"



On Thursday, 24 August 2017 01:29:23 UTC+1, Thiago Macieira wrote:
>
> On Wednesday, 23 August 2017 16:57:43 PDT torto...@gmail.com <javascript:>
> wrote:
> > That is one possible implementation with a slight bloat to filebuf.
> > Is that a constraint too far?
>
> There's one very important difference between using FILE* and using the
> underlying OS: the stdio buffers. Unless you remember to flush, this may
> come
> out in the wrong order:
>
>         fwrite("Hello", 5, 1, buf->file());
>         buf->write("World", 5);
>
> An implementation that always uses FILE* will always be synchronised. An
> implementation that can run without FILE* will need to have two codepaths:
> one
> for when it doesn't have FILE* and one for when it does. That leads me to
> the
> conclusion that it's better to just use FILE* directly and avoid the
> native
> codepath.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> Or to have separate stdio_filebuf and native_filebuf classes

but which is std::filebuf or is it a different beast altogether?

[we also have sync_with_stdio() for that case though that only applies to
the standard streams so is easy to special case.
Besides which they are viewed as iostreams not fstreams regardless of
implementation or they'd be in the fstream header]

I'm not sure you can mandate a native_filebuf as it is inherantly
implementation dependent.
For an implementation based on FILE* it would be redundant.

On the other hand if you know you have a FILE* you can use setvbuf and its
ilk to control the use buffering
and thus whether you need to sync.

I guess a subtle but important difference between a stdio_filebuf and a
native_filebuf is that the buffering is (I think) always on by default
for stdio. You can't do the equivalent of setvbuf() when you fopen() a file
but the buffers could be lazily constructed.

I'm no longer sure what the right thing to put in a proposal (other than
the choices) should be.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/87f4b19b-aec5-4c95-9ac4-1186ba693db8%40isocpp.org.

------=_Part_35_978130353.1503561124211
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, 24 August 2017 01:29:23 UTC+1, Thiago=
 Macieira  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday,=
 23 August 2017 16:57:43 PDT <a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"SCJqDjstCwAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">torto...@gmail.com</a> wrote:
<br>&gt; That is one possible implementation with a slight bloat to filebuf=
..
<br>&gt; Is that a constraint too far?
<br>
<br>There&#39;s one very important difference between using FILE* and using=
 the=20
<br>underlying OS: the stdio buffers. Unless you remember to flush, this ma=
y come=20
<br>out in the wrong order:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fwrite(&quot;Hello&quot=
;, 5, 1, buf-&gt;file());
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0buf-&gt;write(&quot;Wor=
ld&quot;, 5);
<br>
<br>An implementation that always uses FILE* will always be synchronised. A=
n=20
<br>implementation that can run without FILE* will need to have two codepat=
hs: one=20
<br>for when it doesn&#39;t have FILE* and one for when it does. That leads=
 me to the=20
<br>conclusion that it&#39;s better to just use FILE* directly and avoid th=
e native=20
<br>codepath.
<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><div>Or to have separate stdio_filebuf and native_fil=
ebuf classes</div><div><br></div><div>but which is std::filebuf or is it a =
different beast altogether?</div><div><br></div><div>[we also have sync_wit=
h_stdio() for that case though that only applies to the standard streams so=
 is easy to special case.</div><div>Besides which they are viewed as iostre=
ams not fstreams regardless of implementation or they&#39;d be in the fstre=
am header]<br></div>=C2=A0</div><div>I&#39;m not sure you can mandate a nat=
ive_filebuf as it is inherantly implementation dependent.</div><div>For an =
implementation based on FILE* it would be redundant.</div><div><br></div><d=
iv>On the other hand if you know you have a FILE* you can use setvbuf and i=
ts ilk to control the use buffering</div><div>and thus whether you need to =
sync.</div><div><br></div><div>I guess a subtle but important difference be=
tween a stdio_filebuf and a native_filebuf is that the buffering is (I thin=
k) always on by default</div><div>for stdio. You can&#39;t do the equivalen=
t of setvbuf() when you fopen() a file but the buffers could be lazily cons=
tructed.<br></div><div><br></div><div>I&#39;m no longer sure what the right=
 thing to put in a proposal (other than the choices) should be.<br></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/87f4b19b-aec5-4c95-9ac4-1186ba693db8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/87f4b19b-aec5-4c95-9ac4-1186ba693db8=
%40isocpp.org</a>.<br />

------=_Part_35_978130353.1503561124211--

------=_Part_34_1568316548.1503561124211--

.

------=_Part_747_439828910.1503564295162
Content-Type: multipart/alternative;
 boundary="----=_Part_748_2108470520.1503564295163"

------=_Part_748_2108470520.1503564295163
Content-Type: text/plain; charset="UTF-8"



On Thursday, 24 August 2017 08:52:04 UTC+1, Bruce Adams wrote:
>
>
>
> On Thursday, 24 August 2017 01:29:23 UTC+1, Thiago Macieira wrote:
>>
>> On Wednesday, 23 August 2017 16:57:43 PDT torto...@gmail.com wrote:
>> > That is one possible implementation with a slight bloat to filebuf.
>> > Is that a constraint too far?
>>
>> There's one very important difference between using FILE* and using the
>> underlying OS: the stdio buffers. Unless you remember to flush, this may
>> come
>> out in the wrong order:
>>
>>         fwrite("Hello", 5, 1, buf->file());
>>         buf->write("World", 5);
>>
>> An implementation that always uses FILE* will always be synchronised. An
>> implementation that can run without FILE* will need to have two
>> codepaths: one
>> for when it doesn't have FILE* and one for when it does. That leads me to
>> the
>> conclusion that it's better to just use FILE* directly and avoid the
>> native
>> codepath.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>> Or to have separate stdio_filebuf and native_filebuf classes
>
> but which is std::filebuf or is it a different beast altogether?
>
> [we also have sync_with_stdio() for that case though that only applies to
> the standard streams so is easy to special case.
> Besides which they are viewed as iostreams not fstreams regardless of
> implementation or they'd be in the fstream header]
>
> I'm not sure you can mandate a native_filebuf as it is inherantly
> implementation dependent.
> For an implementation based on FILE* it would be redundant.
>
> On the other hand if you know you have a FILE* you can use setvbuf and its
> ilk to control the use buffering
> and thus whether you need to sync.
>
> I guess a subtle but important difference between a stdio_filebuf and a
> native_filebuf is that the buffering is (I think) always on by default
> for stdio. You can't do the equivalent of setvbuf() when you fopen() a
> file but the buffers could be lazily constructed.
>
> I'm no longer sure what the right thing to put in a proposal (other than
> the choices) should be.
>

I guess the problem is that this lies on the cusp of C interoperability,
low-level OS interfacing, POSIX interoperability & C++.

I'll bite the bullet and have one more crack at it. Here's the new idea:

1)
require a new stdio_filebuf supporting construction using FILE* and FILE*
file() const to extract it.    - I don't think this is contraversal

2)
require a new native_filebuf supporting construction using
native_filedescriptor and a getDescriptor method to obtain it.
FileDescriptor is left implementation defined.

3)
#ifdef _POSIX_C_SOURCE

introduce a posix namespace and require

// a non-naked file descriptor
struct std::posix::file_descriptor
{
   int fileDescriptor
};

A std::posix::filebuf class having a constructor allowing a
std::posix::file_descriptor in its constructor
and returning the same via a fileno() method.

This is more contraversal as there is currently no C++ posix binding but
why not start here?

4)
It is implementation defined whether std::filebuf is the same as (i.e. a
typedef of) std::stdio_buffer or std::native_filebuf or something else.

It is implementation whether std::native_filebuf is the same as (i.e. a
typedef of) std::posix::filebuf

It is implementation whether std::file_descriptor is the same as (i.e. a
typedef of) std::posix::file_descriptor where _POSIX_C_SOURCE is defined

It is unsafe to rely on this in portable code.

5)
Conversion between the various filebuf types.

Direct conversion is not permitted.

A std::stdio_filebuf may be constructed from the other types if also given
a FILE*
A std::native_filebuf may be constructed from the other types if also given
a std::file_descriptor
A std::posix::filebuf may be constructed from the other types if also given
a std::posix::file_descriptor

So we provide 'copy-like' constructors like:

std::stdio_filebuf::stdio_filebuf(std::filebuf buf, FILE*)

This allows implementations to copy the buffer safely rather than
allocating a new one.

---
More complicated that originally planned. What do people think?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5f80eadc-1789-46d2-85d2-ba84ed09091d%40isocpp.org.

------=_Part_748_2108470520.1503564295163
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, 24 August 2017 08:52:04 UTC+1, Bruce =
Adams  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>On Thursday, 24 August 2017 01:29:23 UTC+1, Thiago Macieira  wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On Wednesday, 23 August 2017 16:57:=
43 PDT <a rel=3D"nofollow">torto...@gmail.com</a> wrote:
<br>&gt; That is one possible implementation with a slight bloat to filebuf=
..
<br>&gt; Is that a constraint too far?
<br>
<br>There&#39;s one very important difference between using FILE* and using=
 the=20
<br>underlying OS: the stdio buffers. Unless you remember to flush, this ma=
y come=20
<br>out in the wrong order:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fwrite(&quot;Hello&quot=
;, 5, 1, buf-&gt;file());
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0buf-&gt;write(&quot;Wor=
ld&quot;, 5);
<br>
<br>An implementation that always uses FILE* will always be synchronised. A=
n=20
<br>implementation that can run without FILE* will need to have two codepat=
hs: one=20
<br>for when it doesn&#39;t have FILE* and one for when it does. That leads=
 me to the=20
<br>conclusion that it&#39;s better to just use FILE* directly and avoid th=
e native=20
<br>codepath.
<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><div>Or to have separate stdio_filebuf and native_fil=
ebuf classes</div><div><br></div><div>but which is std::filebuf or is it a =
different beast altogether?</div><div><br></div><div>[we also have sync_wit=
h_stdio() for that case though that only applies to the standard streams so=
 is easy to special case.</div><div>Besides which they are viewed as iostre=
ams not fstreams regardless of implementation or they&#39;d be in the fstre=
am header]<br></div>=C2=A0</div><div>I&#39;m not sure you can mandate a nat=
ive_filebuf as it is inherantly implementation dependent.</div><div>For an =
implementation based on FILE* it would be redundant.</div><div><br></div><d=
iv>On the other hand if you know you have a FILE* you can use setvbuf and i=
ts ilk to control the use buffering</div><div>and thus whether you need to =
sync.</div><div><br></div><div>I guess a subtle but important difference be=
tween a stdio_filebuf and a native_filebuf is that the buffering is (I thin=
k) always on by default</div><div>for stdio. You can&#39;t do the equivalen=
t of setvbuf() when you fopen() a file but the buffers could be lazily cons=
tructed.<br></div><div><br></div><div>I&#39;m no longer sure what the right=
 thing to put in a proposal (other than the choices) should be.<br></div></=
div></blockquote><div><br></div><div>I guess the problem is that this lies =
on the cusp of C interoperability, low-level OS interfacing, POSIX interope=
rability &amp; C++. <br></div><div><br></div><div>I&#39;ll bite the bullet =
and have one more crack at it. Here&#39;s the new idea:</div><div><br></div=
><div>1)<br></div><div>require a new stdio_filebuf supporting construction =
using FILE* and FILE* file() const to extract it.=C2=A0=C2=A0=C2=A0 - I don=
&#39;t think this is contraversal</div><div><br></div><div>2)<br></div><div=
>require a new native_filebuf supporting construction using native_filedesc=
riptor and a getDescriptor method to obtain it.</div><div>FileDescriptor is=
 left implementation defined.</div><div><br></div><div>3)<br></div><div>#if=
def _POSIX_C_SOURCE</div><div><br></div><div>introduce a posix namespace an=
d require<br></div><div><br></div><div>// a non-naked file descriptor<br></=
div><div>struct std::posix::file_descriptor</div><div>{</div><div>=C2=A0=C2=
=A0 int fileDescriptor</div><div>};<br></div><div><br></div><div>A std::pos=
ix::filebuf class having a constructor allowing a std::posix::file_descript=
or in its constructor</div><div>and returning the same via a fileno() metho=
d.</div><div><br></div><div>This is more contraversal as there is currently=
 no C++ posix binding but why not start here?<br></div><div><br></div><div>=
4)<br></div><div>It is implementation defined whether std::filebuf is the s=
ame as (i.e. a typedef of) std::stdio_buffer or std::native_filebuf or some=
thing else.</div><div><br></div><div><div>It is implementation whether std:=
:native_filebuf is the same as (i.e. a typedef of) std::posix::filebuf</div=
><div><br></div><div>It is implementation whether std::file_descriptor is t=
he same as (i.e. a typedef of) std::posix::file_descriptor where _POSIX_C_S=
OURCE is defined<br></div><div><br></div><div>It is unsafe to rely on this =
in portable code.<br></div><div><br></div><div>5)</div><div>Conversion betw=
een the various filebuf types.</div><div><br></div><div>Direct conversion i=
s not permitted.</div><div></div><div><br></div><div>A std::stdio_filebuf m=
ay be constructed from the other types if also given a FILE*</div><div>A st=
d::native_filebuf may be constructed from the other types if also given a s=
td::file_descriptor</div><div>A std::posix::filebuf may be constructed from=
 the other types if also given a std::posix::file_descriptor<br></div></div=
><div><br></div><div>So we provide &#39;copy-like&#39; constructors like:</=
div><div><br></div><div>std::stdio_filebuf::stdio_filebuf(std::filebuf buf,=
 FILE*)</div><div><br></div><div>This allows implementations to copy the bu=
ffer safely rather than allocating a new one.</div><div><br></div><div>---<=
/div><div>More complicated that originally planned. What do people think?</=
div><div><br></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5f80eadc-1789-46d2-85d2-ba84ed09091d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5f80eadc-1789-46d2-85d2-ba84ed09091d=
%40isocpp.org</a>.<br />

------=_Part_748_2108470520.1503564295163--

------=_Part_747_439828910.1503564295162--

.

On 24 August 2017 at 11:44,  <tortoise741@gmail.com> wrote:
> 1)
> require a new stdio_filebuf supporting construction using FILE* and FILE*
> file() const to extract it.    - I don't think this is contraversal
>
> 2)
> require a new native_filebuf supporting construction using
> native_filedescriptor and a getDescriptor method to obtain it.
> FileDescriptor is left implementation defined.
>
> 3)
> #ifdef _POSIX_C_SOURCE
>
> introduce a posix namespace and require
>
> // a non-naked file descriptor
> struct std::posix::file_descriptor
> {
>    int fileDescriptor
> };
>
> A std::posix::filebuf class having a constructor allowing a
> std::posix::file_descriptor in its constructor
> and returning the same via a fileno() method.
>
> This is more contraversal as there is currently no C++ posix binding but why
> not start here?
>
> 4)
> It is implementation defined whether std::filebuf is the same as (i.e. a
> typedef of) std::stdio_buffer or std::native_filebuf or something else.
>
> It is implementation whether std::native_filebuf is the same as (i.e. a
> typedef of) std::posix::filebuf
>
> It is implementation whether std::file_descriptor is the same as (i.e. a
> typedef of) std::posix::file_descriptor where _POSIX_C_SOURCE is defined
>
> It is unsafe to rely on this in portable code.
>
> 5)
> Conversion between the various filebuf types.
>
> Direct conversion is not permitted.
>
> A std::stdio_filebuf may be constructed from the other types if also given a
> FILE*
> A std::native_filebuf may be constructed from the other types if also given
> a std::file_descriptor
> A std::posix::filebuf may be constructed from the other types if also given
> a std::posix::file_descriptor
>
> So we provide 'copy-like' constructors like:
>
> std::stdio_filebuf::stdio_filebuf(std::filebuf buf, FILE*)
>
> This allows implementations to copy the buffer safely rather than allocating
> a new one.
>
> ---
> More complicated that originally planned. What do people think?

Strike 3, 4 and 5 and it looks fine. I think stdio_filebuf and
native_filebuf need to be mandated to be different
types from filebuf. The posix-specific type is useless for non-posix
users and is best left to some other specification.
I don't see how you construct a native_filebuf from something that is
not a native_filebuf even if you provide
a file descriptor additionally, and same goes for the other conversions.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaUKYur0ebNME8SV4O-YY22xuBoR5NCz4fR6xA-H5sKNQ%40mail.gmail.com.

.

------=_Part_2018_1441361583.1503617068544
Content-Type: multipart/alternative;
 boundary="----=_Part_2019_646613449.1503617068545"

------=_Part_2019_646613449.1503617068545
Content-Type: text/plain; charset="UTF-8"



On Thursday, 24 August 2017 09:58:12 UTC+1, Ville Voutilainen wrote:
>
> On 24 August 2017 at 11:44,  <torto...@gmail.com <javascript:>> wrote:
> > 1)
> > require a new stdio_filebuf supporting construction using FILE* and
> FILE*
> > file() const to extract it.    - I don't think this is contraversal
> >
> > 2)
> > require a new native_filebuf supporting construction using
> > native_filedescriptor and a getDescriptor method to obtain it.
> > FileDescriptor is left implementation defined.
> >
> > 3)
> > #ifdef _POSIX_C_SOURCE
> >
> > introduce a posix namespace and require
> >
> > // a non-naked file descriptor
> > struct std::posix::file_descriptor
> > {
> >    int fileDescriptor
> > };
> >
> > A std::posix::filebuf class having a constructor allowing a
> > std::posix::file_descriptor in its constructor
> > and returning the same via a fileno() method.
> >
> > This is more contraversal as there is currently no C++ posix binding but
> why
> > not start here?
> >
> > 4)
> > It is implementation defined whether std::filebuf is the same as (i.e. a
> > typedef of) std::stdio_buffer or std::native_filebuf or something else.
> >
> > It is implementation whether std::native_filebuf is the same as (i.e. a
> > typedef of) std::posix::filebuf
> >
> > It is implementation whether std::file_descriptor is the same as (i.e. a
> > typedef of) std::posix::file_descriptor where _POSIX_C_SOURCE is defined
> >
> > It is unsafe to rely on this in portable code.
> >
> > 5)
> > Conversion between the various filebuf types.
> >
> > Direct conversion is not permitted.
> >
> > A std::stdio_filebuf may be constructed from the other types if also
> given a
> > FILE*
> > A std::native_filebuf may be constructed from the other types if also
> given
> > a std::file_descriptor
> > A std::posix::filebuf may be constructed from the other types if also
> given
> > a std::posix::file_descriptor
> >
> > So we provide 'copy-like' constructors like:
> >
> > std::stdio_filebuf::stdio_filebuf(std::filebuf buf, FILE*)
> >
> > This allows implementations to copy the buffer safely rather than
> allocating
> > a new one.
> >
> > ---
> > More complicated that originally planned. What do people think?
>
> Strike 3, 4 and 5 and it looks fine. I think stdio_filebuf and
> native_filebuf need to be mandated to be different
> types from filebuf. The posix-specific type is useless for non-posix
> users and is best left to some other specification.
> I don't see how you construct a native_filebuf from something that is
> not a native_filebuf even if you provide
> a file descriptor additionally, and same goes for the other conversions.
>

3)
A posix binding for C++ is indeed a different beast. I'm not clear whether
that would come from C++ or from Posix.
My instinct is that it should come from the subset of C++ people that are
posix aware rather than the subset of Posix people who are C++ aware
(ignoring the Venn diagram).
There is a lot of semi-standard stuff to build on there e.g. errno
exceptions.
I threw it in there as food for thought because I am thinking that on Posix
a native_filebuf would typically be exactly the same as a posix_filebuf.
I want to see how they would cohabit in principle.

4)
What is the reason for mandating that stdio_filebuf *must* not be a typedef
for filebuf and likewise for native_filebuf?
How would you enforce that?

All I can think is to make sure that no methods are accidentally exposed
which are not mandated in the interface of filebuf itself.
However, many implementations add non-standard methods to the standard
interfaces already. This isn't always a good thing but
shouldn't the standard specify the minimum capability rather than the
maximum in most cases?


Consider the GNU libstdc++ implementation.
They have an implementation of stdio_filebuf
It derives from std::filebuf but adds no additional member variables.
and it adds both FILE* and POSIX FD constructors and accessors.

So here we have a case where stdio_filebuf == native_filebuf == filebuf in
terms of member variables at least.

They have a constructor which takes a std::filebuf and gives a
stdio_filebuf (== native_filebuf).
This is only possible in their implementation because it uses FILE* under
the hood and Posix provides fileno() to get the FD.

I was trying to think how you get from one to the other portably/safely.

The working definition of a native_filebuf is that is can be constructed
from a native file descriptor and provides a method
to get it. It could have it as a member.

With regards to item 5 its not so much that you are constructing a
native_filebuf from some other filebuf.
You are still constructing it from the native file descriptor but saying
that it relates to this other class in the filebuf family which is
in some way 'about the same' file.

The implementation might decide to do something special with that. Maybe
the equivalent of setvbuf() or ios::tie().
I don't have a good motivating use case there,

5) was not a good answer to the conversion problem

A question to ask is why would you need to convert?

I suppose if you wanted C style buffering but wanted to use fcntl for posix
advisory locks.
You want to drop down to the low-level descriptor for a file you've already
opened with stdio_filebuf::open()  (using fopen() internally)
or climb up from it for a file you've already opened with
native_filebuf::open()  (using open() internally)

We want to do that without requiring use of fdopen or fileno() as those are
posix specific.
I want a C++ friendly wrapper to hide that if possible.

For the Linux case you can have direct conversions. i.e.

class stdio_filebuf
{
   stdio_filebuf(native_filebuf& buf):
      stdioFileHandle(fdopen(buf.fileno(),
                             getStdioMode(buf.getMode())
  {
  }

  operator native_filebuf() { return native_filebuf(*this); }
};

but that may not work in the general.

It needs to be examined for a non-posix case.

A near miss on another Posix use case is wanting to use fprintf to write to
a PID file. The PID file is opened using open() with O_EXCL
which has no analogue in fopen(). It turns out that a fprintf for FDs,
dprintf() was standardised by POSIX in 2008.
I don't think there is an analogue for fscanf(). There you still need to
use fdopen().
Of course in C++ you can just use operator<< and operatior>> instead (not
to mention format library proposals under consideration already) so its
mostly academic.

On related notes:

What other non-posix platforms merit consideration? (preferably with source
available)

What use cases are there for native_filebuf outside fcntl on Posix (e.g. on
windows)?

RAII is one. The native file handle will be closed when the buffer is
destroyed.
That is enough in itself but are there any others for completeness?



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6b8ca02a-069c-4701-9dcd-7611e780f2ca%40isocpp.org.

------=_Part_2019_646613449.1503617068545
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, 24 August 2017 09:58:12 UTC+1, Ville =
Voutilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 Augus=
t 2017 at 11:44, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"m3ZlDf9ICwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">torto...@gmail.com</a>&gt; wrote:
<br>&gt; 1)
<br>&gt; require a new stdio_filebuf supporting construction using FILE* an=
d FILE*
<br>&gt; file() const to extract it. =C2=A0 =C2=A0- I don&#39;t think this =
is contraversal
<br>&gt;
<br>&gt; 2)
<br>&gt; require a new native_filebuf supporting construction using
<br>&gt; native_filedescriptor and a getDescriptor method to obtain it.
<br>&gt; FileDescriptor is left implementation defined.
<br>&gt;
<br>&gt; 3)
<br>&gt; #ifdef _POSIX_C_SOURCE
<br>&gt;
<br>&gt; introduce a posix namespace and require
<br>&gt;
<br>&gt; // a non-naked file descriptor
<br>&gt; struct std::posix::file_descriptor
<br>&gt; {
<br>&gt; =C2=A0 =C2=A0int fileDescriptor
<br>&gt; };
<br>&gt;
<br>&gt; A std::posix::filebuf class having a constructor allowing a
<br>&gt; std::posix::file_descriptor in its constructor
<br>&gt; and returning the same via a fileno() method.
<br>&gt;
<br>&gt; This is more contraversal as there is currently no C++ posix bindi=
ng but why
<br>&gt; not start here?
<br>&gt;
<br>&gt; 4)
<br>&gt; It is implementation defined whether std::filebuf is the same as (=
i.e. a
<br>&gt; typedef of) std::stdio_buffer or std::native_filebuf or something =
else.
<br>&gt;
<br>&gt; It is implementation whether std::native_filebuf is the same as (i=
..e. a
<br>&gt; typedef of) std::posix::filebuf
<br>&gt;
<br>&gt; It is implementation whether std::file_descriptor is the same as (=
i.e. a
<br>&gt; typedef of) std::posix::file_descriptor where _POSIX_C_SOURCE is d=
efined
<br>&gt;
<br>&gt; It is unsafe to rely on this in portable code.
<br>&gt;
<br>&gt; 5)
<br>&gt; Conversion between the various filebuf types.
<br>&gt;
<br>&gt; Direct conversion is not permitted.
<br>&gt;
<br>&gt; A std::stdio_filebuf may be constructed from the other types if al=
so given a
<br>&gt; FILE*
<br>&gt; A std::native_filebuf may be constructed from the other types if a=
lso given
<br>&gt; a std::file_descriptor
<br>&gt; A std::posix::filebuf may be constructed from the other types if a=
lso given
<br>&gt; a std::posix::file_descriptor
<br>&gt;
<br>&gt; So we provide &#39;copy-like&#39; constructors like:
<br>&gt;
<br>&gt; std::stdio_filebuf::stdio_<wbr>filebuf(std::filebuf buf, FILE*)
<br>&gt;
<br>&gt; This allows implementations to copy the buffer safely rather than =
allocating
<br>&gt; a new one.
<br>&gt;
<br>&gt; ---
<br>&gt; More complicated that originally planned. What do people think?
<br>
<br>Strike 3, 4 and 5 and it looks fine. I think stdio_filebuf and
<br>native_filebuf need to be mandated to be different
<br>types from filebuf. The posix-specific type is useless for non-posix
<br>users and is best left to some other specification.
<br>I don&#39;t see how you construct a native_filebuf from something that =
is
<br>not a native_filebuf even if you provide
<br>a file descriptor additionally, and same goes for the other conversions=
..
<br></blockquote><div>=C2=A0</div><div>3)<br></div><div>A posix binding for=
 C++ is indeed a different beast. I&#39;m not clear whether that would come=
 from C++ or from Posix.</div><div>My instinct is that it should come from =
the subset of C++ people that are posix aware rather than the subset of Pos=
ix people who are C++ aware (ignoring the Venn diagram).<br></div><div>Ther=
e is a lot of semi-standard stuff to build on there e.g. errno exceptions.<=
/div><div>I threw it in there as food for thought because I am thinking tha=
t on Posix a native_filebuf would typically be exactly the same as a posix_=
filebuf.</div><div>I want to see how they would cohabit in principle.</div>=
<div><br></div><div>4)<br></div><div>What is the reason for mandating that =
stdio_filebuf *must* not be a typedef for filebuf and likewise for native_f=
ilebuf?</div><div></div><div>How would you enforce that?</div><div><br></di=
v><div>All I can think is to make sure that no methods are accidentally exp=
osed which are not mandated in the interface of filebuf itself.</div><div>H=
owever, many implementations add non-standard methods to the standard inter=
faces already. This isn&#39;t always a good thing but<br></div><div>shouldn=
&#39;t the standard specify the minimum capability rather than the maximum =
in most cases?<br></div><div><br></div><div><div><div><br></div><div>Consid=
er the GNU libstdc++ implementation.<br></div><div>They have an implementat=
ion of stdio_filebuf <br></div><div>It derives from std::filebuf but adds n=
o additional member variables.</div><div>and it adds both FILE* and POSIX F=
D constructors and accessors.</div><div><br></div><div>So here we have a ca=
se where stdio_filebuf =3D=3D native_filebuf =3D=3D filebuf in terms of mem=
ber variables at least.<br></div><div><br></div>They have a constructor whi=
ch takes a std::filebuf and gives a stdio_filebuf (=3D=3D native_filebuf).<=
div>This is only possible in their implementation because it uses FILE* und=
er the hood and Posix provides fileno() to get the FD.</div></div><div><div=
><br></div><div>I was trying to think how you get from one to the other por=
tably/safely.</div><br></div></div><div></div>The working definition of a n=
ative_filebuf is that is can be constructed from a native file descriptor a=
nd provides a method<div>to get it. It could have it as a member.<br></div>=
<div><div><br></div><div>With regards to item 5 its not so much that you ar=
e constructing a native_filebuf from some other filebuf.</div><div>You are =
still constructing it from the native file descriptor but saying that it re=
lates to this other class in the filebuf family which is</div><div>in some =
way &#39;about the same&#39; file.</div><div><br></div><div>The implementat=
ion might decide to do something special with that. Maybe the equivalent of=
 setvbuf() or ios::tie().<br></div><div>I don&#39;t have a good motivating =
use case there,<br></div><br><div>5) was not a good answer to the conversio=
n problem<br></div><div><br></div><div>A question to ask is why would you n=
eed to convert?</div><div><br></div><div>I suppose if you wanted C style bu=
ffering but wanted to use fcntl for posix advisory locks.</div><div>You wan=
t to drop down to the low-level descriptor for a file you&#39;ve already op=
ened with stdio_filebuf::open()=C2=A0 (using fopen() internally)<br></div><=
div>or climb up from it for a file you&#39;ve already opened with native_fi=
lebuf::open()=C2=A0 (using open() internally)</div><div><br></div><div>We w=
ant to do that without requiring use of fdopen or fileno() as those are pos=
ix specific.</div><div>I want a C++ friendly wrapper to hide that if possib=
le.</div><div><br></div><div>For the Linux case you can have direct convers=
ions. i.e.</div><div><br></div><div>class stdio_filebuf</div><div>{<br></di=
v><div>=C2=A0=C2=A0 stdio_filebuf(native_filebuf&amp; buf):</div><div>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 stdioFileHandle(fdopen(buf.fileno(),</div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 getStdioMode(buf.getMode())</div><div>=C2=A0 {<br></div>=
<div><div>=C2=A0 }<br></div><div><br></div><div>=C2=A0 operator native_file=
buf() { return native_filebuf(*this); }</div><div>};</div><div><br></div><d=
iv>but that may not work in the general.<br></div><div><br></div><div>It ne=
eds to be examined for a non-posix case.</div><div><br></div><div></div><di=
v><div>A near miss on another Posix use case is wanting to use fprintf to w=
rite=20
to a PID file. The PID file is opened using open() with O_EXCL</div><div>wh=
ich has no analogue in fopen(). It turns out that a fprintf for FDs, dprint=
f() was standardised by POSIX in 2008.</div><div>I don&#39;t think there is=
 an analogue for fscanf(). There you still need to use fdopen(). <br></div>=
<div>Of course in C++ you can just use operator&lt;&lt; and operatior&gt;&g=
t; instead (not to mention format library proposals under consideration alr=
eady) so its mostly academic.<br></div><div><br></div></div><div>On related=
 notes:</div><div><br></div><div><div>What other non-posix platforms merit =
consideration? (preferably with source available)<br></div><div><br></div><=
div></div>What use cases are there for native_filebuf outside fcntl on Posi=
x (e.g. on windows)?</div><div><br></div><div>RAII is one. The native file =
handle will be closed when the buffer is destroyed.</div><div>That is enoug=
h in itself but are there any others for completeness?<br></div><div><br></=
div>=C2=A0<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6b8ca02a-069c-4701-9dcd-7611e780f2ca%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6b8ca02a-069c-4701-9dcd-7611e780f2ca=
%40isocpp.org</a>.<br />

------=_Part_2019_646613449.1503617068545--

------=_Part_2018_1441361583.1503617068544--

.

------=_Part_196_278162738.1504833420354
Content-Type: multipart/alternative;
 boundary="----=_Part_197_1391910604.1504833420354"

------=_Part_197_1391910604.1504833420354
Content-Type: text/plain; charset="UTF-8"

I've created a first draft for comment based on this discussion and a
little further thought.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2643f16e-8c3b-4ec1-b0dd-c8a7923b69b1%40isocpp.org.

------=_Part_197_1391910604.1504833420354
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve created a first draft for comment based on this d=
iscussion and a little further thought.<br><br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2643f16e-8c3b-4ec1-b0dd-c8a7923b69b1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2643f16e-8c3b-4ec1-b0dd-c8a7923b69b1=
%40isocpp.org</a>.<br />

------=_Part_197_1391910604.1504833420354--

------=_Part_196_278162738.1504833420354
Content-Type: application/pdf; name=access_file_descriptors.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=access_file_descriptors.pdf
X-Attachment-Id: bec8e944-595c-4805-9028-258e0935af88
Content-ID: <bec8e944-595c-4805-9028-258e0935af88>

JVBERi0xLjMKJf////8KMSAwIG9iago8PCAvVGl0bGUgKGZpbGUgc3RyZWFtcyBhbmQgYWNjZXNz
IHRvIHRoZSBmaWxlIGRlc2NyaXB0b3IpCi9BdXRob3IgKEJydWNlIFMuIE8uIEFkYW1zKQovQ3Jl
YXRvciAoQXNjaWlkb2N0b3IgUERGIDEuNS4wLmFscGhhLjE2LCBiYXNlZCBvbiBQcmF3biAyLjIu
MikKL1Byb2R1Y2VyIChCcnVjZSBTLiBPLiBBZGFtcykKL01vZERhdGUgKEQ6MjAxNzA5MDgwMjA5
NDQrMDEnMDAnKQovQ3JlYXRpb25EYXRlIChEOjIwMTcwOTA4MDIwOTQ0KzAxJzAwJykKPj4KZW5k
b2JqCjIgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cKL1BhZ2VzIDMgMCBSCi9OYW1lcyAxMiAwIFIK
L091dGxpbmVzIDk0IDAgUgovUGFnZUxhYmVscyAxMjUgMCBSCi9QYWdlTW9kZSAvVXNlT3V0bGlu
ZXMKL09wZW5BY3Rpb24gWzcgMCBSIC9GaXRIIDg0Mi44OV0KL1ZpZXdlclByZWZlcmVuY2VzIDw8
IC9EaXNwbGF5RG9jVGl0bGUgdHJ1ZQo+Pgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFn
ZXMKL0NvdW50IDEyCi9LaWRzIFs3IDAgUiAxMCAwIFIgMjAgMCBSIDI4IDAgUiA0MSAwIFIgNDcg
MCBSIDUzIDAgUiA1NiAwIFIgNjcgMCBSIDczIDAgUiA4MSAwIFIgODUgMCBSXQo+PgplbmRvYmoK
NCAwIG9iago8PCAvTGVuZ3RoIDIKPj4Kc3RyZWFtCnEKCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9i
ago8PCAvVHlwZSAvUGFnZQovUGFyZW50IDMgMCBSCi9NZWRpYUJveCBbMCAwIDU5NS4yOCA4NDEu
ODldCi9Dcm9wQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0JsZWVkQm94IFswIDAgNTk1LjI4IDg0
MS44OV0KL1RyaW1Cb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQXJ0Qm94IFswIDAgNTk1LjI4IDg0
MS44OV0KL0NvbnRlbnRzIDQgMCBSCi9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWy9QREYgL1RleHQg
L0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldCj4+Cj4+CmVuZG9iago2IDAgb2JqCjw8IC9MZW5ndGgg
NTE4Cj4+CnN0cmVhbQpxCi9EZXZpY2VSR0IgY3MKMC42IDAuNiAwLjYgc2NuCi9EZXZpY2VSR0Ig
Q1MKMC42IDAuNiAwLjYgU0NOCgpCVAoxMjQuNzg3IDM2MS42OTY1IFRkCi9GMS4wIDI3IFRmCjw2
NjY5NmM2NTIwNzM3NDcyNjU2MTZkNzMyMDYxNmU2NDIwNjE2MzYzNjU3MzczMjA3NDZmMjA3NDY4
NjUyMDY2Njk2YzY1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjYg
MC42IDAuNiBzY24KMC42IDAuNiAwLjYgU0NOCgpCVAo0MTQuOTAyIDMyNy42NzY1IFRkCi9GMS4w
IDI3IFRmCjw2NDY1NzM2MzcyNjk3MDc0NmY3Mj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAg
MC4wIDAuMCBzY24KMC4wOTQxIDAuMDk0MSAwLjA5NDEgc2NuCjAuMDk0MSAwLjA5NDEgMC4wOTQx
IFNDTgoKQlQKNDM1LjIxNDMgMjkzLjIwNDkgVGQKL0YxLjAgMTMgVGYKWzw0MjcyNzU2MzY1MjA1
MzJlMjA0ZjJlMjA0MT4gMjAuMDE5NSA8NjQ2MTZkNzM+XSBUSgpFVAoKMC4wIDAuMCAwLjAgU0NO
CjAuMCAwLjAgMC4wIHNjbgpRCgplbmRzdHJlYW0KZW5kb2JqCjcgMCBvYmoKPDwgL1R5cGUgL1Bh
Z2UKL1BhcmVudCAzIDAgUgovTWVkaWFCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQ3JvcEJveCBb
MCAwIDU5NS4yOCA4NDEuODldCi9CbGVlZEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9UcmltQm94
IFswIDAgNTk1LjI4IDg0MS44OV0KL0FydEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9Db250ZW50
cyA2IDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdl
QyAvSW1hZ2VJXQovRm9udCA8PCAvRjEuMCA4IDAgUgo+Pgo+Pgo+PgplbmRvYmoKOCAwIG9iago8
PCAvVHlwZSAvRm9udAovQmFzZUZvbnQgL2I4MTVkYitOb3RvU2VyaWYKL1N1YnR5cGUgL1RydWVU
eXBlCi9Gb250RGVzY3JpcHRvciAxMjcgMCBSCi9GaXJzdENoYXIgMzIKL0xhc3RDaGFyIDI1NQov
V2lkdGhzIDEyOSAwIFIKL1RvVW5pY29kZSAxMjggMCBSCj4+CmVuZG9iago5IDAgb2JqCjw8IC9M
ZW5ndGggODUzMgo+PgpzdHJlYW0KcQovRGV2aWNlUkdCIGNzCjAuMiAwLjIgMC4yIHNjbgovRGV2
aWNlUkdCIENTCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNzgyLjM5NCBUZAovRjIuMCAyMiBU
Zgo8NDQ2NTY2Njk2ZTY5NzQ2OTZmNmU3Mz4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4w
IDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNzUzLjIw
NiBUZAovRjEuMCAxMC41IFRmCjw1NDY4Njk3MzIwNjQ2ZjYzNzU2ZDY1NmU3NDIwNzU3MzY1NzMy
MDc0Njg2NTIwNjY2ZjZjNmM2Zjc3Njk2ZTY3MjA3NDY1NzI2ZDczM2E+IFRqCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4y
IDAuMiBTQ04KCkJUCjU2Ljg4MDUgNzI1LjQyNiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQK
CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24K
MC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA3MjUuNDI2IFRkCi9GMS4wIDEwLjUgVGYKPDRlNjE3
NDY5NzY2NTIwNDY2OTZjNjUyMDQ0NjU3MzYzNzI2OTcwNzQ2ZjcyMjAyZDIwNmQ2NTYxNmU2OTZl
NjcyMDYxNmUyMDc1NmU2NDY1NzI2Yzc5Njk2ZTY3MjA3MDZmNzM3MzY5NjI2Yzc5MjA0ZjUzMjA3
MzcwNjU2MzY5NjY2OTYzMjA2ODYxNmU2NDZjNjUyMDc0NmYyMDY2Njk2YzY1PiBUagpFVAoKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4y
IDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDcwMy42NDYgVGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRq
CkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgNzAzLjY0NiBUZAovRjEuMCAxMC41IFRmCjw0
NjQ0MjAyZDIwNjEyMDUwNmY3MzY5NzgyMDY2Njk2YzY1MjA2NDY1NzM2MzcyNjk3MDc0NmY3MjIw
Mjg2MTIwNzM3MDY1NjM2OTYxNmMyMDYzNjE3MzY1MjA2ZjY2MjA2MTIwNmU2MTc0Njk3NjY1MjA2
NjY5NmM2NTIwNjQ2NTczNjM3MjY5NzA3NDZmNzIyOT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
QlQKNTYuODgwNSA2ODEuODY2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAw
LjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjY2LjI0IDY4MS44NjYgVGQKL0YxLjAgMTAuNSBUZgo8NDg0MTRlNDQ0YzQ1MjAy
ZDIwNjEyMDc3Njk2ZTY0NmY3NzczMjA2NjY5NmM2NTIwNjg2MTZlNjQ2YzY1MjAyODYxMjA3Mzcw
NjU2MzY5NjE2YzIwNjM2MTczNjUyMDZmNjYyMDYxMjA2ZTYxNzQ2OTc2NjUyMDY2Njk2YzY1MjA2
NDY1NzM2MzcyNjk3MDc0NmY3MjI5PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA2NTQuMDg2IFRk
Ci9GMS4wIDEwLjUgVGYKPDUzNjU2NTIwNjE2YzczNmYzYTIwPiBUagpFVAoKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBzY24KMC4yNTg4IDAuNTQ1
MSAwLjc5MjIgU0NOCgpCVAo5My41Njg1IDY1NC4wODYgVGQKL0YxLjAgMTAuNSBUZgo8Njg3NDc0
NzA3MzNhMmYyZjY1NmUyZTc3Njk2YjY5NzA2NTY0Njk2MTJlNmY3MjY3MmY3NzY5NmI2OTJmNDY2
OTZjNjU1ZjY0NjU3MzYzNzI2OTcwNzQ2ZjcyPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAw
LjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA2MDku
OTc0IFRkCi9GMi4wIDIyIFRmCjw0ZDZmNzQ2OTc2NjE3NDY5NmY2ZT4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNTYuODgwNSA1ODAuNzg2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDU4MC43ODYgVGQKL0YxLjAgMTAuNSBUZgpbPDQ5NmU3
NDY1NzI2ZjcwNjU3Mj4gMjAuMDE5NSA8NjE3NDY5NmY2ZTIwNjI2NTc0Nzc2NTY1NmUyMDQzMmIy
YjIwNzM3NDcyNjU2MTZkNzMyMDYxNmU2NDIwNmY3MDY1NzI+IDIwLjAxOTUgPDYxNzQ2OTZmNmU3
MzIwNzU3MzY5NmU2NzIwNzA2ZjczNjk3ODIwNDY2OTZjNjUyMDQ0NjU3MzYzNzI2OTcwNzQ2Zjcy
NzM+XSBUSgpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIg
MC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDU1OS4wMDYgVGQKL0YxLjAg
MTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAg
VGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgNTU5LjAwNiBUZAov
RjEuMCAxMC41IFRmCls8NDk2ZTc0NjU3MjZmNzA2NTcyPiAyMC4wMTk1IDw2MTc0Njk2ZjZlMjA2
MjY1NzQ3NzY1NjU2ZTIwNDMyYjJiMjA3Mzc0NzI2NTYxNmQ3MzIwNjE2ZTY0MjA0MzIwNzM3NDY0
Njk2ZjIwNjY3NTZlNjM3NDY5NmY2ZTczMjA2MjYxNzM2NTY0MjA2ZjZlMjA0NjQ5NGM0NTJhPl0g
VEoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAu
MiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNTE5LjE2NiBUZAovRjIuMCAxOCBUZgo8NGU2MTc0Njk3
NjY1MjA0NjY5NmM2NTIwNDQ2NTczNjM3MjY5NzA3NDZmNzI3Mz4gVGoKRVQKCjAuMCAwLjAgMC4w
IFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMi4y
Njg1IFR3CgpCVAo0OC4yNCA0OTEuMTQ2IFRkCi9GMS4wIDEwLjUgVGYKWzw1MzZmNmQ2NTIwNmY3
MDY1NzI+IDIwLjAxOTUgPDYxNzQ2OTZmNmU3MzIwNmY2ZTIwNjEyMDUwNGY1MzQ5NTgyMDczNzk3
Mzc0NjU2ZDJjMjA2ZTZmNzQ2MTYyNmM3OTIwNzQ2ODZmNzM2NTIwNmQ2MTZiNjk2ZTY3MjA3NTcz
NjUyMDZmNjYyMDY2NjM2ZTc0NmMyODI5MmMyMDcyNjU3MTc1Njk3MjY1MjA2MTYzNjM2NTczNzMy
MDc0NmYyMDc0Njg2NT5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNDc1LjM2NiBU
ZAovRjEuMCAxMC41IFRmCjw3NTZlNjQ2NTcyNmM3OTY5NmU2NzIwNjY2OTZjNjUyMDY0NjU3MzYz
NzI2OTcwNzQ2ZjcyMmU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjMuMDMxNSBUdwoKQlQKNDguMjQgNDQ3LjU4
NiBUZAovRjEuMCAxMC41IFRmCls8NTQ2ODY1MjA0MzJiMmIyMDczNzQ2MTZlNjQ2MTcyNjQyMDY0
NmY2NTczMjA2ZTZmNzQyMDZkNjE2ZTY0NjE3NDY1MjA2MTZlPiAyMC4wMTk1IDw3OTIwNmQ2NTYz
Njg2MTZlNjk3MzZkMjA3NDZmMjA2MzZmNmU3NDcyNzU2Mzc0MjA2MTIwNzM3NDcyNjU2MTZkMjA2
Mjc1NjY2NjY1NzIyMDY2NzI2ZjZkMjA2MTIwNjY2OTZjNjU+XSBUSgpFVAoKCjAuMCBUdwowLjAg
MC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBT
Q04KCjAuODkwMiBUdwoKQlQKNDguMjQgNDMxLjgwNiBUZAovRjEuMCAxMC41IFRmCjw2NDY1NzM2
MzcyNjk3MDc0NmY3MjIwNmY3MjIwNzQ2ZjIwNmY2Mjc0NjE2OTZlMjA3NDY4NjUyMDc1NmU2NDY1
NzI2Yzc5Njk2ZTY3MjA2NjY5NmM2NTIwNjQ2NTczNjM3MjY5NzA3NDZmNzIyMDc0Njg2Zjc1Njc2
ODIwNjk3NDIwNjk3MzIwNjE2YzZkNmY3Mzc0MjA2MzY1NzI3NDYxNjk2ZTZjNzkyMDYxNjM2MzY1
NzM3MzY5NjI2YzY1MjA2OTZlMjA2MTZlPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0
IDQxNi4wMjYgVGQKL0YxLjAgMTAuNSBUZgo8Njk2ZDcwNmM2NTZkNjU2ZTc0NjE3NDY5NmY2ZTIw
NmY2ZTIwNjEyMDUwNGY1MzQ5NTgyMDczNzk3Mzc0NjU2ZDJlPiBUagpFVAoKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgowLjMy
MzEgVHcKCkJUCjQ4LjI0IDM4OC4yNDYgVGQKL0YxLjAgMTAuNSBUZgpbPDU0Njg2OTczMjA2ZDZm
NzQ2OTc2NjE3NDY5NmY2ZTIwNjE2YzczNmYyMDYxNzA3MDZjNjk2NTczMjA3NDZmMjA3MzZmNmQ2
NTIwNmU2ZjZlMjA1MDZmNzM2OTc4MjA2MjYxNzM2NTY0MjA2ZjcwNjU3Mj4gMjAuMDE5NSA8NjE3
NDY5NmU2NzIwNzM3OTczNzQ2NTZkNzMyZTIwNDY+IDQwLjAzOTEgPDZmNzIyMDY1Nzg2MTZkNzA2
YzY1MjA3NDY4NjUyMDU3Njk2ZTY0NmY3NzczPl0gVEoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0
OC4yNCAzNzIuNDY2IFRkCi9GMS4wIDEwLjUgVGYKWzw0MTUwNDkyMDY5NmU2MzZjNzU2NDY1NzMy
MDY2NzU2ZTYzNzQ2OTZmNmU3MzIwNmM2OTZiPiAyMC4wMTk1IDw2NTIwNGM2ZjYzNmI0NjY5NmM2
NTI4MjkyMDc3Njg2OTYzNjgyMDZkNjE2Yj4gMjAuMDE5NSA8NjUyMDc1NzM2NTIwNmY2NjIwNjEy
MDIyNDg0MTRlNDQ0YzQ1MjIyMDc0NmYyMDYxMjA2NjY5NmM2NTJlPl0gVEoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
MS42ODM3IFR3CgpCVAo0OC4yNCAzNDQuNjg2IFRkCi9GMS4wIDEwLjUgVGYKPDY2Njk2YzY1MjA2
YzZmNjM2YjY5NmU2NzIwNjk3MzIwNzU3MzY1NjQyMDY4NjU3MjY1MjA2MTczMjA2MTIwNjQ3MjY5
NzY2OTZlNjcyMDY1Nzg2MTZkNzA2YzY1MmUyMDQ5NzQyMDY5NzMyMDZlNmY3NDIwNzQ2ODY1MjA2
ZjZlNmM3OTIwNzU3MzY1MjA2MzYxNzM2NTJlMjA1NDY4NjUyMDcwNzI2OTZkNjE3Mjc5MjA3NTcz
NjUyMDYzNjE3MzY1PiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAg
c2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDMyOC45MDYgVGQK
L0YxLjAgMTAuNSBUZgpbPDYzNmY2ZTczNjk2NDY1NzI2NTY0MjA2OTczMjA3NDZmMjA3MDcyNmY3
NjY5NjQ2NTIwNjk2ZTc0NjU3MjZmNzA2NTcyPiAyMC4wMTk1IDw2MTYyNjk2YzY5NzQ3OTIwNzc2
OTc0NjgyMDc0Njg2NTIwNTA0ZjUzNDk1ODIwNjY3NTZlNjM3NDY5NmY2ZTczMjA2NjYzNmU3NDZj
MjgyOTJjMjA2YzZmNjM2YjY2MjgyOTIwMjYyMDY2NjQ2ZjcwNjU2ZTI4MjkyZT5dIFRKCkVUCgow
LjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjQ4LjI0IDMwMS4xMjYgVGQKL0YxLjAgMTAuNSBUZgo8NGY3NDY4NjU3MjIwNzU3
MzY1MjA2MzYxNzM2NTczMjA2MzZmNzU2YzY0MjA2MjY1MjA2MzZmNmM2YzYxNzQ2NTY0MjA2ODY1
NzI2NTIwNjk2ZTIwNzM3NTcwNzA2ZjcyNzQyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAg
MC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMjcz
LjM0NiBUZAovRjEuMCAxMC41IFRmCls8NDU3ODYxNmQ3MDZjNjUyMDZmNzA2NTcyPiAyMC4wMTk1
IDw2MTc0Njk2ZjZlNzMyMDYyNjE3MzY1NjQyMDZmNmUyMDY2NjM2ZTc0NmMyODI5M2E+XSBUSgpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIgMC4yIDAuMiBz
Y24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDI0NS41NjYgVGQKL0YxLjAgMTAuNSBUZgo8
YTU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgMjQ1LjU2NiBUZAovRjEuMCAxMC41
IFRmCjw2NjY5NmM2NTIwNmM2ZjYzNmI2OTZlNjcyMDc1NzM2OTZlNjcyMDQ2NWY1MzQ1NTQ0YzRi
MjgyOT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4y
IDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSAyMjMuNzg2IFRkCi9GMS4w
IDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4w
IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDIyMy43ODYgVGQK
L0YxLjAgMTAuNSBUZgo8NmU2ZjZlMmQ2MjZjNmY2MzZiNjk2ZTY3MjA0OTRmMjAyODc1NzM2OTZl
NjcyMDRmNWY0ZTRmNGU0MjRjNGY0MzRiMjA2ZjcyMjA0NjVmNTM0NTU0NTM0OTQ3MjkyZT4gVGoK
RVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAw
LjIgMC4yIFNDTgoKMC4wOTgxIFR3CgpCVAo0OC4yNCAxOTYuMDA2IFRkCi9GMS4wIDEwLjUgVGYK
PDRlNmY3NDY1MjA3NDY4NjE3NDIwNmU2ZjZlMmQ2MjZjNmY2MzZiNjk2ZTY3MjA0OTRmMjA2OTcz
MjA2ZTZmNzQyMDYxMjA2NzZmNmY2NDIwNjU3ODYxNmQ3MDZjNjUyMDY5NmUyMDc0Njg2OTczMjA2
MzZmNmU3NDY1Nzg3NDIwNjE3MzIwNDMyYjJiMjA3Mzc0NzI2NTYxNmQ3MzIwNjM3NTcyNzI2NTZl
NzQ2Yzc5MjA3MDcyNmY3NjY5NjQ2NTIwNmU2Zj4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0
OC4yNCAxODAuMjI2IFRkCi9GMS4wIDEwLjUgVGYKPDY0Njk3MjY1NjM3NDIwNzM3NTcwNzA2Zjcy
NzQyMDY2NmY3MjIwNmU2ZjZlMmQ2MjZjNmY2MzZiNjk2ZTY3MjA0OTRmMmU+IFRqCkVUCgowLjAg
MC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBT
Q04KCkJUCjQ4LjI0IDE1Mi40NDYgVGQKL0YxLjAgMTAuNSBUZgo8NTI2NTcxNzU2OTcyNjU2ZDY1
NmU3NDczM2E+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRj
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgMTI0LjY2NiBUZAov
RjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
CjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgozLjMzNSBUdwoKQlQKNjYu
MjQgMTI0LjY2NiBUZAovRjEuMCAxMC41IFRmCls8NjM2ZjZlNzM3NDcyNzU2Mzc0MjA2MTIwMjg2
NDY1NzI2OTc2NjU2NDIwNjM2YzYxNzM3MzIwNmY2Nj4gLTg5Ljg0MzggPDI5MjA3Mzc0NzI2NTYx
NmQ2Mjc1NjYyMDc0NmYyMDY5NmQ3MDZjNjU2ZDY1NmU3NDIwNjE2ZTIwNjY3Mzc0NzI2NTYxNmQy
MDYyNjE3MzY1NjQyMDZmNmUyMDYxMjA2ZTYxNzQ2OTc2NjUyMDY2Njk2YzY1Pl0gVEoKRVQKCgow
LjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4y
IDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCAxMDguODg2IFRkCi9GMS4wIDEwLjUgVGYKPDY0NjU3MzYz
NzI2OTcwNzQ2ZjcyPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAu
NSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDg3LjEwNiBU
ZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgozLjQyNDcgVHcKCkJU
CjY2LjI0IDg3LjEwNiBUZAovRjEuMCAxMC41IFRmCls8NmY2Mjc0NjE2OTZlMjA2MTIwNjY2OTZj
NjUyMDY0NjU3MzYzNzI2OTcwNzQ2ZjcyMjA2MTczMjA3NTczNjU2NDIwNzQ2ZjIwNjk2ZDcwNmM2
NTZkNjU2ZTc0MjA2MTZlMjA2NjczNzQ3MjY1NjE2ZDIwNmM2OTZiPiAyMC4wMTk1IDw2NTIwNmY2
MjZhNjU2Mzc0MjA2MjYxNzM2NTY0MjA2ZjZlMjA2ZTYxNzQ2OTc2NjUyMDQ5NGY+XSBUSgpFVAoK
CjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDcxLjMyNiBUZAovRjEuMCAxMC41IFRmCjw2Njc1NmU2
Mzc0Njk2ZjZlNzMyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KcQow
LjAgMC4wIDAuMCBzY24KMC4wIDAuMCAwLjAgU0NOCjEgdwowIEoKMCBqCltdIDAgZAovU3RhbXAx
IERvCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU0MS4wMDkgMTQuMzg4IFRk
Ci9GMS4wIDkgVGYKPDMxPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgpR
ClEKCmVuZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UKL1BhcmVudCAzIDAg
UgovTWVkaWFCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQ3JvcEJveCBbMCAwIDU5NS4yOCA4NDEu
ODldCi9CbGVlZEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9UcmltQm94IFswIDAgNTk1LjI4IDg0
MS44OV0KL0FydEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9Db250ZW50cyA5IDAgUgovUmVzb3Vy
Y2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXQovRm9u
dCA8PCAvRjIuMCAxNSAwIFIKL0YxLjAgOCAwIFIKPj4KL1hPYmplY3QgPDwgL1N0YW1wMSA5MiAw
IFIKPj4KPj4KL0Fubm90cyBbMTYgMCBSXQo+PgplbmRvYmoKMTEgMCBvYmoKWzEwIDAgUiAvWFla
IDAgODQxLjg5IG51bGxdCmVuZG9iagoxMiAwIG9iago8PCAvVHlwZSAvTmFtZXMKL0Rlc3RzIDEz
IDAgUgo+PgplbmRvYmoKMTMgMCBvYmoKPDwgL0tpZHMgWzY5IDAgUiA3MCAwIFJdCj4+CmVuZG9i
agoxNCAwIG9iagpbMTAgMCBSIC9YWVogMCA4NDEuODkgbnVsbF0KZW5kb2JqCjE1IDAgb2JqCjw8
IC9UeXBlIC9Gb250Ci9CYXNlRm9udCAvNTdiNTRiK05vdG9TZXJpZi1Cb2xkCi9TdWJ0eXBlIC9U
cnVlVHlwZQovRm9udERlc2NyaXB0b3IgMTMxIDAgUgovRmlyc3RDaGFyIDMyCi9MYXN0Q2hhciAy
NTUKL1dpZHRocyAxMzMgMCBSCi9Ub1VuaWNvZGUgMTMyIDAgUgo+PgplbmRvYmoKMTYgMCBvYmoK
PDwgL0JvcmRlciBbMCAwIDBdCi9BIDw8IC9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRw
czovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9GaWxlX2Rlc2NyaXB0b3IpCj4+Ci9TdWJ0eXBlIC9M
aW5rCi9SZWN0IFs5My41Njg1IDY1MS4wMiAzMTQuMjY4IDY2NS4zXQovVHlwZSAvQW5ub3QKPj4K
ZW5kb2JqCjE3IDAgb2JqClsxMCAwIFIgL1hZWiAwIDYzOC4yNyBudWxsXQplbmRvYmoKMTggMCBv
YmoKWzEwIDAgUiAvWFlaIDAgNTQzLjE5IG51bGxdCmVuZG9iagoxOSAwIG9iago8PCAvTGVuZ3Ro
IDkxMjMKPj4Kc3RyZWFtCnEKL0RldmljZVJHQiBjcwowLjIgMC4yIDAuMiBzY24KL0RldmljZVJH
QiBDUwowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDc4Ni42NjYgVGQKL0YyLjAgMTggVGYKPDQz
MjA3Mzc0NjQ2OTZmMjA2Njc1NmU2Mzc0Njk2ZjZlNzMyMDYyNjE3MzY1NjQyMDZmNmUyMDQ2NDk0
YzQ1MmE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCjAuMTM1NyBUdwoKQlQKNDguMjQgNzU4LjY0NiBUZAovRjEu
MCAxMC41IFRmCls8NDEyMDczNjU2NTZkNjk2ZTY3NmM3OTIwNzU2ZTcyNjU2YzYxNzQ2NTY0MjA2
OTczNzM3NTY1MjA2OTczMjA3NDZmMjA2MTZjNmM2Zjc3MjA0MzIwNzM3NDcyNjU2MTZkNzMyMDc0
NmYyMDY5NmU3NDY1NzI2ZjcwNjU3Mj4gMjAuMDE5NSA8NjE3NDY1MjA3MzY1NjU2ZDZjNjU3Mzcz
NmM3OTIwNzc2OTc0NjgyMDQzMjA3Mzc0NjQ2OTZmMjA2ZjcwNjU3Mj4gMjAuMDE5NSA8NjE3NDY5
NmY2ZTczPl0gVEoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgow
LjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgowLjc5NTkgVHcKCkJUCjQ4LjI0IDc0Mi44
NjYgVGQKL0YxLjAgMTAuNSBUZgpbPDYyNjE3MzY1NjQyMDZmNmUyMDQ2NDk0YzQ1MmE+IDEyMC4x
MTcyIDwyZTIwNDEyMDZjNjk2MjcyPiAyMC4wMTk1IDw2MTcyNzkyMDY2NzU2ZTYzNzQ2OTZmNmUy
MDc3NzI2OTc0NzQ2NTZlMjA2OTZlMjA0MzIwNmQ2MT4gMjAuMDE5NSA8NzkyMDc1NzM2NTIwNmY3
MjIwNzI2NTc0NzU3MjZlMjA2MTIwNjg2MTZlNjQ2YzY1MjA3NDZmMjA2MTZlMjA2ZjcwNjU2ZTIw
NjQ2NTc2Njk2MzY1MjA2MTczMjA2MT5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC4zMzA1IFR3
CgpCVAo0OC4yNCA3MjcuMDg2IFRkCi9GMS4wIDEwLjUgVGYKWzw0NjQ5NGM0NTJhPiAxMjAuMTE3
MiA8MmUyMDU0PiAyOS43ODUyIDw2ZjIwNzU3MzY1MjA3Mzc1NjM2ODIwNjEyMDY2NzU2ZTYzNzQ2
OTZmNmUyMDc3Njk3NDY4MjA2MTZlMjA0MzIwNjY3Mzc0NzI2NTYxNmQyMDcyNjU3MTc1Njk3MjY1
NzMyMDQ5NGYyMDZmNzA2NTcyPiAyMC4wMTk1IDw2MTc0Njk2ZjZlNzMyMDc0NmYyMDYyNjUyMDcz
Nzk2ZTYzNjg3MjZmNmU2OTczNjU2NDIwNjI2NTc0Nzc2NTY1NmU+XSBUSgpFVAoKCjAuMCBUdwow
LjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjQ4LjI0IDcxMS4zMDYgVGQKL0YxLjAgMTAuNSBUZgo8NzQ2ODY1NmQyMDYxNmU2
NDIwNzA2ZjczNzM2OTYyNmM3OTIwNzQ2ZjIwNmQ2MTY5NmU3NDYxNjk2ZTIwNmQ3NTZjNzQ2OTcw
NmM2NTIwNjg2MTZlNjQ2YzY1NzMyMDc0NmYyMDc0Njg2NTIwNzM2MTZkNjUyMDc1NmU2NDY1NzI2
Yzc5Njk2ZTY3MjA2NjY5NmM2NTJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgo3LjA3NDIgVHcKCkJUCjQ4LjI0
IDY4My41MjYgVGQKL0YxLjAgMTAuNSBUZgpbPDQxMjA0NjQ5NGM0NTJhMjA2ZDYxNmU2NDYxNzQ2
NTczMjA0MzIwNzM3NDY0Njk2ZjIwNjI2NTY4NjE3NjY5NmY3NTcyMjA3NzY4Njk2MzY4MjA2ZDYx
PiAyMC4wMTk1IDw3OTIwNjk2ZTYzNmM3NTY0NjUyMDYyNzU2NjY2NjU3MjY5NmU2NzIwMjg3MzY1
NjUyMDY2NmY3MjIwNjU3ODYxNmQ3MDZjNjU+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIHNjbgowLjI1ODggMC41NDUx
IDAuNzkyMiBTQ04KCkJUCjQ4LjI0IDY2Ny43NDYgVGQKL0YxLjAgMTAuNSBUZgpbPDY4NzQ3NDcw
NzMzYTJmMmY3Mzc0NjE2MzZiPiAyMC4wMTk1IDw2Zjc2NjU3MjY2NmM2Zjc3PiA2OS44MjQyIDwy
ZTYzNmY2ZDJmNzE3NTY1NzM3NDY5NmY2ZTczMmYzMjM0MzIzMzM2MzIzODJmNzc2ODYxNzQ3MzJk
NzQ2ODY1MmQ2NDY5NjY2NjY1NzI2NTZlNjM2NTJkNjI2NTc0Nzc2NTY1NmUyZDYxMmQ2NjY5NmM2
NTJkNjQ2NTczNjM3MjY5NzA3NDZmNzIyZDYxNmU2NDJkPl0gVEoKRVQKCjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgc2NuCjAuMjU4OCAwLjU0NTEg
MC43OTIyIFNDTgoKQlQKNDguMjQgNjUxLjk2NiBUZAovRjEuMCAxMC41IFRmCjw2NjY5NmM2NTJk
NzA2ZjY5NmU3NDY1NzI+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjEwNC40Njc1IDY1MS45NjYgVGQKL0Yx
LjAgMTAuNSBUZgpbPDI5MmUyMDQ5NzQyMDZkNjE+IDIwLjAxOTUgPDc5MjA2MjY1MjA3NDY4NjE3
NDIwNzQ2ODY1NzI2NTIwNjE3MjY1MjA3NTczNjUyMDYzNjE3MzY1NzMyMDc3Njg2NTcyNjUyMDYy
NzU2NjY2NjU3MjY5NmU2NzIwNjk2NDY1NmU3NDY5NjM2MTZjMjA3NDZmMjA3Mzc0NjQ2OTZmMjA2
OTczMjA2NDY1NzM2OTcyNjU2NDJlPl0gVEoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNjI0LjE4NiBU
ZAovRjEuMCAxMC41IFRmCjw1MjY1NzE3NTY5NzI2NTZkNjU2ZTc0NzMzYT4gVGoKRVQKCjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAw
LjIgMC4yIFNDTgoKQlQKNTYuODgwNSA1OTYuNDA2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNj
bgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDU5Ni40MDYgVGQKL0YxLjAgMTAuNSBUZgpbPDYz
NmY2ZTczNzQ3Mjc1NjM3NDIwNjEyMDI4NjQ2NTcyNjk3NjY1NjQyMDYzNmM2MTczNzMyMDZmNjY+
IC04OS44NDM4IDwyOTIwNzM3NDcyNjU2MTZkNjI3NTY2MjA3NDZmMjA2OTZkNzA2YzY1NmQ2NTZl
NzQyMDYxNmUyMDY2NzM3NDcyNjU2MTZkMjA2MjYxNzM2NTY0MjA2ZjZlMjA2MTIwNDY0OTRjNDUy
YT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNTc0LjYyNiBUZAovRjEuMCAx
MC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBU
YwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA1NzQuNjI2IFRkCi9G
MS4wIDEwLjUgVGYKWzw2ZjYyNzQ2MTY5NmUyMDYxMjA0NjQ5NGM0NTJhMjA2NjcyNmY2ZDIwNjEy
MDczNzQ3MjY1NjE2ZDYyNzU2NjIwNzU3MzY1NjQyMDc0NmYyMDY5NmQ3MDZjNjU2ZDY1NmU3NDIw
NjEyMDczNzQ2NDY5NmYyMDYyNjE3MzY1NjQyMDY2NzM3NDcyNjU2MTZkMjA2YzY5NmI+IDIwLjAx
OTUgPDY1MjA2ZjYyNmE2NTYzNzQyZT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAw
LjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDUzMC41MTQg
VGQKL0YyLjAgMjIgVGYKPDQzNzU3MjcyNjU2ZTc0MjA1MzZmNmM3NTc0Njk2ZjZlNzM+IFRqCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4y
IDAuMiBTQ04KCjQuNzY5NCBUdwoKQlQKNDguMjQgNTAxLjMyNiBUZAovRjEuMCAxMC41IFRmCls8
NGQ2MTZlPiAyMC4wMTk1IDw3OTIwNjk2ZDcwNmM2NTZkNjU2ZTc0NjE3NDY5NmY2ZTczMjA2ZjY2
MjA2YzY5NjI3Mzc0NjQ2MzJiMmIyMDcwNzI2Zjc2Njk2NDY1MjA3NDY4NjU2OTcyMjA2Zjc3NmUy
MDY1Nzg3NDY1NmU3MzY5NmY2ZTczMjA2MTZjNmM2Zjc3Njk2ZTY3MjA2MTIwNjI3NTY2NjY2NTcy
MjA3NDZmMjA2MjY1Pl0gVEoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgoyLjA3NiBUdwoKQlQKNDguMjQg
NDg1LjU0NiBUZAovRjEuMCAxMC41IFRmCls8NjM2ZjZlNzM3NDcyNzU2Mzc0NjU2NDIwNjY3MjZm
NmQyMDYxMjA0NjQ5NGM0NTJhMjA2ZjcyMjA2ZTYxNzQ2OTc2NjUyMDY2Njk2YzY1MjA2NDY1NzM2
MzcyNjk3MDc0NmY3MjIwNjQ2OTcyNjU2Mzc0NmM3OTIwNjE2ZTY0MjA2YzY5NmI+IDIwLjAxOTUg
PDY1MmQ3NzY5NzM2NTIwNzQ2ZjIwNmY2Mjc0NjE2OTZlMjA3NDY4NjUyMDQ2NDk0YzQ1MmEyMDZm
NzI+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjMuNDM3NSBUdwoKQlQKNDguMjQgNDY5Ljc2NiBU
ZAovRjEuMCAxMC41IFRmCjw2ZTYxNzQ2OTc2NjUyMDY2Njk2YzY1MjA2NDY1NzM2MzcyNjk3MDc0
NmY3MjIwNzc2ODY1NzI2NTIwNjk3NDIwNzc2MTczMjA3NTczNjU2NDIwNzQ2ZjIwNjM2ZjZlNzM3
NDcyNzU2Mzc0MjA3NDY4NjU2ZDIwNmY3MjIwNjk3MzIwNmY3NDY4NjU3Mjc3Njk3MzY1MjA2MTc2
NjE2OTZjNjE2MjZjNjUyMDY0NzU2NTIwNzQ2Zj4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0
OC4yNCA0NTMuOTg2IFRkCi9GMS4wIDEwLjUgVGYKPDY5NmQ3MDZjNjU2ZDY1NmU3NDYxNzQ2OTZm
NmUyMDY0NjU3NDYxNjk2YzczMjAyODY2NmY3MjIwNjU3ODYxNmQ3MDZjNjUyMDc3Njg2NTcyNjUy
MDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3MzIwNjk2ZDcwNmM2NTZkNjU2ZTc0NjU2NDIw
Njk2ZTIwNzQ2NTcyNmQ3MzIwNmY2NjIwNDY0OTRjNDUyYTIwNmY3MjIwNDY0NDI5MmU+IFRqCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4y
IDAuMiBTQ04KCjEuNjM3MiBUdwoKQlQKNDguMjQgNDI2LjIwNiBUZAovRjEuMCAxMC41IFRmCjw1
NDY4NjUyMDYzNjE2ZTZmNmU2OTYzNjE2YzIwNjE2ZTY0MjA2MTcyNjc3NTYxNjI2Yzc5MjA2ZDZm
NzI2NTIwNzA2ZjcyNzQ2MTYyNmM2NTIwNmQ2NTc0Njg2ZjY0MjA2ZjY2MjA2NDZmNjk2ZTY3MjA3
NDY4Njk3MzIwNjk3MzIwNjY2ZjcyMjA3NDY4NjUyMDc1NzM2NTcyMjA3NDZmMjA2NDY1NzI2OTc2
NjUyMDYxMjA2ZTY1Nzc+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC40MjI2IFR3CgpCVAo0OC4y
NCA0MTAuNDI2IFRkCi9GMS4wIDEwLjUgVGYKPDczNzQ3MjY1NjE2ZDYyNzU2NjIwNzQ2ODY1NmQ3
MzY1NmM3NjY1NzMyMDYyNjE3MzY1NjQyMDZmNmUyMDczNzQ2NDY5NmYyMDZmNzIyMDZlNjE3NDY5
NzY2NTIwNjY3NTZlNjM3NDY5NmY2ZTczMmUyMDU0Njg2NTcyNjUyMDYxNzI2NTIwNjEyMDY2NjU3
NzIwNzY2MTcyNjk2MTZlNzQ3MzIwNmY2NjIwNzQ2ODY5NzMyMDYxNzY2MTY5NmM2MTYyNmM2NT4g
VGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAu
MiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCAzOTQuNjQ2IFRkCi9GMS4wIDEwLjUgVGYK
PDZmNjY2NjIwNzQ2ODY1MjA3MzY4NjU2YzY2MjAyODY1MmU2NzJlMjA3Mzc0NjQ2OTZmNWY2Mjc1
NjY2NjY1NzIyMDY5NmUyMDQ3NGU1NTczMjA2YzY5NjI3Mzc0NjQ2MzJiMmIyOTJlPiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgpCVAo0OC4yNCAzNjYuODY2IFRkCi9GMS4wIDEwLjUgVGYKWzw1NDY4Njk3MzIwNjk3
MzIwNzQ2ODY1MjA3NDc5NzA2OTYzNjE2YzIwNjE2ZTczNzc2NTcyMjA2NzY5NzY2NTZlMjA3NDZm
MjA3NDY4NjUyMDQ2PiA2OS44MjQyIDw0MT4gMjAuMDE5NSA8NTEyMDZmNjYyMDY4NmY3NzIwNzQ2
ZjIwNjQ2ZjIwNzQ2ODY5NzMyMDZmNmUyMDczNzQ2MTYzNmI+IDIwLjAxOTUgPDZmNzY2NTcyNjY2
YzZmNzcyMDYxNmU2NDIwNjU2YzczNjU3NzY4NjU3MjY1MmU+XSBUSgpFVAoKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0
OC4yNCAzMzkuMDg2IFRkCi9GMS4wIDEwLjUgVGYKPDU0Njg2OTczMjA3MzY5NzQ3NTYxNzQ2OTZm
NmUyMDY5NzMyMDZlNmY2ZTJkNmY3MDc0Njk2ZDYxNmMyMDYxNzMzYT4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNTYuODgwNSAzMTEuMzA2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDMxMS4zMDYgVGQKL0YxLjAgMTAuNSBUZgpbPDZlNmY2
ZTJkNzM3NDYxNmU2NDYxNzI2NDIwNjU3ODc0NjU2ZTczNjk2ZjZlNzMyMDYxNzI2NTIwNjk2ZTY4
NjU3Mj4gMjAuMDE5NSA8NjE2ZTc0NmM3OTIwNmU2ZjZlMmQ3MDZmNzI3NDYxNjI2YzY1Pl0gVEoK
RVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSAyODkuNTI2IFRkCi9GMS4wIDEwLjUgVGYK
PGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjAuMjI0NCBUdwoKQlQKNjYuMjQgMjg5LjUyNiBU
ZAovRjEuMCAxMC41IFRmCjw2MzZjNjE3MzczNjU3MzIwNjQ2NTcyNjk3NjY1NjQyMDY2NzI2ZjZk
MjA3Mzc0NjQzYTNhNzM3NDcyNjU2MTZkNjI3NTY2MjA2ZjcyMjA3Mzc0NjQzYTNhNjY2OTZjNjU2
Mjc1NjYyMDcwNzI2Zjc2Njk2NDY5NmU2NzIwNzQ2ODY1MjA3MzYxNmQ2NTIwNjM2ZjcyNjUyMDY2
NzU2ZTYzNzQ2OTZmNmU2MTZjNjk3NDc5MjA2MTcyNjUyMDZlNmY3ND4gVGoKRVQKCgowLjAgVHcK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgpCVAo2Ni4yNCAyNzMuNzQ2IFRkCi9GMS4wIDEwLjUgVGYKPDczNzQ2MTZlNjQ2MTcy
NjQ2OTczNjU2ND4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMjI5LjYzNCBUZAovRjIuMCAyMiBU
Zgo8NDI2NTc0NzQ2NTcyMjA1MzZmNmM3NTc0Njk2ZjZlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NO
CjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NO
CgpCVAo1Ni44ODA1IDIwMC40NDYgVGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNjYuMjQgMjAwLjQ0NiBUZAovRjEuMCAxMC41IFRmCjw0NTY5NzQ2ODY1NzIy
MDczNzQ2MTZlNjQ2MTcyNjQ2OTczNjUyMDc0Njg2NTIwNmU2ZjZlMmQ3Mzc0NjE2ZTY0NjE3MjY0
MjA2NTc4NzQ2NTZlNzM2OTZmNmU3Mz4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYuODgw
NSAxNzguNjY2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAu
MCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJU
CjY2LjI0IDE3OC42NjYgVGQKL0YxLjAgMTAuNSBUZgpbPDUwNzI2Zjc2Njk2NDY1MjA3Mzc0NjE2
ZTY0NjE3MjY0MjA2YzY5NjI3Mj4gMjAuMDE5NSA8NjE3Mjc5MjA2MzZjNjE3MzczNjU3Mz5dIFRK
CkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIg
MC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDEzOC44MjYgVGQKL0YyLjAgMTggVGYKPDRjNjk2ZTZiMjA2
MjY1NzQ3NzY1NjU2ZTIwNzI2NTcxNzU2OTcyNjU2ZDY1NmU3NDczMjA2NjZmNzIyMDQ2NDk0YzQ1
MmEyMDYxNmU2NDIwNmU2MTc0Njk3NjY1MjA2NjY5NmM2NT4gVGoKRVQKCjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDgu
MjQgMTE0LjM0NiBUZAovRjIuMCAxOCBUZgo8Njg2MTZlNjQ2YzY1NzM+IFRqCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CkJUCjQ4LjI0IDg2LjMyNiBUZAovRjEuMCAxMC41IFRmCjw1NDY4NjUyMDcyNjU3MTc1Njk3MjY1
NmQ2NTZlNzQ3MzIwNzM2ODZmNzcyMDc0Njg2MTc0MjA3NDY4NjUyMDQ2NDk0YzQ1MmEyMDYzNjE3
MzY1MjA2OTczMjA3NjY1NzI3OTIwNzM2OTZkNjk2YzYxNzIyMDc0NmYyMDc0Njg2NTIwNmU2MTc0
Njk3NjY1MjA2NjY5NmM2NTIwNjQ2NTczNjM3MjY5NzA3NDZmNzIyMDYzNjE3MzY1MmU+IFRqCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4y
IDAuMiBTQ04KCkJUCjQ4LjI0IDU4LjU0NiBUZAovRjEuMCAxMC41IFRmCjw0ZTZmNzQ2NTIwNzQ2
ODYxNzQyMDYxMjA3MzZmNmM3NTc0Njk2ZjZlMjA3NDZmMjA2ZjZlNjUyMDcwNzI2ZjYyNmM2NTZk
MjA2OTczMjA2ZTZmNzQyMDZlNjU2MzY1NzM3MzYxNzI2OTZjNzkyMDYxMjA3MzZmNmM3NTc0Njk2
ZjZlMjA3NDZmMjA3NDY4NjUyMDZmNzQ2ODY1NzIyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KcQowLjAgMC4wIDAuMCBzY24KMC4wIDAuMCAwLjAgU0NOCjEgdwowIEoK
MCBqCltdIDAgZAovU3RhbXAyIERvCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJU
CjQ5LjI0IDE0LjM4OCBUZAovRjEuMCA5IFRmCjwzMj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KUQpRCgplbmRzdHJlYW0KZW5kb2JqCjIwIDAgb2JqCjw8IC9UeXBlIC9Q
YWdlCi9QYXJlbnQgMyAwIFIKL01lZGlhQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0Nyb3BCb3gg
WzAgMCA1OTUuMjggODQxLjg5XQovQmxlZWRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovVHJpbUJv
eCBbMCAwIDU5NS4yOCA4NDEuODldCi9BcnRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQ29udGVu
dHMgMTkgMCBSCi9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1h
Z2VDIC9JbWFnZUldCi9Gb250IDw8IC9GMi4wIDE1IDAgUgovRjEuMCA4IDAgUgo+PgovWE9iamVj
dCA8PCAvU3RhbXAyIDkzIDAgUgo+Pgo+PgovQW5ub3RzIFsyMiAwIFIgMjMgMCBSXQo+PgplbmRv
YmoKMjEgMCBvYmoKWzIwIDAgUiAvWFlaIDAgODQxLjg5IG51bGxdCmVuZG9iagoyMiAwIG9iago8
PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBz
Oi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzI0MjM2Mjgvd2hhdHMtdGhlLWRpZmZlcmVu
Y2UtYmV0d2Vlbi1hLWZpbGUtZGVzY3JpcHRvci1hbmQtZmlsZS1wb2ludGVyKQo+PgovU3VidHlw
ZSAvTGluawovUmVjdCBbNDguMjQgNjY0LjY4IDUzMi43MTE2IDY3OC45Nl0KL1R5cGUgL0Fubm90
Cj4+CmVuZG9iagoyMyAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlv
bgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzI0MjM2
Mjgvd2hhdHMtdGhlLWRpZmZlcmVuY2UtYmV0d2Vlbi1hLWZpbGUtZGVzY3JpcHRvci1hbmQtZmls
ZS1wb2ludGVyKQo+PgovU3VidHlwZSAvTGluawovUmVjdCBbNDguMjQgNjQ4LjkgMTA0LjQ2NzUg
NjYzLjE4XQovVHlwZSAvQW5ub3QKPj4KZW5kb2JqCjI0IDAgb2JqClsyMCAwIFIgL1hZWiAwIDU1
OC44MSBudWxsXQplbmRvYmoKMjUgMCBvYmoKWzIwIDAgUiAvWFlaIDAgMjU3LjkzIG51bGxdCmVu
ZG9iagoyNiAwIG9iagpbMjAgMCBSIC9YWVogMCAxNjIuODUgbnVsbF0KZW5kb2JqCjI3IDAgb2Jq
Cjw8IC9MZW5ndGggOTYyMAo+PgpzdHJlYW0KcQovRGV2aWNlUkdCIGNzCjAuMiAwLjIgMC4yIHNj
bgovRGV2aWNlUkdCIENTCjAuMiAwLjIgMC4yIFNDTgoKMC4zMDkxIFR3CgpCVAo0OC4yNCA3OTMu
OTI2IFRkCi9GMS4wIDEwLjUgVGYKPDRmNmUyMDUwNmY3MzY5NzgyMDY5NzQyMDY5NzMyMDcwNmY3
MzczNjk2MjZjNjUyMDI4Nzc2OTc0NjgyMDZjNjk2ZDY5NzQ2MTc0Njk2ZjZlNzMyOTIwNzQ2ZjIw
NjM2ZjZlNzY2NTcyNzQyMDYxMjA0NjQ0MjA3NDZmMjA2MTIwNDY0OTRjNDUyYTIwNzU3MzY5NmU2
NzIwNjY2NDZmNzA2NTZlMjgyOTIwNjE2ZTY0MjA2MTIwNDY0OTRjNDUyYTIwNzQ2ZjIwNjE2ZT4g
VGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAu
MiBzY24KMC4yIDAuMiAwLjIgU0NOCgoxLjA3NTIgVHcKCkJUCjQ4LjI0IDc3OC4xNDYgVGQKL0Yx
LjAgMTAuNSBUZgo8NDY0NDIwNzU3MzY5NmU2NzIwNjY2OTZjNjU2ZTZmMjgyOTJlMjA0ZjZlMjA1
MDZmNzM2OTc4MjA3MDZjNjE3NDY2NmY3MjZkNzMyMDc0Njg2NTcyNjU2NjZmNzI2NTIwNjk3NDIw
NjM2MTZlMjA2MjY1MjA2MTcyNjc3NTY1NjQyMDc0Njg2MTc0MjA2MTIwNzM2ZjZjNzU3NDY5NmY2
ZTIwNzQ2ZjIwNmY2ZTY1MjA3MDcyNmY2MjZjNjU2ZDIwNjk3Mz4gVGoKRVQKCgowLjAgVHcKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgpCVAo0OC4yNCA3NjIuMzY2IFRkCi9GMS4wIDEwLjUgVGYKPDcwNmY3NDY1NmU3NDY5NjE2
YzZjNzkyMDYxMjA3MzZmNmM3NTc0Njk2ZjZlMjA3NDZmMjA3NDY4NjUyMDZmNzQ2ODY1NzIyZT4g
VGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAu
MiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNzIyLjUyNiBUZAovRjIuMCAxOCBUZgo8NTI2NTZjNjE3
NDY5NmY2ZTIwNzQ2ZjIwNzA3MjY1NzY2OTZmNzU3MzIwNzA3MjZmNzA2ZjczNjE2YzczPiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgoyLjIzNDQgVHcKCkJUCjQ4LjI0IDY5NC41MDYgVGQKL0YxLjAgMTAuNSBUZgo8
NTQ2ODZmNzU2NzY4MjA3NDY4Njk3MzIwNmQ3NTczNzQyMDYzNmY2ZDY1MjA3NTcwMjA2ZjY2NzQ2
NTZlMmUyMDQ5MjA2ODYxNzY2NTIwNmU2Zjc0MjA3MzY1NjU2ZTIwNjEyMDcyNjU2MzY1NmU3NDIw
NjM2ZjZlNjM3MjY1NzQ2NTIwNzA3MjZmNzA2ZjczNjE2YzJlMjA1NDY4NjUyMDZkNmY3Mzc0MjA3
MjY1NjM2NTZlNzQ+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNjc4LjcyNiBUZAov
RjEuMCAxMC41IFRmCjw2NDY5NzM2Mzc1NzM3MzY5NmY2ZTczMjA0OTIwNjM2MTZlMjA2NjY5NmU2
NDIwNjE3MjY1M2E+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjguMjk2MyBUdwoKQlQKNDguMjQgNjUwLjk0NiBU
ZAovRjEuMCAxMC41IFRmCjw1NDY4NjUyMDZmNmU2NTIwNmM2NTYxNjQ2OTZlNjcyMDc0NmYyMDc0
Njg2OTczMjA3MDcyNmY3MDZmNzM2MTZjM2EyMD4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBzY24KMC4yNTg4IDAuNTQ1
MSAwLjc5MjIgU0NOCgo4LjI5NjMgVHcKCkJUCjI2My40ODc1IDY1MC45NDYgVGQKL0YxLjAgMTAu
NSBUZgo8Njg3NDc0NzA3MzNhMmYyZjY3NzI2Zjc1NzA3MzJlNjc2ZjZmNjc2YzY1MmU2MzZmNmQy
ZjYxMmY2OTczNmY2MzcwNzAyZTZmNzI2NzJmNjY2ZjcyNzU2ZDJmMjMyMTc0NmY3MDY5NjMyZjcz
NzQ2NDJkPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAu
MjU4OCAwLjU0NTEgMC43OTIyIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBTQ04KCkJUCjQ4LjI0
IDYzNS4xNjYgVGQKL0YxLjAgMTAuNSBUZgo8NzA3MjZmNzA2ZjczNjE2YzczMmY1ODYzNTEzNDQ2
NWE0YTRiNDQ2MjRkPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIg
MC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA2MDcuMzg2IFRkCi9GMS4wIDEw
LjUgVGYKPDY2NzI2ZjZkMjAzMjMwMzEzNDNhPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAw
LjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBzY24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIg
U0NOCgpCVAo0OC4yNCA1NzkuNjA2IFRkCi9GMS4wIDEwLjUgVGYKPDY4NzQ3NDcwNzMzYTJmMmY2
NzcyNmY3NTcwNzMyZTY3NmY2ZjY3NmM2NTJlNjM2ZjZkMmY2MTJmNjk3MzZmNjM3MDcwMmU2Zjcy
NjcyZjY2NmY3Mjc1NmQyZjNmNjY3MjZmNmQ2NzcyNmY3NTcwNzMyMzIxNzM2NTYxNzI2MzY4Njk2
ZTJmNzM3NDY0MmQ3MDcyNmY3MDZmNzM2MTZjNzMyZjcwNmY3MzY5NzgyZjczNzQ2NDJkPiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBz
Y24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgU0NOCgoxNC41OTA5IFR3CgpCVAo0OC4yNCA1NjMuODI2
IFRkCi9GMS4wIDEwLjUgVGYKWzw3MDcyNmY3MDZmNzM2MTZjNzMyZjUxMzQ1MjY0NDY1MzVhNjc2
NzUzNDUyZjUyNjM1Mj4gMjkuNzg1MiA8NTc+IDYwLjA1ODYgPDZmMzE1MzM3NjQ0YjczNGE+XSBU
SgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCjE0LjU5MDkgVHcKCkJUCjI0Ni4xNzcxIDU2My44MjYgVGQK
L0YxLjAgMTAuNSBUZgo8MjA+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4w
IDAuMCBzY24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIFND
TgoKMTQuNTkwOSBUdwoKQlQKMjYzLjQ4NzUgNTYzLjgyNiBUZAovRjEuMCAxMC41IFRmCjw2ODc0
NzQ3MDczM2EyZjJmNjc3MjZmNzU3MDczMmU2NzZmNmY2NzZjNjUyZTYzNmY2ZDJmNjEyZjY5NzM2
ZjYzNzA3MDJlNmY3MjY3MmY2NjZmNzI3NTZkMmYyMzIxNzQ2ZjcwNjk2MzJmNzM3NDY0MmQ+IFRq
CkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yNTg4IDAuNTQ1
MSAwLjc5MjIgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIFNDTgoKQlQKNDguMjQgNTQ4LjA0NiBU
ZAovRjEuMCAxMC41IFRmCjw2NDY5NzM2Mzc1NzM3MzY5NmY2ZTJmNmQ2MTYzNDQ3NjY4NDY0NDcy
NmE1NT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNTIwLjI2NiBUZAovRjEuMCAxMC41IFRmCjw2
NjcyNmY2ZDIwMzIzMDMxMzMzYT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIFNDTgoKQlQK
NDguMjQgNDkyLjQ4NiBUZAovRjEuMCAxMC41IFRmCjw2ODc0NzQ3MDczM2EyZjJmNjc3MjZmNzU3
MDczMmU2NzZmNmY2NzZjNjUyZTYzNmY2ZDJmNjEyZjY5NzM2ZjYzNzA3MDJlNmY3MjY3MmY2NjZm
NzI3NTZkMmYzZjY2NzI2ZjZkNjc3MjZmNzU3MDczMjMyMTczNjU2MTcyNjM2ODY5NmUyZjczNzQ2
NDJkNzA3MjZmNzA2ZjczNjE2YzczMmY2ZTYxNzQ2OTc2NjU1ZjY4NjE2ZTY0NmM2NTJmPiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBz
Y24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgU0NOCgpCVAo0OC4yNCA0NzYuNzA2IFRkCi9GMS4wIDEw
LjUgVGYKPDczNzQ2NDJkNzA3MjZmNzA2ZjczNjE2YzczMmY2ZjQzNDU0NTcyNTE2MjQ5Mzk3MzRk
MmY0Zjc5MzUzNzU0NGM3YTQzNzA2YTM0NGE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAu
MCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDQzMi41
OTQgVGQKL0YyLjAgMjIgVGYKPDUwNzI2ZjcwNmY3MzYxNmM+IFRqCkVUCgowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBT
Q04KCkJUCjU2Ljg4MDUgNDAzLjQwNiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgpCVAo2Ni4yNCA0MDMuNDA2IFRkCi9GMS4wIDEwLjUgVGYKPDQxMjA2ZTY1Nzcy
MDZmNzA2MTcxNzU2NTIwNzQ3OTcwNjUyMDcyNjU3MDcyNjU3MzY1NmU3NDY5NmU2NzIwNjEyMDZl
NjE3NDY5NzY2NTIwNjY2OTZjNjUyMDY0NjU3MzYzNzI2OTcwNzQ2ZjcyPiBUagpFVAoKMC4wIDAu
MCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgpCVAo1Ni44ODA1IDM4MS42MjYgVGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2Nu
CjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgMzgxLjYyNiBUZAovRjEuMCAxMC41IFRmCjw2MTIw
NzM3NDY0Njk2ZjVmNjY2OTZjNjU2Mjc1NjYyMDY2NmY3MjIwNzM3OTZlNjM2ODcyNmY2ZTY5NzM2
OTZlNjcyMDQzMmIyYjIwNzM3NDcyNjU2MTZkMjA0OTRmMjA3NzY5NzQ2ODIwNDMyMDczNzQ2NDY5
NmYyMDYyNjE3MzY1NjQyMDZmNmUyMDQ2NDk0YzQ1MmE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CkJUCjU2Ljg4MDUgMzU5Ljg0NiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgpCVAo2Ni4yNCAzNTkuODQ2IFRkCi9GMS4wIDEwLjUgVGYKPDYxMjA2ZTYxNzQ2OTc2
NjU1ZjY2Njk2YzY1NjI3NTY2MjA2NTc4NzA2ZjczNjk2ZTY3MjA2MTIwNmU2MTc0Njk3NjY1MjA2
NjY5NmM2NTIwNjQ2NTczNjM3MjY5NzA3NDZmNzI+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4w
IDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJU
CjU2Ljg4MDUgMzM4LjA2NiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4w
IFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgpCVAo2Ni4yNCAzMzguMDY2IFRkCi9GMS4wIDEwLjUgVGYKWzw2MTY0NjQyMDYxMjA2ZTY1
NzcyMDcwNjE3Mj4gMjAuMDE5NSA8NjE2ZDY1NzQ2NTcyMjA3NDZmMjA3NDY4NjUyMDczNzQ2NDNh
M2E2MjYxNzM2OTYzNWY2NjczNzQ3MjY1NjE2ZDIwNzQ2NTZkNzA2YzYxNzQ2NTIwNjQ2NTYzNmM2
MTcyNjk2ZTY3MjA3NDY4NjUyMDc0Nzk3MDY1MjA2ZjY2MjA2NjY5NmM2NTYyNzU2NjIwNzU3MzY1
NjQ+XSBUSgpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIg
MC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDMxNi4yODYgVGQKL0YxLjAg
MTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAg
VGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgMzE2LjI4NiBUZAov
RjEuMCAxMC41IFRmCls8NzI2NTY0NjU2NjY5NmU2NTIwNzM3NDY0M2EzYTY2NzM3NDcyNjU2MTZk
MjA2MTczMjA3NDc5NzA2NTY0NjU2NjIwNzM3NDY0M2EzYTYyNjE3MzY5NjM1ZjY2NzM3NDcyNjU2
MTZkM2M3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyYzYzNjg2MTcyMmM2MzY4NjE3MjVmNzQ3Mj4g
MjAuMDE5NSA8NjE2OTc0NzMzZT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAg
c2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUg
Mjk0LjUwNiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAg
MC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2
Ni4yNCAyOTQuNTA2IFRkCi9GMS4wIDEwLjUgVGYKWzw2MTY0NjQyMDczNzQ2NDY5NmY1ZjY2NzM3
NDcyNjU2MTZkMjA2MTczMjA3NDc5NzA2NTY0NjU2NjIwNzM3NDY0M2EzYTYyNjE3MzY5NjM1ZjY2
NzM3NDcyNjU2MTZkM2M3Mzc0NjQ2OTZmNWY2NjY5NmM2NTYyNzU2NjJjNjM2ODYxNzIyYzYzNjg2
MTcyNWY3NDcyPiAyMC4wMTk1IDw2MTY5NzQ3MzNlPl0gVEoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
QlQKNTYuODgwNSAyNzIuNzI2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAw
LjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjY2LjI0IDI3Mi43MjYgVGQKL0YxLjAgMTAuNSBUZgpbPDYxNjQ2NDIwNmU2MTc0
Njk3NjY1NWY2NjczNzQ3MjY1NjE2ZDIwNjE3MzIwNzQ3OTcwNjU2NDY1NjYyMDczNzQ2NDNhM2E2
MjYxNzM2OTYzNWY2NjczNzQ3MjY1NjE2ZDNjNmU2MTc0Njk3NjY1NWY2NjY5NmM2NTYyNzU2NjJj
NjM2ODYxNzIyYzYzNjg2MTcyNWY3NDcyPiAyMC4wMTk1IDw2MTY5NzQ3MzNlPl0gVEoKRVQKCjAu
MCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAu
MiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSAyNTAuOTQ2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBU
agpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCjQuNzg2NiBUdwoKQlQKNjYuMjQgMjUwLjk0NiBUZAovRjEu
MCAxMC41IFRmCls8NjE2NDY0MjA2MTIwNmU2NTc3MjA2MTYyNzM3NDcyPiAyMC4wMTk1IDw2MTYz
NzQyMDYyNjE3MzY1MjA2MzZjNjE3MzczMjAyMjY2NzM3NDcyNjU2MTZkNWY2OTZlNzQ2NTcyNjY2
MTYzNjUyMjIwMjg2MjY1NzQ3NDY1NzIyMDZlNjE2ZDY1MjA3MjY1NzE3NTY5NzI2NTY0MjkyMDc0
Njg2MTc0MjA2NTc4NzQ2NTZlNjQ3Mz5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC42ODczIFR3
CgpCVAo2Ni4yNCAyMzUuMTY2IFRkCi9GMS4wIDEwLjUgVGYKWzw3Mzc0NjQzYTNhNjI2MTczNjk2
MzVmNjk2ZjczNzQ3MjY1NjE2ZDIwNzc2OTc0NjgyMDZmNzA2NTZlMjgyOTJjMjA2OTczNWY2Zjcw
NjU2ZTI4MjkyMDI2MjA2MzZjNmY3MzY1MjgyOTIwNjY3NTZlNjM3NDY5NmY2ZTczMjA2MTczMjA3
MDcyNmY3NjY5NjQ2NTY0MjA2Mj4gMjAuMDE5NSA8NzkyMDczNzQ2NDNhM2E2NjczNzQ3MjY1NjE2
ZDIwNjE2ZTY0MjA2OTczPl0gVEoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAg
MC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCAyMTkuMzg2
IFRkCi9GMS4wIDEwLjUgVGYKWzw2OTZkNzA2YzY1NmQ2NTZlNzQ2NTY0MjA2Mj4gMjAuMDE5NSA8
NzkyMDczNzQ2NDNhM2E2MjYxNzM2OTYzNWY2NjczNzQ3MjY1NjE2ZD5dIFRKCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CjMuNTE2MSBUdwoKQlQKNDguMjQgMTkxLjYwNiBUZAovRjEuMCAxMC41IFRmCjw0OTczMjA2OTcz
MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2MTc0Njk2ZjZlMjA2NDY1NjY2OTZlNjU2NDIwNzc2ODY1NzQ2
ODY1NzIyMDczNzQ2NDNhM2E3Mzc0NjQ2OTZmNWY2NjY5NmM2NTYyNzU2NjJjMjA3Mzc0NjQzYTNh
NmU2MTc0Njk3NjY1NWY2NjY5NmM2NTYyNzU2NjIwNjE2ZTY0MjA3Mzc0NjQzYTNhNjY2OTZjNjU2
Mjc1NjYyMDYxNzI2NT4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgozLjYzNzcgVHcKCkJUCjQ4LjI0
IDE3NS44MjYgVGQKL0YxLjAgMTAuNSBUZgo8NjQ2OTY2NjY2NTcyNjU2ZTc0MjA3NDc5NzA2NTcz
MmUyMDUzNmY2ZDY1MjA2MzZmNzU2YzY0MjA2MjY1MjA3NDc5NzA2NTY0NjU2NjczMjA2ZjY2MjA2
Zjc0Njg2NTcyNzMyMDcwNzI2Zjc2Njk2NDY1NjQyMDc0Njg2MTc0MjA3NDY4NjUyMDYxNjQ2NDY5
NzQ2OTZmNmU2MTZjMjA2OTZlNzQ2NTcyNjY2MTYzNjU3MzIwNmY2Nj4gVGoKRVQKCgowLjAgVHcK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgpCVAo0OC4yNCAxNjAuMDQ2IFRkCi9GMS4wIDEwLjUgVGYKPDczNzQ2NDY5NmY1ZjY2
Njk2YzY1NjI3NTY2MjA2MTZlNjQyMDZlNjE3NDY5NzY2NTVmNjY2OTZjNjU2Mjc1NjYyMDYxNzI2
NTIwNzA3MjZmNzY2OTY0NjU2NDJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCAxMjAuMjA2IFRk
Ci9GMi4wIDE4IFRmCjw3Mzc0NjQzYTNhNmU2MTc0Njk3NjY1NWY2NjY5NmM2NTVmNjQ2NTczNjM3
MjY5NzA3NDZmNzI+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDkyLjE4NiBUZAovRjEuMCAxMC41
IFRmCjw0OTc0MjA2OTczMjA3MDcyNmY3MDZmNzM2NTY0MjA3NDZmMjA2MTY0NjQyMDYxNmUyMDZm
NzA2MTcxNzU2NTIwNzQ3OTcwNjUyMDcyNjU3MDcyNjU3MzY1NmU3NDY5NmU2NzIwNjEyMDZlNjE3
NDY5NzY2NTVmNjY2OTZjNjU1ZjY0NjU3MzYzNzI2OTcwNzQ2ZjcyMmU+IFRqCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CjAuNjg1OSBUdwoKQlQKNDguMjQgNjQuNDA2IFRkCi9GMS4wIDEwLjUgVGYKPDQxNmUyMDY5NmQ3
MDZjNjU2ZDY1NmU3NDYxNzQ2OTZmNmUyMDY5NzMyMDY2NzI2NTY1MjA3NDZmMjA2MTY0NjQyMDY5
NzQ3MzIwNmY3NzZlMjA2NjY5NjU2YzY0NzMyMDc0NmYyMDc0Njg2OTczMmUyMDQxMjA2Njc1NzQ3
NTcyNjUyMDc2NjU3MjczNjk2ZjZlMjA2ZjY2MjA3NDY4NjUyMDQzMmIyYjIwNzM3NDYxNmU2NDYx
NzI2NDIwNmQ2OTY3Njg3ND4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAg
MC4wIHNjbgpxCjAuMCAwLjAgMC4wIHNjbgowLjAgMC4wIDAuMCBTQ04KMSB3CjAgSgowIGoKW10g
MCBkCi9TdGFtcDEgRG8KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTQxLjAw
OSAxNC4zODggVGQKL0YxLjAgOSBUZgo8MzM+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAu
MCAwLjAgc2NuClEKUQoKZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iago8PCAvVHlwZSAvUGFnZQov
UGFyZW50IDMgMCBSCi9NZWRpYUJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9Dcm9wQm94IFswIDAg
NTk1LjI4IDg0MS44OV0KL0JsZWVkQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL1RyaW1Cb3ggWzAg
MCA1OTUuMjggODQxLjg5XQovQXJ0Qm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0NvbnRlbnRzIDI3
IDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAv
SW1hZ2VJXQovRm9udCA8PCAvRjEuMCA4IDAgUgovRjIuMCAxNSAwIFIKPj4KL1hPYmplY3QgPDwg
L1N0YW1wMSA5MiAwIFIKPj4KPj4KL0Fubm90cyBbMzAgMCBSIDMxIDAgUiAzMiAwIFIgMzMgMCBS
IDM0IDAgUiAzNSAwIFIgMzYgMCBSIDM3IDAgUl0KPj4KZW5kb2JqCjI5IDAgb2JqClsyOCAwIFIg
L1hZWiAwIDc0Ni41NSBudWxsXQplbmRvYmoKMzAgMCBvYmoKPDwgL0JvcmRlciBbMCAwIDBdCi9B
IDw8IC9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwczovL2dyb3Vwcy5nb29nbGUuY29t
L2EvaXNvY3BwLm9yZy9mb3J1bS8jIXRvcGljL3N0ZC1wcm9wb3NhbHMvWGNRNEZaSktEYk0pCj4+
Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNjMuNDg3NSA2NDcuODggNTQ3LjA0IDY2Mi4xNl0KL1R5
cGUgL0Fubm90Cj4+CmVuZG9iagozMSAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5
cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29j
cHAub3JnL2ZvcnVtLyMhdG9waWMvc3RkLXByb3Bvc2Fscy9YY1E0RlpKS0RiTSkKPj4KL1N1YnR5
cGUgL0xpbmsKL1JlY3QgWzQ4LjI0IDYzMi4xIDE3Mi45Njk1IDY0Ni4zOF0KL1R5cGUgL0Fubm90
Cj4+CmVuZG9iagozMiAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlv
bgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29jcHAub3JnL2Zv
cnVtLz9mcm9tZ3JvdXBzIyFzZWFyY2hpbi9zdGQtcHJvcG9zYWxzL3Bvc2l4L3N0ZC1wcm9wb3Nh
bHMvUTRSZEZTWmdnU0UvUmNSV28xUzdkS3NKKQo+PgovU3VidHlwZSAvTGluawovUmVjdCBbNDgu
MjQgNTc2LjU0IDUxNC4xMzU1IDU5MC44Ml0KL1R5cGUgL0Fubm90Cj4+CmVuZG9iagozMyAwIG9i
ago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0
dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29jcHAub3JnL2ZvcnVtLz9mcm9tZ3JvdXBzIyFz
ZWFyY2hpbi9zdGQtcHJvcG9zYWxzL3Bvc2l4L3N0ZC1wcm9wb3NhbHMvUTRSZEZTWmdnU0UvUmNS
V28xUzdkS3NKKQo+PgovU3VidHlwZSAvTGluawovUmVjdCBbNDguMjQgNTYwLjc2IDI0Ni4xNzcx
IDU3NS4wNF0KL1R5cGUgL0Fubm90Cj4+CmVuZG9iagozNCAwIG9iago8PCAvQm9yZGVyIFswIDAg
MF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vZ3JvdXBzLmdvb2ds
ZS5jb20vYS9pc29jcHAub3JnL2ZvcnVtLyMhdG9waWMvc3RkLWRpc2N1c3Npb24vbWFjRHZoRkRy
alUpCj4+Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNjMuNDg3NSA1NjAuNzYgNTQ3LjA0IDU3NS4w
NF0KL1R5cGUgL0Fubm90Cj4+CmVuZG9iagozNSAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0Eg
PDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20v
YS9pc29jcHAub3JnL2ZvcnVtLyMhdG9waWMvc3RkLWRpc2N1c3Npb24vbWFjRHZoRkRyalUpCj4+
Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0OC4yNCA1NDQuOTggMTc0LjAzIDU1OS4yNl0KL1R5cGUg
L0Fubm90Cj4+CmVuZG9iagozNiAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUg
L0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29jcHAu
b3JnL2ZvcnVtLz9mcm9tZ3JvdXBzIyFzZWFyY2hpbi9zdGQtcHJvcG9zYWxzL25hdGl2ZV9oYW5k
bGUvc3RkLXByb3Bvc2Fscy9vQ0VFclFiSTlzTS9PeTU3VEx6Q3BqNEopCj4+Ci9TdWJ0eXBlIC9M
aW5rCi9SZWN0IFs0OC4yNCA0ODkuNDIgNTQwLjIyOCA1MDMuN10KL1R5cGUgL0Fubm90Cj4+CmVu
ZG9iagozNyAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAv
VVJJCi9VUkkgKGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29jcHAub3JnL2ZvcnVtLz9m
cm9tZ3JvdXBzIyFzZWFyY2hpbi9zdGQtcHJvcG9zYWxzL25hdGl2ZV9oYW5kbGUvc3RkLXByb3Bv
c2Fscy9vQ0VFclFiSTlzTS9PeTU3VEx6Q3BqNEopCj4+Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0
OC4yNCA0NzMuNjQgMjU5LjQyNjUgNDg3LjkyXQovVHlwZSAvQW5ub3QKPj4KZW5kb2JqCjM4IDAg
b2JqClsyOCAwIFIgL1hZWiAwIDQ2MC44OSBudWxsXQplbmRvYmoKMzkgMCBvYmoKWzI4IDAgUiAv
WFlaIDAgMTQ0LjIzIG51bGxdCmVuZG9iago0MCAwIG9iago8PCAvTGVuZ3RoIDk5MTkKPj4Kc3Ry
ZWFtCnEKL0RldmljZVJHQiBjcwowLjIgMC4yIDAuMiBzY24KL0RldmljZVJHQiBDUwowLjIgMC4y
IDAuMiBTQ04KCjcuNTEzOCBUdwoKQlQKNDguMjQgNzk0LjY3NiBUZAovRjEuMCAxMC41IFRmCls8
NjM2ZjZlNzM2OTY0NjU3MjIwNmQ2MTZiNjk2ZTY3MjA3NDY4Njk3MzIwNmM2NTczNzMyMDZmNzA2
MTcxNzU2NTJlMjA0Nj4gNDAuMDM5MSA8NmY3MjIwNjE2ZTIwNjU3ODYxNmQ3MDZjNjUyMDZmNjYy
MDc3Njg2MTc0MjA2ZDY5Njc2ODc0MjA2MjY1MjA2OTZlNjM2Yzc1NjQ2NTY0MjA3MzY1NjU+XSBU
SgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCjAuODYyNyBUdwoKQlQKNDguMjQgNzc4Ljg5NiBUZAovRjEu
MCAxMC41IFRmCls8Njk2ZTYzNmM3NTY0NjUyZjYxNjY2OTZmMmY3NjMyMmUzMDJmNmU2MTc0Njk3
NjY1NWY2ODYxNmU2NDZjNjU1Zjc0Nzk3MDY1MmU2ODcwNzAyMDY5NmUyMDc0Njg2NTIwNDE0NjQ5
NGYyMDZjNjk2MjcyPiAyMC4wMTk1IDw2MTcyNzkyMDcwNzI2ZjcwNmY3MzY1NjQyMDY2NmY3MjIw
NDI2ZjZmNzM3NDIwNjI+IDIwLjAxOTUgPDc5MjA0ZTY5NjE2YzZjMjA0NDZmNzU2NzZjNjE3MzIw
MmQ+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDc2My4xMTYgVGQKL0YxLjAgMTAu
NSBUZgo8Njc2OTc0M2EyZjJmNjc2OTc0Njg3NTYyMmU2MzZmNmQyZjZlNjU2NDMxMzQyZjYyNmY2
ZjczNzQyZTYxNjY2OTZmMmU2NzY5NzQ+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAw
LjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDczNS4zMzYg
VGQKL0YxLjAgMTAuNSBUZgo8NTQ2ODY5NzMyMDcwNzI2ZjcwNmY3MzYxNmMyMDZkNjE2ZTY0NjE3
NDY1NzMyMDZmNmU2Yzc5MjA3NDY4NjUyMDZkNjk2ZTY5NmQ3NTZkMjA3NDY4NjE3NDIwNjk3MzIw
NzI2NTcxNzU2OTcyNjU2NDIwNzQ2ZjIwNjk2ZDcwNmM2NTZkNjU2ZTc0MjA2MTIwNmU2MTc0Njk3
NjY1NWY2NjY5NmM2NTYyNzU2NjJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA3MDcuNTU2IFRk
Ci9GMS4wIDEwLjUgVGYKPDU0Njg2NTIwNmY3MjY5Njc2OTZlNjE2YzIwNzM3NTY3Njc2NTczNzQ2
OTZmNmUyMDc3NjE3MzNhPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgpx
CjAuOTYwOCAwLjk2MDggMC45NjA4IHNjbgo1Mi4yNCA2OTEuNzQgbQo1NDMuMDQgNjkxLjc0IGwK
NTQ1LjI0OTEgNjkxLjc0IDU0Ny4wNCA2ODkuOTQ5MSA1NDcuMDQgNjg3Ljc0IGMKNTQ3LjA0IDU3
MC41NiBsCjU0Ny4wNCA1NjguMzUwOSA1NDUuMjQ5MSA1NjYuNTYgNTQzLjA0IDU2Ni41NiBjCjUy
LjI0IDU2Ni41NiBsCjUwLjAzMDkgNTY2LjU2IDQ4LjI0IDU2OC4zNTA5IDQ4LjI0IDU3MC41NiBj
CjQ4LjI0IDY4Ny43NCBsCjQ4LjI0IDY4OS45NDkxIDUwLjAzMDkgNjkxLjc0IDUyLjI0IDY5MS43
NCBjCmgKZgowLjggMC44IDAuOCBTQ04KMC43NSB3CjUyLjI0IDY5MS43NCBtCjU0My4wNCA2OTEu
NzQgbAo1NDUuMjQ5MSA2OTEuNzQgNTQ3LjA0IDY4OS45NDkxIDU0Ny4wNCA2ODcuNzQgYwo1NDcu
MDQgNTcwLjU2IGwKNTQ3LjA0IDU2OC4zNTA5IDU0NS4yNDkxIDU2Ni41NiA1NDMuMDQgNTY2LjU2
IGMKNTIuMjQgNTY2LjU2IGwKNTAuMDMwOSA1NjYuNTYgNDguMjQgNTY4LjM1MDkgNDguMjQgNTcw
LjU2IGMKNDguMjQgNjg3Ljc0IGwKNDguMjQgNjg5Ljk0OTEgNTAuMDMwOSA2OTEuNzQgNTIuMjQg
NjkxLjc0IGMKaApTClEKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQg
NjY4LjkxNSBUZAovRjMuMCAxMSBUZgo8NzM3NDcyNzU2Mzc0MjA3Mzc0NjQzYTNhNmU2MTc0Njk3
NjY1NWY2NjY5NmM2NTVmNjQ2NTczNjM3MjY5NzA3NDZmNzI+IFRqCkVUCgowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5
LjI0IDY1NC4xNzUgVGQKL0YzLjAgMTEgVGYKPDdiPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAu
MCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1OS4yNCA2
MzkuNDM1IFRkCi9GMy4wIDExIFRmCjwyMzY5NjY2NDY1NjYyMDVmNTA0ZjUzNDk1ODVmNDM1ZjUz
NGY1NTUyNDM0NT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgNjI0LjY5NSBUZAovRjMuMCAxMSBU
Zgo8Y2EyMDIwMmYyZjIwNzI2NTc0NzU3MjZlMjA3NDY4NjUyMDc1NmU2NDY1NzI2Yzc5Njk2ZTY3
MjA0NjQ0PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAu
MiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1OS4yNCA2MDkuOTU1IFRkCi9GMy4wIDExIFRmCjxj
YTIwMjA2OTZlNzQyMDY2Njk2YzY1NmU2ZjI4MjkyMDYzNmY2ZTczNzQzYj4gVGoKRVQKCjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKQlQKNTkuMjQgNTk1LjIxNSBUZAovRjMuMCAxMSBUZgo8MjM2NTZlNjQ2OTY2PiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgpCVAo1OS4yNCA1ODAuNDc1IFRkCi9GMy4wIDExIFRmCjw3ZDNiPiBUagpFVAoKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgpCVAo0OC4yNCA1NDIuNTk2IFRkCi9GMS4wIDEwLjUgVGYKPDU0Njg2NTIwNTA0ZjUzNDk1
ODIwNjQ2NTY2Njk2ZTY5NzQ2OTZmNmUyMDY5NzMyMDcyNjU3MTc1Njk3MjY1NjQyMDc0NmYyMDYx
NmM2YzZmNzcyMDcwNmY3Mjc0NjE2MjZjNjUyMDYxNjM2MzY1NzM3MzIwNzQ2ZjIwNzQ2ODY1MjA0
NjQ0MmMyMDY2NmY3MjIwNjU3ODYxNmQ3MDZjNjUyMDc0NmYyMDc1NzM2NTIwNjY2MzZlNzQ2YzI4
MjkyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKMS44MDUxIFR3CgpCVAo0OC4yNCA1MTQuODE2IFRkCi9GMS4w
IDEwLjUgVGYKPDQxMjA3MDZmNzQ2NTZlNzQ2OTYxNmM2Yzc5MjA2NjYxNzQ2MTZjMjA2NjZjNjE3
NzIwNzc2OTc0NjgyMDc0Njg2OTczMjA2NDY1NzM2OTY3NmUyMDY5NzMyMDc0Njg2MTc0MjA2OTc0
MjA2MTczNzM3NTZkNjU3MzIwNzQ2ODYxNzQyMDYxMjA2ZTYxNzQ2OTc2NjU1ZjY2Njk2YzY1NWY2
NDY1NzM2MzcyNjk3MDc0NmY3MjIwNmY2ZTIwNTA2ZjczNjk3OD4gVGoKRVQKCgowLjAgVHcKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgowLjE1NTIgVHcKCkJUCjQ4LjI0IDQ5OS4wMzYgVGQKL0YxLjAgMTAuNSBUZgpbPDZkNzU3
Mzc0MjA2MjY1MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2NTY0MjA2OTZlMjA3NDY1NzI2ZDczMjA2ZjY2
MjA2MTZlMjA0NjQ0MjAyODZmNzIyMDczNmY2ZDY1NzQ2ODY5NmU2NzIwNzQ3Mj4gMjAuMDE5NSA8
NjE2ZTczNmM2MTc0NjE2MjZjNjUyMDc0NmYyMDZmNmU2NTI5MmUyMDQzNmY2ZTYzNjU2OTc2NjE2
MjZjNzkyMDc0Njg2NTcyNjUyMDYzNmY3NTZjNjQ+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAu
MCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjAu
NTMwMSBUdwoKQlQKNDguMjQgNDgzLjI1NiBUZAovRjEuMCAxMC41IFRmCjw2MjY1MjA1MDZmNzM2
OTc4MjA2MzZmNmQ3MDZjNjk2MTZlNzQyMDcwNmM2MTc0NjY2ZjcyNmQ3MzIwNmY2ZTIwNzc2ODY5
NjM2ODIwNjEyMDZlNjE3NDY5NzY2NTVmNjY2OTZjNjU2Mjc1NjYyMDY5NzMyMDZlNmY3NDIwNjEy
MDcwNmY3MzY5Nzg1ZjY2Njk2YzY1NjI3NTY2MjA2Mjc1NzQyMDczNmY2ZDY1NzQ2ODY5NmU2NzIw
NmM2Zjc3NjU3MjJkPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAg
c2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjAuMDcwMSBUdwoKQlQKNDguMjQg
NDY3LjQ3NiBUZAovRjEuMCAxMC41IFRmCls8NmM2NTc2NjU2YzJlMjA1NDY4Njk3MzIwNmQ2OTY3
Njg3NDIwNmY2MzYzNzU3MjJjMjA2NjZmNzIyMDY1Nzg2MTZkNzA2YzY1MmMyMDZmNmUyMDYxNmUy
MDRmNTMyMDcwNzI2Zjc2Njk2NDY5NmU2NzIwNjEyMDUwNmY3MzY5NzgyMDY1NmQ3NTZjNjE3NDY5
NmY2ZTIwNmM2MT4gMjAuMDE5NSA8Nzk2NTcyMjAyODczNzU2MzY4MjA2MTczMjA3NzY5NmU2NDZm
Nzc3MzI5MmU+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjEuNDcyMyBUdwoKQlQKNDguMjQgNDUx
LjY5NiBUZAovRjEuMCAxMC41IFRmCjw1Mzc1NjM2ODIwNjEyMDczNzk3Mzc0NjU2ZDIwNzc2Zjc1
NmM2NDIwNjg2MTc2NjUyMDc0NmYyMDczNzU3MDcwNmM3OTIwNjEyMDcwNmY3MzY5Nzg1ZjY2Njk2
YzY1NjI3NTY2MjA3NDZmMjA2ZDY1NjU3NDIwNzQ2ODY1MjA2ZjcyNjk2NzY5NmU2MTZjMjA3NTcz
NjUyMDYzNjE3MzY1MjA3NDY4NjE3NDIwNjk3MzIwNjQ2OTczNzQ2OTZlNjM3ND4gVGoKRVQKCgow
LjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4y
IDAuMiAwLjIgU0NOCgowLjgzMjggVHcKCkJUCjQ4LjI0IDQzNS45MTYgVGQKL0YxLjAgMTAuNSBU
Zgo8NjY3MjZmNmQyMDc0Njg2NTIwNmU2MTc0Njk3NjY1NWY2NjY5NmM2NTYyNzU2NjIwNzA3MjZm
NzA2ZjczNjU2NDJlMjA1NDY4NjUyMDY5NmQ3MDZjNjU2ZDY1NmU3NDYxNzQ2OTZmNmUyMDczNzU3
Mjc2NjU3OTIwNjQ2ZjZlNjUyMDczNmYyMDY2NjE3MjIwNjg2MTczMjA2ZTZmNzQyMDY2NmY3NTZl
NjQyMDZmNmU2NTIwNjI3NTc0MjA0OT4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAu
MCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA0
MjAuMTM2IFRkCi9GMS4wIDEwLjUgVGYKPDYyNjU2YzY5NjU3NjY1MjA2OTc0MjA2ZDc1NzM3NDIw
NjI2NTIwNjE2YzZjNmY3NzY1NjQyMDY2NmY3MjJlMjA1NDY4NjU3MjY1NjY2ZjcyNjUyMDQ5MjA3
MDcyNmY3MDZmNzM2NTNhPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgpx
CjAuOTYwOCAwLjk2MDggMC45NjA4IHNjbgo1Mi4yNCA0MDQuMzIgbQo1NDMuMDQgNDA0LjMyIGwK
NTQ1LjI0OTEgNDA0LjMyIDU0Ny4wNCA0MDIuNTI5MSA1NDcuMDQgNDAwLjMyIGMKNTQ3LjA0IDI1
My42NiBsCjU0Ny4wNCAyNTEuNDUwOSA1NDUuMjQ5MSAyNDkuNjYgNTQzLjA0IDI0OS42NiBjCjUy
LjI0IDI0OS42NiBsCjUwLjAzMDkgMjQ5LjY2IDQ4LjI0IDI1MS40NTA5IDQ4LjI0IDI1My42NiBj
CjQ4LjI0IDQwMC4zMiBsCjQ4LjI0IDQwMi41MjkxIDUwLjAzMDkgNDA0LjMyIDUyLjI0IDQwNC4z
MiBjCmgKZgowLjggMC44IDAuOCBTQ04KMC43NSB3CjUyLjI0IDQwNC4zMiBtCjU0My4wNCA0MDQu
MzIgbAo1NDUuMjQ5MSA0MDQuMzIgNTQ3LjA0IDQwMi41MjkxIDU0Ny4wNCA0MDAuMzIgYwo1NDcu
MDQgMjUzLjY2IGwKNTQ3LjA0IDI1MS40NTA5IDU0NS4yNDkxIDI0OS42NiA1NDMuMDQgMjQ5LjY2
IGMKNTIuMjQgMjQ5LjY2IGwKNTAuMDMwOSAyNDkuNjYgNDguMjQgMjUxLjQ1MDkgNDguMjQgMjUz
LjY2IGMKNDguMjQgNDAwLjMyIGwKNDguMjQgNDAyLjUyOTEgNTAuMDMwOSA0MDQuMzIgNTIuMjQg
NDA0LjMyIGMKaApTClEKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQg
MzgxLjQ5NSBUZAovRjMuMCAxMSBUZgo8MjM2OTY2NjQ2NTY2MjA1ZjUwNGY1MzQ5NTg1ZjQzNWY1
MzRmNTU1MjQzNDU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0IDM2Ni43NTUgVGQKL0YzLjAgMTEg
VGYKPDczNzQ3Mjc1NjM3NDIwNzM3NDY0M2EzYTcwNmY3MzY5Nzg1ZjY2Njk2YzY1NWY2NDY1NzM2
MzcyNjk3MDc0NmY3Mj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4y
IDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgMzUyLjAxNSBUZAovRjMuMCAx
MSBUZgo8N2I+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIg
MC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0IDMzNy4yNzUgVGQKL0YzLjAgMTEgVGYK
PGNhMjA2OTZlNzQyMDY2Njk2YzY1NmU2ZjI4MjkyMDYzNmY2ZTczNzQzYj4gVGoKRVQKCjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKQlQKNTkuMjQgMzIyLjUzNSBUZAovRjMuMCAxMSBUZgo8Y2EyMDJmMmYyMDZmNzQ2ODY1NzIy
MDYzNmY2ZTc0NjU2ZTc0MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2MTc0Njk2ZjZlMjA2NDY1NjY2OTZl
NjU2ND4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgMzA3Ljc5NSBUZAovRjMuMCAxMSBUZgo8N2Qz
Yj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2Nu
CjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgMjkzLjA1NSBUZAovRjMuMCAxMSBUZgo8NjM2YzYx
NzM3MzIwNzA2ZjczNjk3ODVmNjY2OTZjNjU2Mjc1NjYyMDJlMmUyZT4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
QlQKNTkuMjQgMjc4LjMxNSBUZAovRjMuMCAxMSBUZgo8NzQ3OTcwNjU2NDY1NjYyMDYyNjE3MzY5
NjM1ZjY2NzM3NDcyNjU2MTZkM2M3MDZmNzM2OTc4NWY2NjY5NmM2NTYyNzU2NjJjNjM2ODYxNzIy
YzYzNjg2MTcyNTQ3MjYxNjk3MzNlMjA3MDZmNzM2OTc4NWY2NjczNzQ3MjY1NjE2ZDNiPiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgpCVAo1OS4yNCAyNjMuNTc1IFRkCi9GMy4wIDExIFRmCjwyMzY1NmU2NDY5NjY+
IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDIyNS42OTYgVGQKL0YxLjAgMTAuNSBUZgo8NDk3NDIw
Nzc2Zjc1NmM2NDIwNzQ2ODY1NmUyMDYyNjUyMDZjNjU2Njc0MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2
MTc0Njk2ZjZlMjA2NDY1NjY2OTZlNjU2NDIwNzc2ODY1NzQ2ODY1NzIyMDZlNjE3NDY5NzY2NTVm
NjY2OTZjNjU2Mjc1NjYyMDNkM2QyMDcwNmY3MzY5Nzg1ZjY2Njk2YzY1NjI3NTY2PiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgoxLjEzMTkgVHcKCkJUCjQ4LjI0IDE5Ny45MTYgVGQKL0YxLjAgMTAuNSBUZgpbPDU1
NzM2NTIwNmY2NjIwNWY1MDRmNTM0OTU4NWY0MzVmNTM0ZjU1NTI+IDIwLjAxOTUgPDQzNDUyMDY0
NmY2NTczMjA2OTZlNzQ3MjZmNjQ3NTYzNjUyMDYxMjA2MzZmNzU3MDZjNjk2ZTY3MjA2MjY1NzQ3
NzY1NjU2ZTIwNDk1MzRmMjA0MzJiMmIyMDYxNmU2NDIwNTA0ZjUzNDk1ODIwNjI3NTc0MjA2OTc0
MjA2OTczMjA2MTIwNzQ3MjY5NzY2OTYxNmM+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjcuNzAz
MyBUdwoKQlQKNDguMjQgMTgyLjEzNiBUZAovRjEuMCAxMC41IFRmCjw2ZjZlNjUyZTIwNDE2ZTIw
NjE2Yzc0NjU3MjZlNjE3NDY5NzY2NTIwNzQ2ZjIwNjM2ZjZlNzM2OTY0NjU3MjIwNjk3MzIwNjk2
ZTc0NzI2ZjY0NzU2MzY5NmU2NzIwNjEyMDcwNmY3MzY5NzgyMDZlNjE2ZDY1NzM3MDYxNjM2NTIw
NjE2ZTY0MjA2ZDYxNmI2OTZlNjcyMDc0Njg2OTczPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAu
MCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJU
CjQ4LjI0IDE2Ni4zNTYgVGQKL0YxLjAgMTAuNSBUZgo8NzM3NDY0M2EzYTcwNmY3MzY5NzgzYTNh
NjY2OTZjNjU1ZjY0NjU3MzYzNzI2OTcwNzQ2ZjcyMmU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjEuMDg0MyBU
dwoKQlQKNDguMjQgMTM4LjU3NiBUZAovRjEuMCAxMC41IFRmCjw0MjZmNmY3Mzc0MjA0MTUzNDk0
ZjIwNjk2ZTYzNmM3NTY0NjU3MzIwNjEyMDcwNmY3MzY5NzgzYTNhNzM3NDcyNjU2MTZkNWY2NDY1
NzM2MzcyNjk3MDc0NmY3MjIwMjg3MzY1NjUyMD4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBzY24KMC4yNTg4IDAuNTQ1
MSAwLjc5MjIgU0NOCgoxLjA4NDMgVHcKCkJUCjMxNC4zNjg3IDEzOC41NzYgVGQKL0YxLjAgMTAu
NSBUZgpbPDY4NzQ3NDcwM2EyZjJmNzc3Nzc3PiA2OS44MjQyIDwyZTYyNmY2ZjczNzQyZTZmNzI2
NzJmNjQ2ZjYzMmY2YzY5NjI3MzJmMzE1ZjM0Mzc1ZjMwMmY2NDZmNjMyZjY4NzQ2ZDZjMmY+XSBU
SgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMjU4OCAwLjU0
NTEgMC43OTIyIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBTQ04KCjIuNDA5NCBUdwoKQlQKNDgu
MjQgMTIyLjc5NiBUZAovRjEuMCAxMC41IFRmCjw2MjZmNmY3Mzc0NWY2MTczNjk2ZjJmNzI2NTY2
NjU3MjY1NmU2MzY1MmY3MDZmNzM2OTc4NWY1ZjczNzQ3MjY1NjE2ZDVmNjQ2NTczNjM3MjY5NzA3
NDZmNzIyZTY4NzQ2ZDZjPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAw
LjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjIuNDA5NCBUdwoKQlQKMzA3
LjcxNiAxMjIuNzk2IFRkCi9GMS4wIDEwLjUgVGYKPDI5MmUyMDU0Njg2OTczMjA2NDZmNjU3MzIw
NmU2Zjc0MjA2MTcwNzA2NTYxNzIyMDY5NmUyMDc0Njg2NTIwNmU2NTc0Nzc2ZjcyNmI2OTZlNjcy
MDU0NTM+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4y
IDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMTA3LjAxNiBUZAovRjEuMCAx
MC41IFRmCjw3MDcyNmY3MDZmNzM2MTZjMjAyZDIwPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAu
MCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBzY24KMC4yNTg4IDAuNTQ1MSAwLjc5
MjIgU0NOCgpCVAoxMDAuNzYxIDEwNy4wMTYgVGQKL0YxLjAgMTAuNSBUZgpbPDY4NzQ3NDcwM2Ey
ZjJmNzc3Nzc3PiA2OS44MjQyIDwyZTZmNzA2NTZlMmQ3Mzc0NjQyZTZmNzI2NzJmNmE3NDYzMzEy
ZjczNjMzMjMyMmY3NzY3MzIzMTJmNjQ2ZjYzNzMyZjcwNjE3MDY1NzI3MzJmMzIzMDMxMzcyZjZl
MzQzNjM1MzYyZTcwNjQ2Nj5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
CnEKMC4wIDAuMCAwLjAgc2NuCjAuMCAwLjAgMC4wIFNDTgoxIHcKMCBKCjAgagpbXSAwIGQKL1N0
YW1wMiBEbwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OS4yNCAxNC4zODgg
VGQKL0YxLjAgOSBUZgo8MzQ+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
ClEKUQoKZW5kc3RyZWFtCmVuZG9iago0MSAwIG9iago8PCAvVHlwZSAvUGFnZQovUGFyZW50IDMg
MCBSCi9NZWRpYUJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9Dcm9wQm94IFswIDAgNTk1LjI4IDg0
MS44OV0KL0JsZWVkQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL1RyaW1Cb3ggWzAgMCA1OTUuMjgg
ODQxLjg5XQovQXJ0Qm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0NvbnRlbnRzIDQwIDAgUgovUmVz
b3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXQov
Rm9udCA8PCAvRjEuMCA4IDAgUgovRjMuMCA0MiAwIFIKPj4KL1hPYmplY3QgPDwgL1N0YW1wMiA5
MyAwIFIKPj4KPj4KL0Fubm90cyBbNDMgMCBSIDQ0IDAgUiA0NSAwIFJdCj4+CmVuZG9iago0MiAw
IG9iago8PCAvVHlwZSAvRm9udAovQmFzZUZvbnQgLzJhZDZiYyttcGx1czFtbi1yZWd1bGFyCi9T
dWJ0eXBlIC9UcnVlVHlwZQovRm9udERlc2NyaXB0b3IgMTM1IDAgUgovRmlyc3RDaGFyIDMyCi9M
YXN0Q2hhciAyNTUKL1dpZHRocyAxMzcgMCBSCi9Ub1VuaWNvZGUgMTM2IDAgUgo+PgplbmRvYmoK
NDMgMCBvYmoKPDwgL0JvcmRlciBbMCAwIDBdCi9BIDw8IC9UeXBlIC9BY3Rpb24KL1MgL1VSSQov
VVJJIChodHRwOi8vd3d3LmJvb3N0Lm9yZy9kb2MvbGlicy8xXzQ3XzAvZG9jL2h0bWwvYm9vc3Rf
YXNpby9yZWZlcmVuY2UvcG9zaXhfX3N0cmVhbV9kZXNjcmlwdG9yLmh0bWwpCj4+Ci9TdWJ0eXBl
IC9MaW5rCi9SZWN0IFszMTQuMzY4NyAxMzUuNTEgNTQ3LjA0IDE0OS43OV0KL1R5cGUgL0Fubm90
Cj4+CmVuZG9iago0NCAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlv
bgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cuYm9vc3Qub3JnL2RvYy9saWJzLzFfNDdfMC9kb2Mv
aHRtbC9ib29zdF9hc2lvL3JlZmVyZW5jZS9wb3NpeF9fc3RyZWFtX2Rlc2NyaXB0b3IuaHRtbCkK
Pj4KL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQ4LjI0IDExOS43MyAzMDcuNzE2IDEzNC4wMV0KL1R5
cGUgL0Fubm90Cj4+CmVuZG9iago0NSAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5
cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2My
Mi93ZzIxL2RvY3MvcGFwZXJzLzIwMTcvbjQ2NTYucGRmKQo+PgovU3VidHlwZSAvTGluawovUmVj
dCBbMTAwLjc2MSAxMDMuOTUgNDM4LjI3NDggMTE4LjIzXQovVHlwZSAvQW5ub3QKPj4KZW5kb2Jq
CjQ2IDAgb2JqCjw8IC9MZW5ndGggOTA1NAo+PgpzdHJlYW0KcQovRGV2aWNlUkdCIGNzCjAuMiAw
LjIgMC4yIHNjbgovRGV2aWNlUkdCIENTCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNzg2LjY2
NiBUZAovRjIuMCAxOCBUZgo8NzM3NDY0M2EzYTczNzQ2NDY5NmY1ZjY2Njk2YzY1NjI3NTY2PiBU
agpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4y
IDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA3NTguNjQ2IFRkCi9GMS4wIDEwLjUgVGYKPDU0Njg2NTIw
Njk2ZTc0NjU3MjY2NjE2MzY1MjA2NjZmNzIyMDczNzQ2NDNhM2E3Mzc0NjQ2OTZmNWY2NjY5NmM2
NTYyNzU2NjIwNzM2ODYxNmM2YzIwNjI2NTIwNjk2NDY1NmU3NDY5NjM2MTZjMjA3NDZmMjA3NDY4
NjUyMDY5NmU3NDY1NzI2NjYxNjM2NTIwNjY2ZjcyMjA3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYy
MDY1Nzg2MzY1NzA3NDNhPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoK
LTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDczMC44
NjYgVGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAw
LjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQg
NzMwLjg2NiBUZAovRjEuMCAxMC41IFRmCjw3MjY1NzA2YzYxNjM2OTZlNjcyMDczNzQ2NDNhM2E2
NjY5NmM2NTYyNzU2NjIwNzc2OTc0NjgyMDczNzQ2NDNhM2E3Mzc0NjQ2OTZmNWY2NjY5NmM2NTYy
NzU2NjIwNjk2ZTIwNjE2YzZjMjA2Njc1NmU2Mzc0Njk2ZjZlNzM+IFRqCkVUCgowLjAgMC4wIDAu
MCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjU2Ljg4MDUgNzA5LjA4NiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAu
MCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4y
IDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA3MDkuMDg2IFRkCi9GMS4wIDEwLjUgVGYKPDU0Njg2NTIw
NjE2NDY0Njk3NDY5NmY2ZTIwNmY2NjIwNjEyMDYzNmY2ZTczNzQ3Mjc1NjM3NDZmNzIyMDYxNjM2
MzY1NzA3NDY5NmU2NzIwNjEyMDQ2NDk0YzQ1MmEzYTIwNzM3NDY0Njk2ZjVmNjY2OTZjNjU2Mjc1
NjYzYTNhNzM3NDY0Njk2ZjVmNjY2OTZjNjU2Mjc1NjYyODQ2NDk0YzQ1MmEyMDczNzQ2NDY5NmY0
NjY5NmM2NTI5M2I+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41
IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNjg3LjMwNiBU
ZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA2ODcu
MzA2IFRkCi9GMS4wIDEwLjUgVGYKPDU0Njg2NTIwNjE2NDY0Njk3NDY5NmY2ZTIwNmY2NjIwNjY2
OTZjNjUyODI5MjA2Njc1NmU2Mzc0Njk2ZjZlMjA3MjY1NzQ3NTcyNmU2OTZlNjcyMDYxMjA0NjQ5
NGM0NTJhMjA0NjQ5NGM0NTJhMjA3Mzc0NjQ2OTZmNWY2NjY5NmM2NTYyNzU2NjNhM2E2NjY5NmM2
NTI4MjkyMDYzNmY2ZTczNzQzYj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC4yMzUyIFR3CgpCVAo0OC4yNCA2
NTkuNTI2IFRkCi9GMS4wIDEwLjUgVGYKWzw1Nz4gNjAuMDU4NiA8NjUyMDYzNmY3NTZjNjQyMDZk
NjE2ZTY0NjE3NDY1MjA2MTIwNzc3Mj4gMjAuMDE5NSA8NjE3MDcwNjU3MjIwNzQ2ZjIwNzM2NTc0
NzY2Mjc1NjYyODI5MmUyMDQ4NmY3NzY1NzY2NTcyMmMyMDc0Njg2OTczMjA2OTczMjA2YzY1NjY3
NDIwNzQ2ZjIwNjEyMDY2NzU3NDc1NzI2NTIwNzA3MjZmNzA2ZjczNjE2YzIwNjE3MzIwNzM2NTc0
NzY2Mjc1NjYyODI5MjA2MzYxNmU+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4w
IDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDY0
My43NDYgVGQKL0YxLjAgMTAuNSBUZgpbPDYyNjUyMDY5NmU3NjZmNmI+IDIwLjAxOTUgPDY1NjQy
MDYxNmM3MjY1NjE2NDc5MjA2ZjZlNjM2NTIwNzQ2ODY1MjA0NjQ5NGM0NTJhMjA2OTczMjA2NTc4
NzA2ZjczNjU2NDJlPl0gVEoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4y
IDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNjE1Ljk2NiBUZAovRjEuMCAx
MC41IFRmCjw0MTZlMjA2OTczNzM3NTY1MjA3NDZmMjA2MjY1MjA3MjY1NzM2ZjZjNzY2NTIwNjg2
NTcyNjUyMDY5NzMyMDc3Njg2NTc0Njg2NTcyMjA2MTZlNjQyMDY4NmY3NzIwNzQ2ODY5NzMyMDcz
Njg2Zjc1NmM2NDIwNjI2NTIwMjI3Mzc5NmU2MzY4NzI2ZjZlNjk3MzY1NjQyMjJlPiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgoyLjQ2MjYgVHcKCkJUCjQ4LjI0IDU4OC4xODYgVGQKL0YxLjAgMTAuNSBUZgpbPDQz
NmY2ZTczNjk2NDY1NzIyMDQ3NGU1NTIwNmM2OTYyNzM3NDY0NjMyYjJiMjA3NzY4Njk2MzY4MjA3
MDcyNmY3NjY5NjQ2NTczMjA2MjZmNzQ2ODIwNzM3NDY0Njk2ZjVmNjY2OTZjNjU2Mjc1NjYyMDc2
NzMyMDczNzQ2NDY5NmY1ZjczNzk2ZTYzNWY2NjY5NmM2NTYyNzU2NjIwNTc+IDYwLjA1ODYgPDY1
MjA3MzY4NmY3NTZjNjQyMDYxNmM3MzZmPl0gVEoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NO
CjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4y
NCA1NzIuNDA2IFRkCi9GMS4wIDEwLjUgVGYKPDYzNmY2ZTczNjk2NDY1NzIyMDc0Njg2NTIwNjE2
ZTYxNmM2ZjY3NzkyMDc3Njk3NDY4MjA3Mzc5NmU2MzVmNzc2OTc0Njg1ZjczNzQ2NDY5NmYyODI5
MjA2MTZlNjQyMDY5NmY3MzNhM2E3NDY5NjUyODI5PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAu
MCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA1
MjguMjk0IFRkCi9GMi4wIDIyIFRmCjw0OTZkNzA2YzY1NmQ2NTZlNzQ2MTc0Njk2ZjZlPiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgpCVAo0OC4yNCA0OTkuMTA2IFRkCi9GMS4wIDEwLjUgVGYKPDQxNmUyMDQ5NmQ3
MDZjNjU2ZDY1NmU3NDYxNzQ2OTZmNmUyMDZmNjYyMDc0Njg2OTczMjA3MDcyNmY3MDZmNzM2MTZj
MjA3MzY4NmY3NTZjNjQyMDYyNjUyMDcwNzI2Zjc2Njk2NDY1NjQyZT4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
MC4wNzY2IFR3CgpCVAo0OC4yNCA0NzEuMzI2IFRkCi9GMS4wIDEwLjUgVGYKWzw1ND4gMjkuNzg1
MiA8NmYyMDYyNjUyMDc1NzM2NTY2NzU2YzIwNjE3MzIwNjEyMDcyNjU2NjY1NzI2NTZlNjM2NTIw
Njk3NDIwNzM2ODZmNzU2YzY0MjA2MzZmNmQ3MDY5NmM2NTIwNzU2ZTY0NjU3MjIwNjE3NDIwNmM2
NTYxNzM3NDIwNjM2YzYxNmU2NzIwMjYyMDY3NjM2MzIwNmY2ZTIwNjI2Zjc0NjgyMDRjNjk2ZTc1
NzgyMDYxNmU2NDIwNTc2OTZlNjQ2Zjc3NzM+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4
LjI0IDQ1NS41NDYgVGQKL0YxLjAgMTAuNSBUZgo8NjE2ZTY0MjA2MjY1MjA2NDc1NjE2YzIwNmM2
OTYzNjU2ZTczNjU2NDIwNzU2ZTY0NjU3MjIwNDI1MzQ0MjA2MTZlNjQyMDRjNDc1MDRjMmU+IFRq
CkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIg
MC4yIDAuMiBTQ04KCjQuNTgzNSBUdwoKQlQKNDguMjQgNDI3Ljc2NiBUZAovRjEuMCAxMC41IFRm
Cls8NTM2NTc2NjU3Mj4gMjAuMDE5NSA8NjE2YzIwNzQ3MjY5NjE2YzczMjA2OTZkNzA2YzY1NmQ2
NTZlNzQ2MTc0Njk2ZjZlNzMyMDYzNmY3NTZjNjQyMDYyNjUyMDcwNzI2ZjY0NzU2MzY1NjQyMDc0
NmYyMDc0NjU3Mzc0MjA3MzZmNmM3NTc0Njk2ZjZlNzMyMDY3Njk3NjY1NmUyMDY0Njk2NjY2NjU3
MjY1NmU3NDIwNzM3NDYxNzI3NDY5NmU2Nz5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDgu
MjQgNDExLjk4NiBUZAovRjEuMCAxMC41IFRmCjw2MTczNzM3NTZkNzA3NDY5NmY2ZTczMmU+IFRq
CkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgMzg0LjIwNiBUZAovRjEuMCAxMC41IFRm
CjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIg
MC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCAzODQuMjA2IFRkCi9GMS4wIDEw
LjUgVGYKPDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3MzIwNjI3NTY5NmM3NDIwNmY2ZTIw
NDY0OTRjNDUyYTIwNmY2ZTIwNjEyMDUwNmY3MzY5NzgyMDczNzk3Mzc0NjU2ZD4gVGoKRVQKCjAu
MCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAu
MiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSAzNjIuNDI2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBU
agpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDM2Mi40MjYgVGQKL0YxLjAgMTAuNSBUZgo8
NzM3NDY0M2EzYTY2Njk2YzY1NjI3NTY2MjA2OTczMjA2Mjc1Njk2Yzc0MjA2ZjZlMjA0NjQ5NGM0
NTJhMjA2ZjZlMjA2MTIwNmU2ZjZlMmQ1MDZmNzM2OTc4MjA3Mzc5NzM3NDY1NmQ+IFRqCkVUCgow
LjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgMzQwLjY0NiBUZAovRjEuMCAxMC41IFRmCjxhNT4g
VGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAu
MiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCAzNDAuNjQ2IFRkCi9GMS4wIDEwLjUgVGYK
PDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3MzIwNjI3NTY5NmM3NDIwNmY2ZTIwNjEyMDcw
NmY3MzY5NzgyMDQ2NDQ+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgot
MC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgMzE4Ljg2
NiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCAz
MTguODY2IFRkCi9GMS4wIDEwLjUgVGYKPDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3MzIw
NjI3NTY5NmM3NDIwNmY2ZTIwNjEyMDZlNjE3NDY5NzY2NTIwNjY2OTZjNjUyMDY0NjU3MzYzNzI2
OTcwNzQ2ZjcyMjAyODY1MmU2NzJlMjA2MTIwNzc2OTZlNjQ2Zjc3NzMyMDQ4NDE0ZTQ0NGM0NTI5
PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24K
MC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCAyNzQuNzU0IFRkCi9GMi4wIDIyIFRmCjw1MDcyNmY2
MjZjNjU2ZDczMjA3NDZmMjA2MjY1MjA2MTY0NjQ3MjY1NzM3MzY1NjQyMDYyNjU2NjZmNzI2NTIw
NzQ2ODY5NzMyMDYzNjE2ZTIwNjI2NT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMjQ0LjgzNCBU
ZAovRjIuMCAyMiBUZgo8NmQ2MTY0NjUyMDY5NmU3NDZmMjA2MTIwNzA3MjZmNzA2ZjczNjE2YzIw
NzQ2ZjIwNDk1MzRmPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAu
NSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDIxNS42NDYg
VGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAg
c2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgMjE1
LjY0NiBUZAovRjEuMCAxMC41IFRmCjw3Mzc5NmU2MzcyNmY2ZTY5NzM2MTc0Njk2ZjZlMjA2ZjY2
MjA3Mzc0NjQ2OTZmNWY2NjY5NmM2NTYyNzU2NjIwNzc2OTc0NjgyMDczNzQ2NDY5NmY+IFRqCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNj
bgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgMTkzLjg2NiBUZAovRjEuMCAxMC41IFRmCjxh
NT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4y
IDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCAxOTMuODY2IFRkCi9GMS4wIDEwLjUg
VGYKPDY4NmY3NzIwNzM2ODZmNzU2YzY0MjA3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDYyNjUy
MDY5NmQ3MDZjNjU2ZDY1NmU3NDY1NjQzZj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4w
IDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNzQu
OTU0IDE3Mi4wODYgVGQKL0YxLjEgMTAuNSBUZgo8MjE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
MS4zNjQ0IFR3CgpCVAo4NC4yNCAxNzIuMDg2IFRkCi9GMS4wIDEwLjUgVGYKPDc3Njg2MTc0MjA3
NDZmMjA2NDZmMjA3NzY4NjU2ZTIwNzQ2ODY1MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2MTc0Njk2ZjZl
MjA2ZjY2MjA3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDY5NzMyMDYyNjE3MzY1NjQyMDZmNmUy
MDQ2NDk0YzQ1MmEyMDYxNmU2NDIwNzQ2ODc1NzMyMDczNjk2ZDY5NmM2MTcyMjA2ZjcyPiBUagpF
VAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNj
bgowLjIgMC4yIDAuMiBTQ04KCkJUCjg0LjI0IDE1Ni4zMDYgVGQKL0YxLjAgMTAuNSBUZgo8Njk2
NDY1NmU3NDY5NjM2MTZjMjA3NDZmMjA3NDY4NjUyMDcwNzI2ZjcwNmY3MzY1NjQyMDczNzQ2NDY5
NmY1ZjY2Njk2YzY1NjI3NTY2PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNj
bgoKLTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo3NC45NTQgMTM0
LjUyNiBUZAovRjEuMSAxMC41IFRmCjwyMT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4w
IDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgoxLjM4OTcg
VHcKCkJUCjg0LjI0IDEzNC41MjYgVGQKL0YxLjAgMTAuNSBUZgo8Nzc2ODYxNzQyMDc0NmYyMDY0
NmYyMDc3Njg2NTZlMjA3NDY4NjUyMDY5NmQ3MDZjNjU2ZDY1NmU3NDYxNzQ2OTZmNmUyMDZmNjYy
MDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3MzIwNjI2MTczNjU2NDIwNmY2ZTIwNmU2MTc0
Njk3NjY1NWY2NjY5NmM2NTVmNjQ2NTczNjM3MjY5NzA3NDZmNzIyMDYxNmU2ND4gVGoKRVQKCgow
LjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4y
IDAuMiAwLjIgU0NOCgpCVAo4NC4yNCAxMTguNzQ2IFRkCi9GMS4wIDEwLjUgVGYKPDc0Njg3NTcz
MjA3MzY5NmQ2OTZjNjE3MjIwNmY3MjIwNjk2NDY1NmU3NDY5NjM2MTZjMjA3NDZmMjA3NDY4NjUy
MDcwNzI2ZjcwNmY3MzY1NjQyMDZlNjE3NDY5NzY2NTVmNjY2OTZjNjU2Mjc1NjY+IFRqCkVUCgow
LjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjc0Ljk1NCA5Ni45NjYgVGQKL0YxLjEgMTAuNSBUZgo8MjE+IFRq
CkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKMy4wMTgxIFR3CgpCVAo4NC4yNCA5Ni45NjYgVGQKL0YxLjAg
MTAuNSBUZgo8Nzc2ODYxNzQyMDc0NmYyMDY0NmYyMDc3Njg2NTZlMjA3NDY4NjUyMDY5NmQ3MDZj
NjU2ZDY1NmU3NDYxNzQ2OTZmNmUyMDZmNjYyMDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3
MzIwNzM2OTZkNjk2YzYxNzIyMDZmNzIyMDY5NjQ2NTZlNzQ2OTYzNjE2YzIwNzQ2ZjIwNjI2Zjc0
NjgyMDc0Njg2NT4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNj
bgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgoxLjY3NyBUdwoKQlQKODQuMjQgODEu
MTg2IFRkCi9GMS4wIDEwLjUgVGYKPDcwNzI2ZjcwNmY3MzY1NjQyMDZlNjE3NDY5NzY2NTVmNjY2
OTZjNjU2Mjc1NjYyMDYxNmU2NDIwNzM3NDY0Njk2ZjVmNjY2OTZjNjU2Mjc1NjYyMDI4NjUyZTY3
MmUyMDcwNzI2Zjc2Njk2NDY1NzMyMDYzNmY2ZTczNzQ3Mjc1NjM3NDZmNzI3MzIwNjY3MjZmNmQy
MDYyNmY3NDY4MjA0NjQ5NGM0NTJhMjA2MTZlNjQ+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4w
IFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQK
ODQuMjQgNjUuNDA2IFRkCi9GMS4wIDEwLjUgVGYKPDQ2NDQyOT4gVGoKRVQKCjAuMCAwLjAgMC4w
IFNDTgowLjAgMC4wIDAuMCBzY24KcQowLjAgMC4wIDAuMCBzY24KMC4wIDAuMCAwLjAgU0NOCjEg
dwowIEoKMCBqCltdIDAgZAovU3RhbXAxIERvCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBT
Q04KCkJUCjU0MS4wMDkgMTQuMzg4IFRkCi9GMS4wIDkgVGYKPDM1PiBUagpFVAoKMC4wIDAuMCAw
LjAgU0NOCjAuMCAwLjAgMC4wIHNjbgpRClEKCmVuZHN0cmVhbQplbmRvYmoKNDcgMCBvYmoKPDwg
L1R5cGUgL1BhZ2UKL1BhcmVudCAzIDAgUgovTWVkaWFCb3ggWzAgMCA1OTUuMjggODQxLjg5XQov
Q3JvcEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9CbGVlZEJveCBbMCAwIDU5NS4yOCA4NDEuODld
Ci9UcmltQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0FydEJveCBbMCAwIDU5NS4yOCA4NDEuODld
Ci9Db250ZW50cyA0NiAwIFIKL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbL1BERiAvVGV4dCAvSW1h
Z2VCIC9JbWFnZUMgL0ltYWdlSV0KL0ZvbnQgPDwgL0YyLjAgMTUgMCBSCi9GMS4wIDggMCBSCi9G
MS4xIDUxIDAgUgo+PgovWE9iamVjdCA8PCAvU3RhbXAxIDkyIDAgUgo+Pgo+Pgo+PgplbmRvYmoK
NDggMCBvYmoKWzQ3IDAgUiAvWFlaIDAgODQxLjg5IG51bGxdCmVuZG9iago0OSAwIG9iagpbNDcg
MCBSIC9YWVogMCA1NTYuNTkgbnVsbF0KZW5kb2JqCjUwIDAgb2JqCls0NyAwIFIgL1hZWiAwIDMw
My4wNSBudWxsXQplbmRvYmoKNTEgMCBvYmoKPDwgL1R5cGUgL0ZvbnQKL0Jhc2VGb250IC80Mjdk
YWQrTm90b1NlcmlmCi9TdWJ0eXBlIC9UcnVlVHlwZQovRm9udERlc2NyaXB0b3IgMTM5IDAgUgov
Rmlyc3RDaGFyIDMyCi9MYXN0Q2hhciAyNTUKL1dpZHRocyAxNDEgMCBSCi9Ub1VuaWNvZGUgMTQw
IDAgUgo+PgplbmRvYmoKNTIgMCBvYmoKPDwgL0xlbmd0aCA5MjkzCj4+CnN0cmVhbQpxCi9EZXZp
Y2VSR0IgY3MKMC4yIDAuMiAwLjIgc2NuCi9EZXZpY2VSR0IgQ1MKMC4yIDAuMiAwLjIgU0NOCgpC
VAo0OC4yNCA3ODYuNjY2IFRkCi9GMi4wIDE4IFRmCjw0OTZkNzA2YzY5NjM2MTc0Njk2ZjZlNzMy
MDY2NmY3MjIwNzQ2ODY1MjA2NDY1NjY2OTZlNjk3NDY5NmY2ZTIwNmY2NjIwNjEyMDY2Njk2YzY1
MjA3Mzc0NzI2NTYxNmQ+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDc1OC42NDYgVGQKL0YxLjAg
MTAuNSBUZgpbPDU0Njg2NTIwNjM3NTcyNzI2NTZlNzQyMDYzNjE2ZTZmNmU2OTYzNjE2YzIwNzU3
MzYxNjc2NTIwNmY2NjIwNjEyMDYzNzU3Mzc0NmY2ZDIwNzM3NDcyNjU2MTZkNjI3NTY2MjA3MjY1
NzA3MjY1NzM2NTZlNzQ2OTZlNjcyMDYxMjA2ZTYxNzQ2OTc2NjUyMDY2Njk2YzY1MjA2OTczMjA3
MzZmNmQ2NTc0Njg2OTZlNjcyMDZjNjk2Yj4gMjAuMDE5NSA8NjUzYT5dIFRKCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCnEKMC45NjA4IDAuOTYwOCAwLjk2MDggc2NuCjUyLjI0
IDc0Mi44MyBtCjU0My4wNCA3NDIuODMgbAo1NDUuMjQ5MSA3NDIuODMgNTQ3LjA0IDc0MS4wMzkx
IDU0Ny4wNCA3MzguODMgYwo1NDcuMDQgNjUxLjEzIGwKNTQ3LjA0IDY0OC45MjA5IDU0NS4yNDkx
IDY0Ny4xMyA1NDMuMDQgNjQ3LjEzIGMKNTIuMjQgNjQ3LjEzIGwKNTAuMDMwOSA2NDcuMTMgNDgu
MjQgNjQ4LjkyMDkgNDguMjQgNjUxLjEzIGMKNDguMjQgNzM4LjgzIGwKNDguMjQgNzQxLjAzOTEg
NTAuMDMwOSA3NDIuODMgNTIuMjQgNzQyLjgzIGMKaApmCjAuOCAwLjggMC44IFNDTgowLjc1IHcK
NTIuMjQgNzQyLjgzIG0KNTQzLjA0IDc0Mi44MyBsCjU0NS4yNDkxIDc0Mi44MyA1NDcuMDQgNzQx
LjAzOTEgNTQ3LjA0IDczOC44MyBjCjU0Ny4wNCA2NTEuMTMgbAo1NDcuMDQgNjQ4LjkyMDkgNTQ1
LjI0OTEgNjQ3LjEzIDU0My4wNCA2NDcuMTMgYwo1Mi4yNCA2NDcuMTMgbAo1MC4wMzA5IDY0Ny4x
MyA0OC4yNCA2NDguOTIwOSA0OC4yNCA2NTEuMTMgYwo0OC4yNCA3MzguODMgbAo0OC4yNCA3NDEu
MDM5MSA1MC4wMzA5IDc0Mi44MyA1Mi4yNCA3NDIuODMgYwpoClMKUQowLjIgMC4yIDAuMiBzY24K
MC4yIDAuMiAwLjIgU0NOCgpCVAo1OS4yNCA3MjAuMDA1IFRkCi9GMy4wIDExIFRmCjw3NjZmNjk2
NDIwNzM2ZjZkNjU0Njc1NmU2MzI4Mjk+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAw
LjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0IDcwNS4yNjUg
VGQKL0YzLjAgMTEgVGYKPDdiPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNj
bgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1OS4yNCA2OTAuNTI1IFRkCi9G
My4wIDExIFRmCjxjYTIwNjM3NTczNzQ2ZjZkNWY2ZTYxNzQ2OTc2NjU1ZjY2Njk2YzY1NjI3NTY2
MjA2Mjc1NjY2NjY1NzIzYj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
MC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgNjc1Ljc4NSBUZAovRjMu
MCAxMSBUZgo8Y2EyMDY5NmY3Mzc0NzI2NTYxNmQyMDczNmY2ZDY1NDY2OTZjNjUyODI2NjI3NTY2
NjY2NTcyMjkzYj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgNjYxLjA0NSBUZAovRjMuMCAxMSBU
Zgo8N2Q+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDYyMy4xNjYgVGQKL0YxLjAgMTAuNSBUZgo8
NTQ2ODY5NzMyMDY5NzMyMDcwNzI2ZjYyNmM2NTZkNjE3NDY5NjMyMDY5NmUyMDc0Njg2MTc0M2E+
IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIg
MC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNTk1LjM4NiBUZAovRjEuMCAxMC41
IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwow
LjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA1OTUuMzg2IFRkCi9GMS4w
IDEwLjUgVGYKPDczNmY2ZDY1NDY2OTZjNjUyMDY0NmY2NTczMjA2ZTZmNzQyMDZmNzc2ZTIwNmY3
MjIwNjM2ZjZlNzQ2MTY5NmUyMDYyNzU2NjY2NjU3Mj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
QlQKNTYuODgwNSA1NzMuNjA2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAw
LjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjY2LjI0IDU3My42MDYgVGQKL0YxLjAgMTAuNSBUZgo8NzM2ZjZkNjU0NjY5NmM2
NTIwNjQ2ZjY1NzMyMDZlNmY3NDIwNjk2ZDcwNmM2NTZkNjU2ZTc0MjA3NDY4NjUyMDY5NmU3NDY1
NzI2NjYxNjM2NTIwNmY2NjIwNjY3Mzc0NzI2NTYxNmQyZTIwNGU2Zjc0NjE2MjZjNzkyMDc0Njg2
NTIwNjY3NTZlNjM3NDY5NmY2ZTczMjA2ZjcwNjU2ZTI4MjkyMDYxNmU2NDIwNjM2YzZmNzM2NTI4
MjkyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNTQ1LjgyNiBUZAovRjEuMCAxMC41IFRmCjw0
MTZlMjA2MTZjNzQ2NTcyNmU2MTc0Njk3NjY1MjA2OTczM2E+IFRqCkVUCgowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCnEKMC45NjA4IDAuOTYwOCAwLjk2MDggc2NuCjUyLjI0IDUzMC4w
MSBtCjU0My4wNCA1MzAuMDEgbAo1NDUuMjQ5MSA1MzAuMDEgNTQ3LjA0IDUyOC4yMTkxIDU0Ny4w
NCA1MjYuMDEgYwo1NDcuMDQgNDIzLjU3IGwKNTQ3LjA0IDQyMS4zNjA5IDU0NS4yNDkxIDQxOS41
NyA1NDMuMDQgNDE5LjU3IGMKNTIuMjQgNDE5LjU3IGwKNTAuMDMwOSA0MTkuNTcgNDguMjQgNDIx
LjM2MDkgNDguMjQgNDIzLjU3IGMKNDguMjQgNTI2LjAxIGwKNDguMjQgNTI4LjIxOTEgNTAuMDMw
OSA1MzAuMDEgNTIuMjQgNTMwLjAxIGMKaApmCjAuOCAwLjggMC44IFNDTgowLjc1IHcKNTIuMjQg
NTMwLjAxIG0KNTQzLjA0IDUzMC4wMSBsCjU0NS4yNDkxIDUzMC4wMSA1NDcuMDQgNTI4LjIxOTEg
NTQ3LjA0IDUyNi4wMSBjCjU0Ny4wNCA0MjMuNTcgbAo1NDcuMDQgNDIxLjM2MDkgNTQ1LjI0OTEg
NDE5LjU3IDU0My4wNCA0MTkuNTcgYwo1Mi4yNCA0MTkuNTcgbAo1MC4wMzA5IDQxOS41NyA0OC4y
NCA0MjEuMzYwOSA0OC4yNCA0MjMuNTcgYwo0OC4yNCA1MjYuMDEgbAo0OC4yNCA1MjguMjE5MSA1
MC4wMzA5IDUzMC4wMSA1Mi4yNCA1MzAuMDEgYwpoClMKUQowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgpCVAo1OS4yNCA1MDcuMTg1IFRkCi9GMy4wIDExIFRmCjw3NjZmNjk2NDIwNzM2
ZjZkNjU0Njc1NmU2MzI4Mjk+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0IDQ5Mi40NDUgVGQKL0Yz
LjAgMTEgVGYKPDdiPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIg
MC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1OS4yNCA0NzcuNzA1IFRkCi9GMy4wIDEx
IFRmCjxjYTIwNjM3NTczNzQ2ZjZkNWY2ZTYxNzQ2OTc2NjU1ZjY2Njk2YzY1NjI3NTY2MjA2Mjc1
NjY2NjY1NzIzYj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgNDYyLjk2NSBUZAovRjMuMCAxMSBU
Zgo8Y2EyMDczNzQ2NDNhM2E2NjczNzQ3MjY1NjE2ZDIwNzM2ZjZkNjU0NjY5NmM2NTNiPiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgpCVAo1OS4yNCA0NDguMjI1IFRkCi9GMy4wIDExIFRmCjxjYTIwNzM2ZjZkNjU0
NjY5NmM2NTJlNzM2NTc0NWY3MjY0NjI3NTY2Mjg2Mjc1NjY2NjY1NzIyOTNiPiBUagpFVAoKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgpCVAo1OS4yNCA0MzMuNDg1IFRkCi9GMy4wIDExIFRmCjw3ZD4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
QlQKNDguMjQgMzk1LjYwNiBUZAovRjEuMCAxMC41IFRmCjw1NDY4Njk3MzIwNjk3MzIwNzA3MjZm
NjI2YzY1NmQ2MTc0Njk2MzIwNjk2ZTIwNzQ2ODYxNzQzYT4gVGoKRVQKCjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKQlQKNTYuODgwNSAzNjcuODI2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAu
MCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4y
IDAuMiBTQ04KCkJUCjY2LjI0IDM2Ny44MjYgVGQKL0YxLjAgMTAuNSBUZgo8NzM2ZjZkNjU0NjY5
NmM2NTIwNjQ2ZjY1NzMyMDZlNmY3NDIwNmY3NzZlMjA2ZjcyMjA2MzZmNmU3NDYxNjk2ZTIwNjI3
NTY2NjY2NTcyPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBU
YwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDM0Ni4wNDYgVGQK
L0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
CgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgMzQ2LjA0
NiBUZAovRjEuMCAxMC41IFRmCjw3MzZmNmQ2NTQ2Njk2YzY1MjA2MzZmNmU3Mzc0NzI3NTYzNzQ3
MzIwNjEyMDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNzc2ODY5NjM2ODIwNjk3MzIwNzI2NTY0
NzU2ZTY0NjE2ZTc0MmU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjIuOTAyOCBUdwoKQlQKNDguMjQgMzE4LjI2
NiBUZAovRjEuMCAxMC41IFRmCls8NDEyMDY2NzU2ZTYzNzQ2OTZmNmUyMDc0Njg2MTc0MjA2Zjcw
NjU3Mj4gMjAuMDE5NSA8NjE3NDY1NzMyMDZmNmUyMDYxMjA2NjY5NmM2NTIwNzM3NDcyNjU2MTZk
MjA3MzY4NmY3NTZjNjQyMDYyNjUyMDYxNjI2YzY1MjA3NDZmMjA2MTYzNjM2NTcwNzQyMDYxMjA3
Mzc0NzI2NTYxNmQyMDc0Njg2MTc0MjA3NTczNjU3MzIwNjU2OTc0Njg2NTcyPl0gVEoKRVQKCgow
LjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4y
IDAuMiAwLjIgU0NOCgowLjA1ODggVHcKCkJUCjQ4LjI0IDMwMi40ODYgVGQKL0YxLjAgMTAuNSBU
Zgo8NzM3NDY0M2EzYTY2Njk2YzY1NjI3NTY2MmMyMDczNzQ2NDNhM2E3Mzc0NjQ2OTZmNWY2NjY5
NmM2NTYyNzU2NjIwNmY3MjIwNzM3NDY0M2EzYTZlNjE3NDY5NzY2NTVmNjY2OTZjNjU2Mjc1NjYy
ZTIwNDk3NDIwNmQ3NTczNzQyMDYyNjUyMDZjNjU2NzYxNmMyMDY2NmY3MjIwNzQ2ODYxNzQyMDY2
NzU2ZTYzNzQ2OTZmNmUyMDc0NmYyMDc1NzM2NTIwNjY3NTZlNjM3NDY5NmY2ZTczPiBUagpFVAoK
CjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDI4Ni43MDYgVGQKL0YxLjAgMTAuNSBUZgo8NzM3NTYz
NjgyMDYxNzMyMDZmNzA2NTZlMjgyOTIwNzc2ODY5NjM2ODIwNjE3MjY1MjA2Mzc1NzI3MjY1NmU3
NDZjNzkyMDYxNzY2MTY5NmM2MTYyNmM2NTIwNjk2ZTIwNzM3NDY0M2EzYTY2NzM3NDcyNjU2MTZk
MjA2Mjc1NzQyMDZlNmY3NDIwNjk2ZTIwNzM3NDY0M2EzYTY5NmY3Mzc0NzI2NTYxNmQyZT4gVGoK
RVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAw
LjIgMC4yIFNDTgoKQlQKNDguMjQgMjU4LjkyNiBUZAovRjEuMCAxMC41IFRmCjw0NDZmMjA3NzY1
M2E+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNj
bgowLjIgMC4yIDAuMiBTQ04KCjAuMDY5NyBUdwoKQlQKNDguMjQgMjMxLjE0NiBUZAovRjEuMCAx
MC41IFRmCls8NjEyOTIwNjU3ODc0NjU2ZTY0MjA3Mzc0NjQzYTNhNjY3Mzc0NzI2NTYxNmQyMDc0
NmYyMDcwNjU3MjZkNjk3NDIwNjk3NDczMjA3MjY0NjI3NTY2MjA3NDZmMjA2MjY1MjA2MTZlPiAy
MC4wMTk1IDw3OTIwNmY2NjIwNzQ2ODY1MjA3NDY4NzI2NTY1M2YyMDYyMjkyMDcwNzI2Zjc2Njk2
NDY1MjA3Mzc0NjQzYTNhNzM3NDY0Njk2ZjVmNjY3Mzc0NzI2NTYxNmQyODI5MjA3NDZmMjA2NzZm
Pl0gVEoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4y
IDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCAyMTUuMzY2IFRkCi9GMS4wIDEwLjUg
VGYKPDc3Njk3NDY4MjA3Mzc0NjQzYTNhNzM3NDY0Njk2ZjVmNjY2OTZjNjU2Mjc1NjYyODI5MjA2
MzI5MjA3MDcyNmY3NjY5NjQ2NTIwNjEyMDZlNjU3NzIwNjI2MTczNjUyMDYzNmM2MTczNzMyMDcz
NzQ2NDNhM2E2NjY5NmM2NTczNzQ3MjY1NjE2ZDI4MjkyMDYxNzMyMDYxMjA2MjYxNzM2NTIwNjM2
YzYxNzM3MzIwNmY2NjIwNjY2ZjcyMjA2MTZjNmMyMDc0Njg3MjY1NjUzZj4gVGoKRVQKCjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKMC41MzEzIFR3CgpCVAo0OC4yNCAxODcuNTg2IFRkCi9GMS4wIDEwLjUgVGYKWzw3Mzc0NjQ2
OTZmNWY2NjY5NmM2NTYyNzU2NjJjMjA2ZTYxNzQ2OTc2NjU1ZjY2Njk2YzY1NjI3NTY2MjA2MTZl
NjQyMDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjM2Zjc1NmM2NDIwNjg2MTc2NjUyMDY0Njk2
NjY2NjU3MjY1NmU3NDIwNzM2OTdhNjU3MzJlMjA1Nz4gNjAuMDU4NiA8NjUyMDc3NmY3NTZjNjQy
MDcwNzI2NTY2NjU3MjIwNzQ2ODY1NzM2NTIwNzQ2ZjIwNjI2NT5dIFRKCkVUCgoKMC4wIFR3CjAu
MCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4y
IFNDTgoKQlQKNDguMjQgMTcxLjgwNiBUZAovRjEuMCAxMC41IFRmCls8NmQ2NTZkNjI2NTcyNzMy
MDcyPiAyMC4wMTk1IDw2MTc0Njg2NTcyMjA3NDY4NjE2ZTIwNzA2ZjY5NmU3NDY1NzI3MzJlMjA1
MzZmMjA3NzY1MjA2MTY0NjQyMDc0Njg2NTIwNjY2OTZjNjU2Mjc1NjYyMDc0Nzk3MDY1MjA2MTcz
MjA3NDY1NmQ3MDZjNjE3NDY1MjA3MDYxNzI+IDIwLjAxOTUgPDYxNmQ2NTc0NjU3Mj5dIFRKCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCnEKMC45NjA4IDAuOTYwOCAwLjk2MDgg
c2NuCjUyLjI0IDE1NS45OSBtCjU0My4wNCAxNTUuOTkgbAo1NDUuMjQ5MSAxNTUuOTkgNTQ3LjA0
IDE1NC4xOTkxIDU0Ny4wNCAxNTEuOTkgYwo1NDcuMDQgOTMuNzcgbAo1NDcuMDQgOTEuNTYwOSA1
NDUuMjQ5MSA4OS43NyA1NDMuMDQgODkuNzcgYwo1Mi4yNCA4OS43NyBsCjUwLjAzMDkgODkuNzcg
NDguMjQgOTEuNTYwOSA0OC4yNCA5My43NyBjCjQ4LjI0IDE1MS45OSBsCjQ4LjI0IDE1NC4xOTkx
IDUwLjAzMDkgMTU1Ljk5IDUyLjI0IDE1NS45OSBjCmgKZgowLjggMC44IDAuOCBTQ04KMC43NSB3
CjUyLjI0IDE1NS45OSBtCjU0My4wNCAxNTUuOTkgbAo1NDUuMjQ5MSAxNTUuOTkgNTQ3LjA0IDE1
NC4xOTkxIDU0Ny4wNCAxNTEuOTkgYwo1NDcuMDQgOTMuNzcgbAo1NDcuMDQgOTEuNTYwOSA1NDUu
MjQ5MSA4OS43NyA1NDMuMDQgODkuNzcgYwo1Mi4yNCA4OS43NyBsCjUwLjAzMDkgODkuNzcgNDgu
MjQgOTEuNTYwOSA0OC4yNCA5My43NyBjCjQ4LjI0IDE1MS45OSBsCjQ4LjI0IDE1NC4xOTkxIDUw
LjAzMDkgMTU1Ljk5IDUyLjI0IDE1NS45OSBjCmgKUwpRCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4y
IDAuMiBTQ04KCkJUCjU5LjI0IDEzMy4xNjUgVGQKL0YzLjAgMTEgVGYKPDc0Nzk3MDY1NjQ2NTY2
MjA3Mzc0NjQzYTNhNjI2MTczNjk2MzVmNjY3Mzc0NzI2NTYxNmQzYzczNzQ2NDNhM2E2NjY5NmM2
NTYyNzU2NjJjNjM2ODYxNzIzZTIwNzM3NDY0M2EzYTY2NzM3NDcyNjU2MTZkM2I+IFRqCkVUCgow
LjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjU5LjI0IDExOC40MjUgVGQKL0YzLjAgMTEgVGYKPDc0Nzk3MDY1NjQ2NTY2MjA3
Mzc0NjQzYTNhNjI2MTczNjk2MzVmNjY3Mzc0NzI2NTYxNmQzYzZlNjE3NDY5NzY2NTVmNjY2OTZj
NjU2Mjc1NjYyYzYzNjg2MTcyM2UyMDZlNjE3NDY5NzY2NTVmNjY3Mzc0NzI2NTYxNmQzYj4gVGoK
RVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAw
LjIgMC4yIFNDTgoKQlQKNTkuMjQgMTAzLjY4NSBUZAovRjMuMCAxMSBUZgo8NzQ3OTcwNjU2NDY1
NjYyMDczNzQ2NDNhM2E2MjYxNzM2OTYzNWY2NjczNzQ3MjY1NjE2ZDNjNzM3NDY0Njk2ZjVmNjY2
OTZjNjU2Mjc1NjYyYzYzNjg2MTcyM2UyMDczNzQ2NDY5NmY1ZjY2NzM3NDcyNjU2MTZkM2I+IFRq
CkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIg
MC4yIDAuMiBTQ04KCjAuMTA4OCBUdwoKQlQKNDguMjQgNjUuODA2IFRkCi9GMS4wIDEwLjUgVGYK
Wzw0OTc0MjA3MzY4NmY3NTZjNjQyMDYxNmM3MzZmMjA2MjY1MjA3MDZmNzM3MzY5NjI2YzY1MjA3
NDZmMjA2ODYxNzY2NTIwNjEyMDY2NzU2ZTYzNzQ2OTZmNmUyMDc0Njg2MTc0MjA2ZjcwNjU3Mj4g
MjAuMDE5NSA8NjE3NDY1NzMyMDZmNmUyMDYxMjA2NjY5NmM2NTIwNjI2MTczNjU2NDIwNzM3NDcy
NjU2MTZkMjA2MTZlNjQyMDYzNjE2ZTIwNjE2MzYzNjU3MDc0MjA2MTZlPiAyMC4wMTk1IDw3OT5d
IFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KcQowLjAgMC4w
IDAuMCBzY24KMC4wIDAuMCAwLjAgU0NOCjEgdwowIEoKMCBqCltdIDAgZAovU3RhbXAyIERvCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ5LjI0IDE0LjM4OCBUZAovRjEuMCA5
IFRmCjwzNj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KUQpRCgplbmRz
dHJlYW0KZW5kb2JqCjUzIDAgb2JqCjw8IC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIKL01lZGlh
Qm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0Nyb3BCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQmxl
ZWRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovVHJpbUJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9B
cnRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQ29udGVudHMgNTIgMCBSCi9SZXNvdXJjZXMgPDwg
L1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldCi9Gb250IDw8IC9G
Mi4wIDE1IDAgUgovRjEuMCA4IDAgUgovRjMuMCA0MiAwIFIKPj4KL1hPYmplY3QgPDwgL1N0YW1w
MiA5MyAwIFIKPj4KPj4KPj4KZW5kb2JqCjU0IDAgb2JqCls1MyAwIFIgL1hZWiAwIDg0MS44OSBu
dWxsXQplbmRvYmoKNTUgMCBvYmoKPDwgL0xlbmd0aCA4MDk4Cj4+CnN0cmVhbQpxCi9EZXZpY2VS
R0IgY3MKMC4yIDAuMiAwLjIgc2NuCi9EZXZpY2VSR0IgQ1MKMC4yIDAuMiAwLjIgU0NOCgoxLjE0
NzMgVHcKCkJUCjQ4LjI0IDc5NC42NzYgVGQKL0YxLjAgMTAuNSBUZgpbPDZmNjYyMDc0Njg2NTcz
NjUyMDc0Njg3MjY1NjUyMDc0Nzk3MDY1NzMyZTIwNTQ2ODY1NzI2NTY2NmY3MjY1MjA3NzY1MjA3
MDcyNmY3MDZmNzM2NTIwNjk2ZTc0NzI2ZjY0NzU2MzY5NmU2NzIwNjE2ZTIwNjE2MjczNzQ3Mj4g
MjAuMDE5NSA8NjE2Mzc0MjA2MjYxNzM2NTIwNjM2YzYxNzM3MzIwNjY2ZjcyMjA2MTIwNjI2MTcz
Njk2MzVmNjY3Mzc0NzI2NTYxNmQ+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4w
IDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDc3
OC44OTYgVGQKL0YxLjAgMTAuNSBUZgo8Nzc2ODY5NjM2ODIwNzM2OTZkNzA2Yzc5MjA2MTc1Njc2
ZDY1NmU3NDczMjA2MjYxNzM2OTYzNWY2OTZmNzM3NDcyNjU2MTZkMjA3NzY5NzQ2ODIwNmY3MDY1
NmUyODI5MmMyMDY5NzM1ZjZmNzA2NTZlMjgyOTIwNjE2ZTY0MjA2MzZjNmY3MzY1MjgyOTIwNmQ2
NTc0Njg2ZjY0NzM+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDc1MS4xMTYgVGQKL0YxLjAgMTAu
NSBUZgpbPDU0Njg2NTIwNmU2MTZkNjUyMDY2NzM3NDcyNjU2MTZkNWY2OTZlNzQ2NTcyNjY2MTYz
NjUyMDY5NzMyMDc1NzM2NTY0MjA2ODY1NzI2NTIwNzA3MjY1MjA2MjY5NmI+IDIwLjAxOTUgPDY1
NzM2ODY1NjQ2OTZlNjcyZT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDcwNy4wMDQgVGQKL0Yy
LjAgMjIgVGYKPDQxNmM3NDY1NzI2ZTYxNzQ2OTc2NjU3MzIwNzQ2ZjIwNzQ2ODY5NzMyMDcwNzI2
ZjcwNmY3MzYxNmMzYT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0w
LjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSA2NzcuODE2
IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDY3
Ny44MTYgVGQKL0YxLjAgMTAuNSBUZgo8NzM3NDYxNmU2NDYxNzI2NDY5NzM2NTIwNzM2ZjZkNjUy
MDY1Nzg2OTczNzQ2OTZlNjcyMDZlNmY2ZTJkNzM3NDYxNmU2NDYxNzI2NDIwNjU3ODc0NjU2ZTcz
Njk2ZjZlNzM+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRj
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNjU2LjAzNiBUZAov
RjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
CjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA2NTYuMDM2
IFRkCi9GMS4wIDEwLjUgVGYKPDcwNzI2Zjc2Njk2NDY1MjA2ODY5Njc2ODY1NzIyZDZjNjU3NjY1
NmMyMDY5NmU3NDY1NzI2NjYxNjM2NTczMjA2NjZmNzIyMDc0Njg2NTIwNzU3MzY1MjA2MzYxNzM2
NTczMjA2MzZmNmU3MzY5NjQ2NTcyNjU2ND4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4w
IDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYu
ODgwNSA2MzQuMjU2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NO
CjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CkJUCjY2LjI0IDYzNC4yNTYgVGQKL0YxLjAgMTAuNSBUZgo8NjQ2ZjIwNmU2Zjc0Njg2OTZlNjcy
ZTIwNGM2NTYxNzY2NTIwNzQ2ODY1MjA3Mzc0NjE3NDc1NzMyMDcxNzU2ZjIwNjE3MzIwNjk3MzJl
PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24K
MC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA1OTQuNDE2IFRkCi9GMi4wIDE4IFRmCjw1Mzc0NjE2
ZTY0NjE3MjY0Njk3MzY5NmU2NzIwNmU2ZjZlMmQ3Mzc0NjE2ZTY0NjE3MjY0MjA2NTc4NzQ2NTZl
NzM2OTZmNmU3Mz4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNTY2LjM5NiBUZAovRjEuMCAxMC41
IFRmCls8NTc+IDYwLjA1ODYgPDY1MjA2MzZmNzU2YzY0MjA3MjY1NzE3NTY5NzI2NTIwNzQ2ODYx
NzQzYT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNTM4LjYxNiBUZAovRjEu
MCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAu
MCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA1MzguNjE2IFRk
Ci9GMS4wIDEwLjUgVGYKPDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNzA3MjZmNzY2OTY0NjU3
MzIwNjEyMDYzNmY2ZTczNzQ3Mjc1NjM3NDZmNzIyMDYxNjM2MzY1NzA3NDY5NmU2NzIwNjEyMDQ2
NDk0YzQ1MmE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRj
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNTE2LjgzNiBUZAov
RjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
CjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA1MTYuODM2
IFRkCi9GMS4wIDEwLjUgVGYKPDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNzA3MjZmNzY2OTY0
NjU3MzIwNjEyMDY2NzU2ZTYzNzQ2OTZmNmUyMDc0NmYyMDZmNjI3NDYxNjk2ZTIwNjEyMDQ2NDk0
YzQ1MmE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNDk1LjA1NiBUZAovRjEu
MCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAu
MCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA0OTUuMDU2IFRk
Ci9GMS4wIDEwLjUgVGYKPDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNzA3MjZmNzY2OTY0NjU3
MzIwNjEyMDYzNmY2ZTczNzQ3Mjc1NjM3NDZmNzIyMDYxNjM2MzY1NzA3NDY5NmU2NzIwNjEyMDZl
NjE3NDY5NzY2NTIwNjY2OTZjNjUyMDY0NjU3MzYzNzI2OTcwNzQ2ZjcyPiBUagpFVAoKMC4wIDAu
MCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgpCVAo1Ni44ODA1IDQ3My4yNzYgVGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2Nu
CjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgNDczLjI3NiBUZAovRjEuMCAxMC41IFRmCjw3Mzc0
NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDcwNzI2Zjc2Njk2NDY1NzMyMDYxMjA2Njc1NmU2Mzc0Njk2
ZjZlMjA3NDZmMjA2ZjYyNzQ2MTY5NmUyMDYxMjA2ZTYxNzQ2OTc2NjUyMDY2Njk2YzY1MjA2NDY1
NzM2MzcyNjk3MDc0NmY3Mj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
MC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNDQ1LjQ5NiBUZAovRjEu
MCAxMC41IFRmCjw1NDY4NjU3MzY1MjA2OTZlMjA2NTY2NjY2NTYzNzQyMDZkNjE2ZTY0NjE3NDY1
MjA3NDY4NjE3NDIwNzM3NDY0M2EzYTY2Njk2YzY1NjI3NTY2MjAzZDNkMjA3Mzc0NjQ2OTZmNWY2
NjY5NmM2NTYyNzU2NjIwNjE2ZTY0MmY2ZjcyMjA3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDNk
M2QyMDZlNjE3NDY5NzY2NTVmNjY2OTZjNjU2Mjc1NjY+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0
IDQxNy43MTYgVGQKL0YxLjAgMTAuNSBUZgpbPDU3Njg2MTc0MjA2MzZmNmU3Mzc0NzI+IDIwLjAx
OTUgPDYxNjk2ZTc0NzMyMDY0NmYyMDc0Njg2NTczNjUyMDcwNmM2MTYzNjUyMDZmNmUyMDYxNmUy
MDY5NmQ3MDZjNjU2ZDY1NmU3NDYxNzQ2OTZmNmUzZj5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0
IDM3Ny44NzYgVGQKL0YyLjAgMTggVGYKPDUwNzI2Zjc2Njk2NDY1MjA2ODY5Njc2ODY1NzIyMDZj
NjU3NjY1NmMyMDY5NmU3NDY1NzI2NjYxNjM2NTczMjA2OTZlNzM3NDY1NjE2ND4gVGoKRVQKCjAu
MCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4y
IFNDTgoKMC42NDczIFR3CgpCVAo0OC4yNCAzNDkuODU2IFRkCi9GMS4wIDEwLjUgVGYKWzw1MDcy
NmY3NjY5NjQ2OTZlNjcyMDY4Njk2NzY4NjU3MjIwNmM2NTc2NjU2YzIwNjk2ZTc0NjU3MjY2NjE2
MzY1NzMyMDY5NzMyMDY2NzI+IDIwLjAxOTUgPDYxNzU2NzY4NzQyMDc3Njk3NDY4MjA2OTZkNzA2
YzY1NmQ2NTZlNzQ2MTc0Njk2ZjZlMjA2NDY1NjY2OTZlNjU2NDIwNjk3MzczNzU2NTczMjA3NzY4
Njk2MzY4MjA3NzZmNzU2YzY0MjA2ZTY1NjU2ND5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4w
IFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC45
Mjg1IFR3CgpCVAo0OC4yNCAzMzQuMDc2IFRkCi9GMS4wIDEwLjUgVGYKWzw3NDZmMjA2MjY1MjA3
NzZmNzI2Yj4gMjAuMDE5NSA8NjU2NDIwNmY3NTc0MjA2OTZlMjA2Njc1NmM2YzJlMjA1Mzc1NjM2
ODIwNzA3MjZmNzA2ZjczNjE2YzczMjA2ZDY5Njc2ODc0MjA3MjY1NzE3NTY5NzI2NTIwNzM2ZjZk
NjU3NDY4Njk2ZTY3MjA2YzY5NmI+IDIwLjAxOTUgPDY1MjA3NDY4Njk3MzIwNzA3MjZmNzA2Zjcz
NjE2YzIwNjE3MzIwNjEyMDZjNmY3NzJkNmM2NTc2NjU2Yz5dIFRKCkVUCgoKMC4wIFR3CjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKNi44NTk1IFR3CgpCVAo0OC4yNCAzMTguMjk2IFRkCi9GMS4wIDEwLjUgVGYKPDY5NmU3NDY1
NzI2NjYxNjM2NTIwNmY2ZTIwNzc2ODY5NjM2ODIwNzQ2ZjIwNjI3NTY5NmM2NDIwNmY3MjIwNzQ2
ODY1NzkyMDZkNjk2NzY4NzQyMDc1NzM2NTIwNjE2ZTIwNjU2ZTc0Njk3MjY1NmM3OTIwNjQ2OTY2
NjY2NTcyNjU2ZTc0MjA2ZDY1NjM2ODYxNmU2OTczNmQyMDY1MmU2NzJlPiBUagpFVAoKCjAuMCBU
dwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIHNj
bgowLjI1ODggMC41NDUxIDAuNzkyMiBTQ04KCkJUCjQ4LjI0IDMwMi41MTYgVGQKL0YxLjAgMTAu
NSBUZgpbPDY4NzQ3NDcwM2EyZjJmNzc3Nzc3PiA2OS44MjQyIDwyZTYyNmY2ZjczNzQyZTZmNzI2
NzJmNjQ2ZjYzMmY2YzY5NjI3MzJmMzE1ZjM0MzQ1ZjMwMmY2NDZmNjMyZjY4NzQ2ZDZjMmY2MjZm
NmY3Mzc0MmY2OTZlNzQ2NTcyNzA3MjZmNjM2NTczNzMyZjY2Njk2YzY1NWY2YzZmNjM2YjJlNjg3
NDZkNmM+XSBUSgpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAu
MiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCAyNjIuNjc2IFRkCi9GMi4wIDE4IFRmCjw0
NDZmMjA2ZTZmNzQ2ODY5NmU2Nz4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC4xNjI5IFR3CgpCVAo0OC4yNCAy
MzQuNjU2IFRkCi9GMS4wIDEwLjUgVGYKPDQ5MjA2MTcyNjc3NTY1MjA2MTY3NjE2OTZlNzM3NDIw
NzQ2ODY1MjAyMjY0NmYyMDZlNmY3NDY4Njk2ZTY3MjIyMDZmNzA3NDY5NmY2ZTIwNjE3MzIwNzQ2
ODY5NzMyMDY5NzMyMDYxMjA2NjcyNjU3MTc1NjU2ZTc0MjA3MjY1NzE3NTY5NzI2NTZkNjU2ZTc0
MjA2ZjZlMjA1MDRmNTM0OTU4MjA2MjYxNzM2NTY0MjA3Mzc5NzM3NDY1NmQ3MzIwNjE3Mz4gVGoK
RVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBz
Y24KMC4yIDAuMiAwLjIgU0NOCgo2LjAxMzcgVHcKCkJUCjQ4LjI0IDIxOC44NzYgVGQKL0YxLjAg
MTAuNSBUZgpbPDY1NzY2OTY0NjU2ZTYzNjU2NDIwNjI+IDIwLjAxOTUgPDc5MjA3MTc1NjU3Mzc0
Njk2ZjZlNzMyMDZmNmUyMDczNzQ2MTYzNmIyMDZmNzY2NTcyNjY2YzZmNzcyMDYxNmU2NDIwNjU2
YzczNjU3NzY4NjU3MjY1MjA2NzZmNjk2ZTY3MjA2MjYxNjM2YjIwNmQ2MTZlPiAyMC4wMTk1IDw3
OTIwNzk2NTYxNzI3MzJlMjA1MzY1NjUzYT5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgc2NuCjAuMjU4OCAwLjU0NTEg
MC43OTIyIFNDTgoKQlQKNDguMjQgMjAzLjA5NiBUZAovRjEuMCAxMC41IFRmCls8Njg3NDc0NzA3
MzNhMmYyZjc3Nzc3Nz4gNjkuODI0MiA8MmU2NzZmNmY2NzZjNjUyZTYzNmYyZTc1NmIyZjczNjU2
MTcyNjM2ODNmNzEzZDY2NzM3NDcyNjU2MTZkMmI2MTZlNjQyYjY2Njk2YzY1MmI2NDY1NzM2Mzcy
Njk3MDc0NmY3Mj5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjE0LjM4MDkgVHcKCkJUCjQ4LjI0IDE3NS4zMTYg
VGQKL0YxLjAgMTAuNSBUZgo8NmU2Zjc0NjE2MjZjNzkzYTIwPiBUagpFVAoKCjAuMCBUdwowLjAg
MC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIHNjbgowLjI1
ODggMC41NDUxIDAuNzkyMiBTQ04KCjE0LjM4MDkgVHcKCkJUCjEwNi4zODQ5IDE3NS4zMTYgVGQK
L0YxLjAgMTAuNSBUZgpbPDY4NzQ3NDcwNzMzYTJmMmY3Mzc0NjE2MzZiPiAyMC4wMTk1IDw2Zjc2
NjU3MjY2NmM2Zjc3PiA2OS44MjQyIDwyZTYzNmY2ZDJmNzE3NTY1NzM3NDY5NmY2ZTczMmYzMjM3
MzQzNjMxMzYzODJmNjg2Zjc3MmQ3NDZmMmQ2MzZmNmU3Mzc0NzI3NTYzNzQyZDYxMmQ2MzJkNjY3
Mzc0NzI2NTYxNmQyZDY2NzI2ZjZkMmQ2MTJkNzA2ZjczNjk3ODJkPl0gVEoKRVQKCgowLjAgVHcK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBzY24K
MC4yNTg4IDAuNTQ1MSAwLjc5MjIgU0NOCgpCVAo0OC4yNCAxNTkuNTM2IFRkCi9GMS4wIDEwLjUg
VGYKPDY2Njk2YzY1MmQ2NDY1NzM2MzcyNjk3MDc0NmY3Mj4gVGoKRVQKCjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDgu
MjQgMTMxLjc1NiBUZAovRjEuMCAxMC41IFRmCls8NDk2ZDcwNmM2NTZkNjU2ZTc0Njk2ZTY3MjA2
MTIwNjY2NDYyNzU2NjIwNjk3MzIwNjE2YzczNmYyMDY0NjU3MzYzNzI2OTYyNjU2NDIwNjk2ZTIw
NGU2OTYzNmY2YzYxNjkyMDRhNmY3Mzc1NzQ3NDY5NzNkNTczMjAyMjU0Njg2NTIwNDMyYjJiMjA1
Mzc0NjE2ZTY0NjE3MjY0MjA0YzY5NjI3Mj4gMjAuMDE5NSA8NjE3Mjc5MjIyZT5dIFRKCkVUCgow
LjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAu
MiBTQ04KCkJUCjQ4LjI0IDg3LjY0NCBUZAovRjIuMCAyMiBUZgo8NDQ2OTczNjM3NTczNzM2OTZm
NmU3Mz4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KcQowLjAgMC4wIDAu
MCBzY24KMC4wIDAuMCAwLjAgU0NOCjEgdwowIEoKMCBqCltdIDAgZAovU3RhbXAxIERvCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU0MS4wMDkgMTQuMzg4IFRkCi9GMS4wIDkg
VGYKPDM3PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgpRClEKCmVuZHN0
cmVhbQplbmRvYmoKNTYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UKL1BhcmVudCAzIDAgUgovTWVkaWFC
b3ggWzAgMCA1OTUuMjggODQxLjg5XQovQ3JvcEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9CbGVl
ZEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9UcmltQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0Fy
dEJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9Db250ZW50cyA1NSAwIFIKL1Jlc291cmNlcyA8PCAv
UHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0KL0ZvbnQgPDwgL0Yx
LjAgOCAwIFIKL0YyLjAgMTUgMCBSCj4+Ci9YT2JqZWN0IDw8IC9TdGFtcDEgOTIgMCBSCj4+Cj4+
Ci9Bbm5vdHMgWzYwIDAgUiA2MiAwIFIgNjMgMCBSIDY0IDAgUl0KPj4KZW5kb2JqCjU3IDAgb2Jq
Cls1NiAwIFIgL1hZWiAwIDczNS4zIG51bGxdCmVuZG9iago1OCAwIG9iagpbNTYgMCBSIC9YWVog
MCA2MTguNDQgbnVsbF0KZW5kb2JqCjU5IDAgb2JqCls1NiAwIFIgL1hZWiAwIDQwMS45IG51bGxd
CmVuZG9iago2MCAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgov
UyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cuYm9vc3Qub3JnL2RvYy9saWJzLzFfNDRfMC9kb2MvaHRt
bC9ib29zdC9pbnRlcnByb2Nlc3MvZmlsZV9sb2NrLmh0bWwpCj4+Ci9TdWJ0eXBlIC9MaW5rCi9S
ZWN0IFs0OC4yNCAyOTkuNDUgNDQzLjY4MjMgMzEzLjczXQovVHlwZSAvQW5ub3QKPj4KZW5kb2Jq
CjYxIDAgb2JqCls1NiAwIFIgL1hZWiAwIDI4Ni43IG51bGxdCmVuZG9iago2MiAwIG9iago8PCAv
Qm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8v
d3d3Lmdvb2dsZS5jby51ay9zZWFyY2g/cT1mc3RyZWFtK2FuZCtmaWxlK2Rlc2NyaXB0b3IpCj4+
Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0OC4yNCAyMDAuMDMgMzY5LjU2MjggMjE0LjMxXQovVHlw
ZSAvQW5ub3QKPj4KZW5kb2JqCjYzIDAgb2JqCjw8IC9Cb3JkZXIgWzAgMCAwXQovQSA8PCAvVHlw
ZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cHM6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlv
bnMvMjc0NjE2OC9ob3ctdG8tY29uc3RydWN0LWEtYy1mc3RyZWFtLWZyb20tYS1wb3NpeC1maWxl
LWRlc2NyaXB0b3IpCj4+Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDYuMzg0OSAxNzIuMjUgNTQ3
LjA0IDE4Ni41M10KL1R5cGUgL0Fubm90Cj4+CmVuZG9iago2NCAwIG9iago8PCAvQm9yZGVyIFsw
IDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vc3RhY2tvdmVy
Zmxvdy5jb20vcXVlc3Rpb25zLzI3NDYxNjgvaG93LXRvLWNvbnN0cnVjdC1hLWMtZnN0cmVhbS1m
cm9tLWEtcG9zaXgtZmlsZS1kZXNjcmlwdG9yKQo+PgovU3VidHlwZSAvTGluawovUmVjdCBbNDgu
MjQgMTU2LjQ3IDExOC45Nzg1IDE3MC43NV0KL1R5cGUgL0Fubm90Cj4+CmVuZG9iago2NSAwIG9i
agpbNTYgMCBSIC9YWVogMCAxMTUuOTQgbnVsbF0KZW5kb2JqCjY2IDAgb2JqCjw8IC9MZW5ndGgg
OTgyNwo+PgpzdHJlYW0KcQovRGV2aWNlUkdCIGNzCjAuMiAwLjIgMC4yIHNjbgovRGV2aWNlUkdC
IENTCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNzg2LjY2NiBUZAovRjIuMCAxOCBUZgo8NDg2
Zjc3MjA3NDZmMjA3MjY1NzA3MjY1NzM2NTZlNzQyMDYxMjA2ZTYxNzQ2OTc2NjUyMDY2Njk2YzY1
MjA2NDY1NzM2MzcyNjk3MDc0NmY3Mj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNzU4LjY0NiBU
ZAovRjEuMCAxMC41IFRmCjw1MDZmNzM3MzY5NjI2YzY1MjA2ZjcwNzQ2OTZmNmU3MzIwNjEyMDc0
Njg2NTIwNmU2MTc0Njk3NjY1MjA2NjY5NmM2NTIwNjQ2NTczNjM3MjY5NzA3NDZmNzIyMDcyNjU3
MDcyNjU3MzY1NmU3NDYxNzQ2OTZmNmUyMDYxNzI2NTNhPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NO
CjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NO
CgpCVAo1Ni44ODA1IDczMC44NjYgVGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNjYuMjQgNzMwLjg2NiBUZAovRjEuMCAxMC41IFRmCls8NjEyMDZlNjE2Yj4g
MjAuMDE5NSA8NjU2NDIwNjY2OTZjNjUyMDY0NjU3MzYzNzI2OTcwNzQ2ZjcyMmUyMDY5MmU2NTJl
MjA2MTZlMjA2OTZlNzQ2NTY3NjU3MjIwNmY2ZTIwNTA2ZjczNjk3OD5dIFRKCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4y
IDAuMiBTQ04KCkJUCjU2Ljg4MDUgNzA5LjA4NiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQK
CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24K
MC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCA3MDkuMDg2IFRkCi9GMS4wIDEwLjUgVGYKPDYxMjA0
NjQ5NGM0NTJhPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKLTAuNSBU
YwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1Ni44ODA1IDY4Ny4zMDYgVGQK
L0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
CgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNjYuMjQgNjg3LjMw
NiBUZAovRjEuMCAxMC41IFRmCls8NjEyMDczNzQ3Mjc1NjM3NDIwNzc3Mj4gMjAuMDE5NSA8NjE3
MDcwNjk2ZTY3MjA2MTIwNmU2MTZiPiAyMC4wMTk1IDw2NTY0MjA2NjY5NmM2NTIwNjQ2NTczNjM3
MjY5NzA3NDZmNzIyZT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjAuNjU2NCBUdwoKQlQKNDguMjQgNjU5LjUy
NiBUZAovRjEuMCAxMC41IFRmCls8NDEyMDZlNjE2Yj4gMjAuMDE5NSA8NjU2NDIwNjY2OTZjNjUy
MDY0NjU3MzYzNzI2OTcwNzQ2ZjcyMjA2ZjZlMjA1MDZmNzM2OTc4MjA2OTczMjA2YTc1NzM3NDIw
NjE2ZTIwNjk2ZTc0NjU2NzY1NzIyMDYxNmU2NDIwNzQ2ODY1NzI2NTY2NmY3MjY1MjA2MTIwNzY2
NTcyNzkyMDZjNjU2MTZiNzkyMDYxNjI3Mzc0NzI+IDIwLjAxOTUgPDYxNjM3NDY5NmY2ZTJlMjA0
OTc0MjA3MzY4NmY3NTZjNjQ+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAu
MCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDY0My43
NDYgVGQKL0YxLjAgMTAuNSBUZgpbPDc0Njg3NTczMjA2MjY1MjA3MjY1NzA2YzYxNjM2NTY0MjA2
Mj4gMjAuMDE5NSA8NzkyMDYxMjA2YzY1NzM3MzIwNmM2NTYxNmI3OTIwNjE2MjczNzQ3Mj4gMjAu
MDE5NSA8NjE2Mzc0Njk2ZjZlMjA2OTZlMjA2MTIwNjg2OTY3Njg2NTcyMjA2YzY1NzY2NTZjMjA0
MTUwNDkyZT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIg
MC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjAuMjY3IFR3CgpCVAo0OC4yNCA2MTUuOTY2IFRkCi9G
MS4wIDEwLjUgVGYKWzw0MTIwNDY0OTRjNDUyYTIwNmQ2MTZlNjQ2MTc0NjU3MzIwNzM3NDY0Njk2
ZjIwNjI3NTY2NjY2NTcyNjk2ZTY3MjA3NzY4Njk2MzY4MjA2OTczMjA2YzY5NmI+IDIwLjAxOTUg
PDY1NmM3OTIwNmU2Zjc0MjA2NTcxNzU2OTc2NjE2YzY1NmU3NDIwNzQ2ZjIwNmU2MTc0Njk3NjY1
MjA0OTRmMmUyMDU0Njg2OTczMjA2OTczMjA3NDY4NjU3MjY1NjY2ZjcyNjUyMDcyNzU2YzY1NjQ+
XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIg
MC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDYwMC4xODYgVGQKL0YxLjAgMTAuNSBU
Zgo8NmY3NTc0MmU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjIuOTg0OCBUdwoKQlQKNDguMjQgNTcyLjQwNiBU
ZAovRjEuMCAxMC41IFRmCjw1NDY4NjUyMDI3NjY2OTZjNjU1ZjY0NjU3MzYzNzI2OTcwNzQ2Zjcy
MjcyMDczNjg2Zjc1NmM2NDIwNzQ2ODY1NzI2NTY2NmY3MjY1MjA2MjY1MjA2MTIwNzM3NDcyNzU2
Mzc0MjA3NzY4Njk2MzY4MjA2OTczMjA2ZjcwNjE3MTc1NjUyMDc0NmYyMDc0Njg2NTIwNzM3NDYx
NmU2NDYxNzI2NDIwNjI3NTc0MjA2MTZjNmM2Zjc3NzM+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
QlQKNDguMjQgNTU2LjYyNiBUZAovRjEuMCAxMC41IFRmCjw2OTZkNzA2YzY1NmQ2NTZlNzQ2MTc0
Njk2ZjZlMjA2NDY1NjY2OTZlNjU2NDIwNjE2MzYzNjU3MzczMjA3NDZmMjA3NDY4NjUyMDZjNmY3
NzIwNmM2NTc2NjU2YzIwNzI2NTcwNzI2NTczNjU2ZTc0NjE3NDY5NmY2ZTJlPiBUagpFVAoKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgoxLjA2OTMgVHcKCkJUCjQ4LjI0IDUyOC44NDYgVGQKL0YxLjAgMTAuNSBUZgo8NDk2ZTIw
NmY3MjY0NjU3MjIwNzQ2ZjIwNzM2ZjZjNzY2NTIwNzQ2ODY1MjA2ZjcyNjk2NzY5NmU2MTZjMjA3
NTczNjUyMDYzNjE3MzY1MmMyMDc0Njg2MTc0MjA2ZjY2MjA2MjY1Njk2ZTY3MjA2MTYyNmM2NTIw
NzQ2ZjIwNjM2MTZjNmMyMDY2NjM2ZTc0NmMyODI5MjA2ZjZlMjA1MDZmNzM2OTc4MmMyMDY5NzQy
MDY5NzMyMDZlNjU2MzY1NzM3MzYxNzI3OTIwNzQ2Zj4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAw
LjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgox
LjUwMDYgVHcKCkJUCjQ4LjI0IDUxMy4wNjYgVGQKL0YxLjAgMTAuNSBUZgo8NjQ2NTY2Njk2ZTY1
MjA2ODZmNzcyMDc0NmYyMDZmNjI3NDYxNjk2ZTIwNjE2ZTIwNDY0NDJlMjA1NzY5NzQ2ODZmNzU3
NDIwNzQ2ODY5NzMyMDY1NjE2MzY4MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2MTc0Njk2ZjZlMjA2ZjZl
MjA2MTIwNTA0ZjUzNDk1ODIwNjM2ZjZlNjY2ZjcyNmQ2OTZlNjcyMDcwNmM2MTc0NjY2ZjcyNmQ+
IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAw
LjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKNy43Mjg2IFR3CgpCVAo0OC4yNCA0OTcuMjg2IFRkCi9G
MS4wIDEwLjUgVGYKPDc3NmY3NTZjNjQyMDYyNjUyMDY2NzI2NTY1MjA3NDZmMjA2NDY1NjY2OTZl
NjUyMDY5NzQ3MzIwNmY3NzZlMjA2ZDY1NmQ2MjY1NzI3MzIwNjE2ZTY0MjA2NDY1NjY2OTZlNjk3
NDY5NmY2ZTczMjA2NjZmNzIyMDY0NmY2OTZlNjcyMDczNmYyMDcyNjU2ZTY0NjU3MjY5NmU2Nz4g
VGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAu
MiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA0ODEuNTA2IFRkCi9GMS4wIDEwLjUgVGYK
PDZlNjE3NDY5NzY2NTVmNjY2OTZjNjU1ZjY0NjU3MzYzNzI2OTcwNzQ2ZjcyMjA2ZTZmNmUyZDcw
NmY3Mjc0NjE2MjZjNjUyMDZmNmUyMDY1NzY2NTZlMjA1MDZmNzM2OTc4MjA3Mzc5NzM3NDY1NmQ3
MzJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBz
Y24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA0NDEuNjY2IFRkCi9GMi4wIDE4IFRmCjw0MzJi
MmIyMDYxNmU2NDIwNTA2ZjczNjk3OD4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC4zNzk0IFR3CgpCVAo0OC4y
NCA0MTMuNjQ2IFRkCi9GMS4wIDEwLjUgVGYKPDQ0NjU2NjY5NmU2OTZlNjcyMDYxMjA1MDZmNzM2
OTc4MjA2MjY5NmU2NDY5NmU2NzIwNjY2ZjcyMjA0MzIwNjk3MzIwNmY3NTc0MjA2ZjY2MjA3MzYz
NmY3MDY1MmUyMDUzNmY2ZDY1MjA2MjY1NmM2OTY1NzY2NTIwNzQ2ODY5NzMyMDY5NzMyMDYxMjA2
YTZmNjIyMDY2NmY3MjIwNTA0ZjUzNDk1ODIwNjE2ZTY0MjA3MzZmNmQ2NTIwNjY2ZjcyMjA3NDY4
NjU+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC43MzQzIFR3CgpCVAo0OC4yNCAzOTcuODY2IFRk
Ci9GMS4wIDEwLjUgVGYKPDQzMjA3Mzc0NjE2ZTY0NjE3MjY0MmUyMDQ5MjA2MjY1NmM2OTY1NzY2
NTIwNzQ2ODY5NzMyMDY5NzMyMDYxMjA2YTZmNjIyMDY2NmY3MjIwNzQ2ODY1MjA2OTZlNzQ2NTcy
NjU3Mzc0NjU2NDIwNmQ2NTZkNjI2NTcyNzMyMDZmNjYyMDc0Njg2NTIwNDMyYjJiMjA2MzZmNmQ2
ZDY5NzQ3NDY1NjUyMDYyNjU2MzYxNzU3MzY1MjA3Mzc1NjM2ODIwNjE+IFRqCkVUCgoKMC4wIFR3
CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNDguMjQgMzgyLjA4NiBUZAovRjEuMCAxMC41IFRmCls8NjI2OTZlNjQ2OTZl
NjcyMDczNjg2Zjc1NmM2NDIwNjI2NTIwNjI3NTY5NmM3NDIwNmY2ZTIwNzQ2ZjcwMjA2ZjY2MjA3
NDY4NjUyMDUwNmY3MzY5NzgyMDQzMjA2MjY5NmU2NDY5NmU2NzczMjA2MTczMjA2MTIwNzA3NTcy
NjUyMDZjNjk2MjcyPiAyMC4wMTk1IDw2MTcyNzkyMDY1Nzg3NDY1NmU3MzY5NmY2ZTJlPl0gVEoK
RVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAw
LjIgMC4yIFNDTgoKMC40MzYzIFR3CgpCVAo0OC4yNCAzNTQuMzA2IFRkCi9GMS4wIDEwLjUgVGYK
Wzw1NDY4NjUyMDcwNzI2NTY2NjU3MjY1NmU2MzY1MjA2OTZlMjA0MzJiMmIyMDczNzQ2MTZlNjQ2
MTcyNjQ2OTczNjE3NDY5NmY2ZTIwNjk3MzIwNzI2OTY3Njg3NDZjNzkyMDc0NmYyMDczNzQ2MTZl
NjQ2MTcyNjQ2OTczNjUyMDc0Njg2NTIwNjY3NTZlNjM3NDY5NmY2ZTYxNmM2OTc0NzkyMDcyPiAy
MC4wMTk1IDw2MTc0Njg2NTcyMjA3NDY4NjE2ZTIwNzQ2ODY1MjA0ZjUzPl0gVEoKRVQKCgowLjAg
VHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgowLjkzMzYgVHcKCkJUCjQ4LjI0IDMzOC41MjYgVGQKL0YxLjAgMTAuNSBUZgpb
PDYyNjk2ZTY0Njk2ZTY3MmUyMDQ2PiA0MC4wMzkxIDw2ZjcyMjA2NTc4NjE2ZDcwNmM2NTIwNzQ2
ODY1MjA2NjY5NmM2NTczNzk3Mzc0NjU2ZDIwNTQ1MzIwNzM3NDYxNmU2NDYxNzI2NDY5NzM2NTcz
MjA2MTYzNjM2NTczNzMyMDc0NmYyMDY2Njk2YzY1MmQ3Mzc5NzM3NDY1NmQ3MzIwNjE2ZTY0MjA3
NzZmNzU2YzY0MjA2MjY1MjA3NzcyNmY2ZTY3MjA3NDZmPl0gVEoKRVQKCgowLjAgVHcKMC4wIDAu
MCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NO
CgpCVAo0OC4yNCAzMjIuNzQ2IFRkCi9GMS4wIDEwLjUgVGYKPDcyNjU3MTc1Njk3MjY1MjA2MTIw
NTA2ZjczNjk3ODIwNjI2OTZlNjQ2OTZlNjcyMDY1MmU2NzJlMjA2ZjcwNjU2ZTY0Njk3MjI4Mjky
MDY5NmUyMDY5NzQ3MzIwNjk2ZTc0NjU3MjY2NjE2MzY1MmU+IFRqCkVUCgowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjAuMzQ3
NyBUdwoKQlQKNDguMjQgMjk0Ljk2NiBUZAovRjEuMCAxMC41IFRmCjw1MzY5NmQ2OTZjNjE3MjZj
NzkyMDY5NzQyMDYzNjE2ZTIwNjI2NTIwNjE3MjY3NzU2NTY0MjA3NDY4NjE3NDIwNjY2OTZjNjUy
MDZjNmY2MzZiNjk2ZTY3MjA2ZDc1NzM3NDIwNjI2NTIwNjk2ZDcwNmM2NTZkNjU2ZTc0NjU2NDIw
Nzc2OTc0Njg2Zjc1NzQyMDY0Njk3MjY1NjM3NDIwNzI2NTY2NjU3MjY1NmU2MzY1MjA3NDZmMjA2
NjYzNmU3NDZjMjgyOTJjPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAw
LjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjMuMTIyNSBUdwoKQlQKNDgu
MjQgMjc5LjE4NiBUZAovRjEuMCAxMC41IFRmCjw3NDY4NjU3MjY1NjY2ZjcyNjUyMDY1Nzg3MDZm
NzM2OTZlNjcyMDYxNmUyMDQ2NDQyMDczNmYyMDc0Njg2MTc0MjA2NjYzNmU3NDZjMjgyOTIwNjM2
MTZlMjA2MjY1MjA3NTczNjU2NDIwNzQ2ZjIwNjk2ZDcwNmM2NTZkNjU2ZTc0MjA2NjY5NmM2NTIw
NmM2ZjYzNmI2OTZlNjcyMDY5NzMyMDcwNmY3NDY1NmU3NDY5NjE2YzZjNzk+IFRqCkVUCgoKMC4w
IFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAw
LjIgMC4yIFNDTgoKQlQKNDguMjQgMjYzLjQwNiBUZAovRjEuMCAxMC41IFRmCjw2ZDY5NzM3MDZj
NjE2MzY1NjQyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC45NDQ4IFR3CgpCVAo0OC4yNCAyMzUuNjI2IFRk
Ci9GMS4wIDEwLjUgVGYKPDU0Njg2NTIwNDMyYjJiMjA3Mzc0NjE2ZTY0NjE3MjY0MjA3MzY4NmY3
NTZjNjQyMDY5NmU3Mzc0NjU2MTY0MjA2MTY5NmQyMDc0NmYyMDczNzQ2MTZlNjQ2MTcyNjQ2OTcz
NjUyMDYxNmUyMDY5NmU3NDY1NzI2NjYxNjM2NTIwNjY2ZjcyMjA2YzZmNjM2YjY5NmU2NzIwNjY2
OTZjNjU3MzJlMjA1NDY4Njk3MzIwNmQ2OTY3Njg3NDIwNjI2NTIwNjE+IFRqCkVUCgoKMC4wIFR3
CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKMi40NjE0IFR3CgpCVAo0OC4yNCAyMTkuODQ2IFRkCi9GMS4wIDEwLjUgVGYKPDcz
NzQ2MTZlNjQ2MTZjNmY2ZTY1MjA2OTZlNzQ2NTcyNjY2MTYzNjUyMDI4NjkyZTY1MmUyMDZlNmY3
NDIwNzU3MzY5NmU2NzIwNjk2ZjczNzQ3MjY1NjE2ZDI5MjA2MTczMjA2OTczMjA3MDcyNmY3NjY5
NjQ2NTY0MjA2OTZlMjA0MTQ2NDk0ZjIwNmY3MjIwNjk3NDIwNjM2Zjc1NmM2NDIwNjI2NTIwNjI3
NTY5NmM3NDIwNzU3MDZmNmU+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4w
IDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMjA0LjA2
NiBUZAovRjEuMCAxMC41IFRmCjw2OTZmNzM3NDcyNjU2MTZkNzMyMDY2NmY3MjIwNjU3ODYxNmQ3
MDZjNjUyMDY2NzM3NDcyNjU2MTZkMmU2YzZmNjM2YjI4MjkyMDZmNzIyMDY2NzM3NDcyNjU2MTZk
MjAzYzNjMjA2YzZmNjM2YjI4MjkyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMS40OTYxIFR3CgpCVAo0OC4y
NCAxNzYuMjg2IFRkCi9GMS4wIDEwLjUgVGYKPDU3Njg2OTZjNjUyMDc0Njg2OTczMjA2OTczMjA3
NDcyNzU2NTIwNzQ2ZjIwNjU2YzY5NmQ2OTZlNjE3NDY1MjA3NDY4NjUyMDZlNjE3NDY5NzY2NTVm
NjY2OTZjNjU1ZjY0NjU3MzYzNzI2OTcwNzQ2ZjcyMjA3NTczNjUyMDYzNjE3MzY1MjA2NTZlNzQ2
OTcyNjU2Yzc5MjA3NzZmNzU2YzY0MjA3MjY1NzE3NTY5NzI2NTIwNzQ2ODY1MjA0MzJiMmI+IFRq
CkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKMC45OTY3IFR3CgpCVAo0OC4yNCAxNjAuNTA2IFRkCi9GMS4w
IDEwLjUgVGYKPDczNzQ2MTZlNjQ2MTcyNjQyMDc0NmYyMDczNzU3MDcwNmY3Mjc0MjA2NTc2NjU3
Mjc5NzQ2ODY5NmU2NzIwNzQ2ODYxNzQyMDY5NzMyMDYzNzU3MjcyNjU2ZTc0NmM3OTIwNjQ2ZjZl
NjUyMDY5NmUyMDUwNmY3MzY5NzgyMDc1NzM2OTZlNjcyMDY2NjM2ZTc0NmMyODI5MmUyMDQ5NzQy
MDZkNjk2NzY4NzQyMDY1NzY2NTZlMjA2ZTY1NjU2NDIwNzQ2Zj4gVGoKRVQKCgowLjAgVHcKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgpCVAo0OC4yNCAxNDQuNzI2IFRkCi9GMS4wIDEwLjUgVGYKWzw2MzZmNmU3MzY5NjQ2NTcy
MjA2MzYxNzM2NTczMjA2MzZmNzY2NTcyNjU2NDIwNjI+IDIwLjAxOTUgPDc5MjA3NDY4NjUyMDY5
NmY2Mzc0NmMyODI5MjA3Mzc5NzM3NDY1NmQyMDYzNjE2YzZjMjA3NzY4Njk2MzY4MjA3MDcyNjU2
NDYxNzQ2NTIwNjk3NDJlPl0gVEoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
MC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMS4xOTgyIFR3CgpCVAo0OC4yNCAxMTYu
OTQ2IFRkCi9GMS4wIDEwLjUgVGYKPDRkNzkyMDc2Njk2NTc3MjA2OTczMjA3NDY4NjE3NDIwNGY1
MzIwNjI2OTZlNjQ2OTZlNjc3MzIwNjE3MjY1MjA2ZjcyNzQ2ODZmNjc2ZjZlNjE2YzJlMjA1NDY4
NjU3OTIwNzA3MjZmNzY2OTY0NjUyMDYxMjA2NjZmNzU2ZTY0NjE3NDY5NmY2ZTIwNzU3MDZmNmUy
MDc3Njg2OTYzNjgyMDc0Njg2NTczNjUyMDY4Njk2NzY4NjU3Mj4gVGoKRVQKCgowLjAgVHcKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgoyLjY0NzIgVHcKCkJUCjQ4LjI0IDEwMS4xNjYgVGQKL0YxLjAgMTAuNSBUZgpbPDZjNjU3
NjY1NmMyMDczNjU3Mjc2Njk2MzY1NzMyMDZkNjE+IDIwLjAxOTUgPDc5MjA2MjY1MjA2Mjc1Njk2
Yzc0MmUyMDU0Njg2NTc5MjA2MTZjNzM2ZjIwNjM2ZjZlNzQ2OTZlNzU2NTIwNzQ2ODY1MjA0MzJi
MmIyMDc0NzI+IDIwLjAxOTUgPDYxNjQ2OTc0Njk2ZjZlMjA2ZjY2MjA2MjY1Njk2ZTY3MjA2MTYy
NmM2NTIwNzQ2ZjIwNjE3MzYzNjU2ZTY0MjA2MTZlNjQ+XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CkJUCjQ4LjI0IDg1LjM4NiBUZAovRjEuMCAxMC41IFRmCls8NjQ2NTczNjM2NTZlNjQyMDc0Njg2
NTIwNmM2NTc2NjU2YzIwNmY2NjIwNjE2MjczNzQ3Mj4gMjAuMDE5NSA8NjE2Mzc0Njk2ZjZlMjA2
MTczMjA2MTcwNzA3MjZmNzA3MjY5NjE3NDY1MjA3NDZmMjA3NDY4NjUyMDcwNzI2ZjY3NzI+IDIw
LjAxOTUgPDYxNmQ2ZDY5NmU2NzIwNzQ2MTczNmIyMDcyNjU3MTc1Njk3MjY1NjQyZT5dIFRKCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCnEKMC4wIDAuMCAwLjAgc2NuCjAuMCAw
LjAgMC4wIFNDTgoxIHcKMCBKCjAgagpbXSAwIGQKL1N0YW1wMiBEbwowLjIgMC4yIDAuMiBzY24K
MC4yIDAuMiAwLjIgU0NOCgpCVAo0OS4yNCAxNC4zODggVGQKL0YxLjAgOSBUZgo8Mzg+IFRqCkVU
CgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuClEKUQoKZW5kc3RyZWFtCmVuZG9iago2
NyAwIG9iago8PCAvVHlwZSAvUGFnZQovUGFyZW50IDMgMCBSCi9NZWRpYUJveCBbMCAwIDU5NS4y
OCA4NDEuODldCi9Dcm9wQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0JsZWVkQm94IFswIDAgNTk1
LjI4IDg0MS44OV0KL1RyaW1Cb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQXJ0Qm94IFswIDAgNTk1
LjI4IDg0MS44OV0KL0NvbnRlbnRzIDY2IDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERG
IC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXQovRm9udCA8PCAvRjIuMCAxNSAwIFIKL0Yx
LjAgOCAwIFIKPj4KL1hPYmplY3QgPDwgL1N0YW1wMiA5MyAwIFIKPj4KPj4KPj4KZW5kb2JqCjY4
IDAgb2JqCls2NyAwIFIgL1hZWiAwIDg0MS44OSBudWxsXQplbmRvYmoKNjkgMCBvYmoKPDwgL0xp
bWl0cyBbKF9fYW5jaG9yLXRvcCkgKF9pbXBsZW1lbnRhdGlvbildCi9OYW1lcyBbKF9fYW5jaG9y
LXRvcCkgMTEgMCBSIChfYWx0ZXJuYXRpdmVzX3RvX3RoaXNfcHJvcG9zYWwpIDU3IDAgUiAoX2Fw
YWNoZV9zdGRjeHgpIDgyIDAgUiAoX2JldHRlcl9zb2x1dGlvbikgMjUgMCBSIChfY19hbmRfcG9z
aXgpIDcxIDAgUiAoX2Nfc3RkaW9fZnVuY3Rpb25zX2Jhc2VkX29uX2ZpbGUpIDIxIDAgUiAoX2Ns
YW5nX2xpYmN4eCkgODYgMCBSIChfY3VycmVudF9zb2x1dGlvbnMpIDI0IDAgUiAoX2RlZmluaXRp
b25zKSAxNCAwIFIgKF9kaXNjdXNzaW9ucykgNjUgMCBSIChfZG9fbm90aGluZykgNjEgMCBSIChf
Z251X2xpYnN0ZGNfMykgODMgMCBSIChfaGlzdG9yeSkgNzUgMCBSIChfaG93X3RvX3JlcHJlc2Vu
dF9hX25hdGl2ZV9maWxlX2Rlc2NyaXB0b3IpIDY4IDAgUiAoX2ltcGxlbWVudGF0aW9uKSA0OSAw
IFJdCj4+CmVuZG9iago3MCAwIG9iago8PCAvTGltaXRzIFsoX2ltcGxlbWVudGF0aW9uX29mX3N0
ZF9maWxlYnVmKSAoX3Zpc3VhbF9jKV0KL05hbWVzIFsoX2ltcGxlbWVudGF0aW9uX29mX3N0ZF9m
aWxlYnVmKSA3NCAwIFIgKF9pbXBsaWNhdGlvbnNfZm9yX3RoZV9kZWZpbml0aW9uX29mX2FfZmls
ZV9zdHJlYW0pIDU0IDAgUiAoX2xpbmtfYmV0d2Vlbl9yZXF1aXJlbWVudHNfZm9yX2ZpbGVfYW5k
X25hdGl2ZV9maWxlX2hhbmRsZXMpIDI2IDAgUiAoX21vdGl2YXRpb24pIDE3IDAgUiAoX25hdGl2
ZV9maWxlX2Rlc2NyaXB0b3JzKSAxOCAwIFIgKF9vcGVuX3dhdGNvbV92MikgODcgMCBSIChfcHJv
YmxlbXNfdG9fYmVfYWRkcmVzc2VkX2JlZm9yZV90aGlzX2Nhbl9iZV9tYWRlX2ludG9fYV9wcm9w
b3NhbF90b19pc28pIDUwIDAgUiAoX3Byb3Bvc2FsKSAzOCAwIFIgKF9wcm92aWRlX2hpZ2hlcl9s
ZXZlbF9pbnRlcmZhY2VzX2luc3RlYWQpIDU5IDAgUiAoX3JlbGF0aW9uX3RvX3ByZXZpb3VzX3By
b3Bvc2FscykgMjkgMCBSIChfc3RhbmRhcmRpc2luZ19ub25fc3RhbmRhcmRfZXh0ZW5zaW9ucykg
NTggMCBSIChfc3RkX25hdGl2ZV9maWxlX2Rlc2NyaXB0b3IpIDM5IDAgUiAoX3N0ZF9zdGRpb19m
aWxlYnVmKSA0OCAwIFIgKF9zdXJ2ZXlfb2ZfZXhpc3RpbmdfZmlsZWJ1Zl9pbXBsZW1lbnRhdGlv
bnMpIDc5IDAgUiAoX3Zpc3VhbF9jKSA4OCAwIFJdCj4+CmVuZG9iago3MSAwIG9iagpbNjcgMCBS
IC9YWVogMCA0NjUuNjkgbnVsbF0KZW5kb2JqCjcyIDAgb2JqCjw8IC9MZW5ndGggODgzNwo+Pgpz
dHJlYW0KcQovRGV2aWNlUkdCIGNzCjAuMiAwLjIgMC4yIHNjbgovRGV2aWNlUkdCIENTCjAuMiAw
LjIgMC4yIFNDTgoKQlQKNDguMjQgNzg2LjY2NiBUZAovRjIuMCAxOCBUZgo8NDk2ZDcwNmM2NTZk
NjU2ZTc0NjE3NDY5NmY2ZTIwNmY2NjIwNzM3NDY0M2EzYTY2Njk2YzY1NjI3NTY2PiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAw
LjIgU0NOCgowLjYwNiBUdwoKQlQKNDguMjQgNzU4LjY0NiBUZAovRjEuMCAxMC41IFRmCjw0OTIw
NjE3MjY3NzU2NTIwNzQ2ODYxNzQyMDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3MzIwNzQ3
OTcwNjk2MzYxNmM2Yzc5MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2NTY0MjA2MTczMjA2MTIwNmU2MTc0
Njk3NjY1NWY2NjY5NmM2NTYyNzU2NjIwNmY3MjIwMjg3MDY1NzI2ODYxNzA3MzIwNmQ2ZjcyNjUy
MDZlNjE2OTc2NjU2Yzc5MjkyMDYxNzMyMDYxPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBT
Q04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjIuOTI0
NCBUdwoKQlQKNDguMjQgNzQyLjg2NiBUZAovRjEuMCAxMC41IFRmCjw3Mzc0NjQ2OTZmNWY2NjY5
NmM2NTYyNzU2NjJlMjA0OTY2MjA3NDY4Njk3MzIwNjk3MzIwNzQ2ODY1MjA2MzYxNzM2NTIwNzQ2
ODY1NmUyMDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjM2Zjc1NmM2NDIwNjI2NTIwNjEyMDc0
Nzk3MDY1NjQ2NTY2MjA2NjZmNzIyMDY1Njk3NDY4NjU3MjIwNzM3NDY0Njk2ZjVmNjY2OTZjNjU2
Mjc1NjYyMDZmNzI+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMC4wMDYzIFR3CgpCVAo0OC4yNCA3
MjcuMDg2IFRkCi9GMS4wIDEwLjUgVGYKPDZlNjE3NDY5NzY2NTVmNjY2OTZjNjU2Mjc1NjYyMDQ5
NmUyMDc0Njg2NTIwNjM2MTczNjUyMDZmNjYyMDUwNmY3MzY5NzgyMDY3Njk3NjY1NmUyMDY2Njk2
YzY1NmU2ZjI4MjkyMDYxNmU2NDIwNjY2NDZmNzA2NTZlMjgyOTIwNjk3MzIwNjk3MzIwNjE2Yzcz
NmYyMDcwNmY3MzczNjk2MjZjNjUyMDc0Njg2MTc0MjA3NDY4NjUyMDczNjE2ZDY1MjA2MzZjNjE3
MzczMjA2OTczPiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2Nu
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDcxMS4zMDYgVGQKL0Yx
LjAgMTAuNSBUZgo8NjE2YzZjMjA3NDY4NzI2NTY1MjA2ZjY2MjA3Mzc0NjQzYTNhNzM3NDY0Njk2
ZjVmNjY2OTZjNjU2Mjc1NjYyMDczNzQ2NDNhM2E2ZTYxNzQ2OTc2NjU2NjY5NmM2NTYyNzU2NjIw
NjE2ZTY0MjA3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKNC4yNjU5
IFR3CgpCVAo0OC4yNCA2ODMuNTI2IFRkCi9GMS4wIDEwLjUgVGYKPDQ5MjA2ODYxNzY2NTIwNzQ2
ODc1NzMyMDZjNjU2Njc0MjA2OTc0MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2MTc0Njk2ZjZlMjA2NDY1
NjY2OTZlNjU2NDIwNzc2ODY1NzQ2ODY1NzIyMDczNzQ2NDNhM2E3Mzc0NjQ2OTZmNWY2NjY5NmM2
NTYyNzU2NjJjMjA3Mzc0NjQzYTNhNmU2MTc0Njk3NjY1NWY2NjY5NmM2NTYyNzU2NjIwNjE2ZTY0
PiBUagpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIg
MC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCjIuODA3MyBUdwoKQlQKNDguMjQgNjY3Ljc0NiBUZAov
RjEuMCAxMC41IFRmCjw3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDYxNzI2NTIwNjQ2OTY2NjY2
NTcyNjU2ZTc0MjA3NDc5NzA2NTczMmUyMDUzNmY2ZDY1MjA2MzZmNzU2YzY0MjA2MjY1MjA3NDc5
NzA2NTY0NjU2NjczMjA2ZjY2MjA2Zjc0Njg2NTcyNzMyMDcwNzI2Zjc2Njk2NDY1NjQyMDc0Njg2
MTc0MjA3NDY4NjUyMDYxNjQ2NDY5NzQ2OTZmNmU2MTZjPiBUagpFVAoKCjAuMCBUdwowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CkJUCjQ4LjI0IDY1MS45NjYgVGQKL0YxLjAgMTAuNSBUZgo8Njk2ZTc0NjU3MjY2NjE2MzY1NzMy
MDZmNjYyMDczNzQ2NDY5NmY1ZjY2Njk2YzY1NjI3NTY2MjA2MTZlNjQyMDZlNjE3NDY5NzY2NTVm
NjY2OTZjNjU2Mjc1NjYyMDYxNzI2NTIwNzA3MjZmNzY2OTY0NjU2NDJlPiBUagpFVAoKMC4wIDAu
MCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NO
CgowLjIwMzMgVHcKCkJUCjQ4LjI0IDYyNC4xODYgVGQKL0YxLjAgMTAuNSBUZgpbPDUzNmY2ZDY1
MjA2ODYxNzY2NTIwNjE3MjY3NzU2NTY0MjA3NDY4NjE3NDIwNzQ2ODY1NzkyMDRkNTU1Mz4gMjAu
MDE5NSA8NTQyMDYyNjUyMDY0Njk2NjY2NjU3MjY1NmU3NDIwNzQ3OTcwNjU3MzJlMjA1MDcyNjU3
Mzc1NmQ2MTYyNmM3OTIwNzQ2ODY5NzMyMDY5NzMyMDY1Njk3NDY4NjU3MjIwNzM2ZjIwNzQ2ODYx
NzQyMDczNzQ2NDNhM2E2NjY5NmM2NTYyNzU2NjIwNjk3Mz5dIFRKCkVUCgoKMC4wIFR3CjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKMC41NDM3IFR3CgpCVAo0OC4yNCA2MDguNDA2IFRkCi9GMS4wIDEwLjUgVGYKWzw2MTIwNmM2
NTczNzMyMDZjNjU2MTZiNzkyMDYxNjI3Mzc0NzI+IDIwLjAxOTUgPDYxNjM3NDY5NmY2ZTIwNjE2
ZTY0MmY2ZjcyMjA3MzZmMjA3NDY4NjE3NDIwNzQ2ODY1MjA3Mzc0NjE2ZTY0NjE3MjY0MjA2ZDYx
NmU2NDYxNzQ2NTczMjA3NDY4NjUyMDYzNmY2ZDcwNmM2NTc0NjUyMDY5NmU3NDY1NzI2NjYxNjM2
NTIwNjY2ZjcyMjA2NTYxNjM2ODIwNjM2YzYxNzM3Mz5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoK
QlQKNDguMjQgNTkyLjYyNiBUZAovRjEuMCAxMC41IFRmCjw2MTZlNjQyMDY0NmY2NTczMjA2ZTZm
NzQyMDcwNjU3MjZkNjk3NDIwNjk2ZDcwNmM2NTZkNjU2ZTc0NjE3NDY5NmY2ZTIwNjQ2NTY2Njk2
ZTY1NjQyMDY1Nzg3NDY1NmU3MzY5NmY2ZTczMmU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4w
IDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDU2
NC44NDYgVGQKL0YxLjAgMTAuNSBUZgo8NDkyMDYyNjU2YzY5NjU3NjY1MjA2ZDZmNzI2NTIwNjE3
MjY3NzU2ZDY1NmU3NDczMjA3NzZmNzU2YzY0MjA2MjY1MjA3MjY1NzE3NTY5NzI2NTY0MjA3NDZm
MjA2YTc1NzM3NDY5NjY3OTIwNjE2NDY0Njk2ZTY3MjA3NDY4Njk3MzIwNzI2NTczNzQ3MjY5NjM3
NDY5NmY2ZTJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4y
IDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA1MjAuNzM0IFRkCi9GMi4wIDIyIFRm
Cjw0ODY5NzM3NDZmNzI3OT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
MC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKOC40OTgyIFR3CgpCVAo0OC4yNCA0OTEu
NTQ2IFRkCi9GMS4wIDEwLjUgVGYKWzw0Nj4gNDAuMDM5MSA8NmY3MjIwNzM2ZjZkNjUyMDcyNjU2
MTczNmY2ZTIwNDkyMDY2NjU2Yzc0MjA2MzZmNmQ3MDY1NmM2YzY1NjQyMDc0NmYyMDYxNmU3Mzc3
NjU3MjIwNjE2ZTIwNmY2YzY0MjA3MTc1NjU3Mzc0Njk2ZjZlMjA2ZjZlMjA3Mzc0NjE2MzZiMjA2
Zjc2NjU3MjY2NmM2Zjc3PiA2OS44MjQyIDwyZT5dIFRKCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4w
IFNDTgowLjAgMC4wIDAuMCBzY24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgc2NuCjAuMjU4OCAwLjU0
NTEgMC43OTIyIFNDTgoKQlQKNDguMjQgNDc1Ljc2NiBUZAovRjEuMCAxMC41IFRmCls8Njg3NDc0
NzA3MzNhMmYyZjczNzQ2MTYzNmI+IDIwLjAxOTUgPDZmNzY2NTcyNjY2YzZmNzc+IDY5LjgyNDIg
PDJlNjM2ZjZkMmY3MTc1NjU3Mzc0Njk2ZjZlNzMyZjM4MzYzNjM3MzUzODMxMmY2NjZjNmY2MzZi
MmQ2OTZlNjcyZDYxMmQ2MzJkNjk2NjczNzQ3MjY1NjE2ZDJkNmY2ZTJkNmM2OTZlNzU3ODJkNjc2
MzYzMmQzNDJkMzYyZjM0MzUzNTMyMzUzMDMyMzgyMz5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIHNjbgowLjI1ODggMC41NDUxIDAu
NzkyMiBTQ04KCkJUCjQ4LjI0IDQ1OS45ODYgVGQKL0YxLjAgMTAuNSBUZgo8MzQzNTM1MzIzNTMw
MzIzOD4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKMC42Njk4IFR3CgpCVAo0OC4yNCA0MzIuMjA2IFRkCi9GMS4w
IDEwLjUgVGYKWzw0MjY1NjM2MTc1NzM2NTIwNDkyMDY4NjE3NjY1MjA3MzY1NjU2ZTIwNzQ2ODY5
NzMyMDY0Njk3MzYzNzU3MzczNjU2NDIwNzM2NTc2NjU3Mj4gMjAuMDE5NSA8NjE2YzIwNzQ2OTZk
NjU3MzIwNDkyMDY4NjE2NDIwNjE3MzczNzU2ZDY1NjQyMDc0Njg2NTcyNjUyMDc3NjE3MzIwNjEy
MDcwNzI2ZjcwNmY3MzYxNmMyMDYxNmM3MjY1NjE2NDc5PiA4OS44NDM4IDwyZTIwNTQ2ODY5NzM+
XSBUSgpFVAoKCjAuMCBUdwowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIg
MC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDQxNi40MjYgVGQKL0YxLjAgMTAuNSBU
Zgo8NzI2NTczNzU2Yzc0NjU2NDIwNjk2ZTIwNzQ2ODY5NzMyMDY0Njk3MzYzNzU3MzczNjk2ZjZl
MjA3NzY4NjU2ZTIwNDkyMDY2NmY3NTZlNjQyMDZlNmY2ZTY1MmU+IFRqCkVUCgowLjAgMC4wIDAu
MCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIHNjbgowLjI1ODggMC41
NDUxIDAuNzkyMiBTQ04KCkJUCjQ4LjI0IDM4OC42NDYgVGQKL0YxLjAgMTAuNSBUZgo8Njg3NDc0
NzA3MzNhMmYyZjY3NzI2Zjc1NzA3MzJlNjc2ZjZmNjc2YzY1MmU2MzZmNmQyZjYxMmY2OTczNmY2
MzcwNzAyZTZmNzI2NzJmNjY2ZjcyNzU2ZDJmMjMyMTc0NmY3MDY5NjMyZjczNzQ2NDJkNzA3MjZm
NzA2ZjczNjE2YzczMmY1ODYzNTEzNDQ2NWE0YTRiNDQ2MjRkPiBUagpFVAoKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0
OC4yNCAzNjAuODY2IFRkCi9GMS4wIDEwLjUgVGYKPDU0Njg2NTIwNjk2ZTY5NzQ2OTYxNmMyMDcw
NzI2ZjcwNmY3MzYxNmMyMDYzNmY2ZTczNjk2NDY1NzI2NTY0MjA3Mzc0NjQ2OTZmNWY2NjY5NmM2
NTYyNzU2NjIwNjE3MzIwNmY3NTc0MjA2ZjY2MjA3MzYzNmY3MDY1MmU+IFRqCkVUCgowLjAgMC4w
IDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04K
CkJUCjQ4LjI0IDMzMy4wODYgVGQKL0YxLjAgMTAuNSBUZgo8NTQ2ODY1MjA2ODZmNzA2NTIwNzc2
MTczMjA3NDY4NjE3NDIwNzM3NDY0M2EzYTY2Njk2YzY1NjI3NTY2MjA2MzZmNzU2YzY0MjA2MjY1
MjA2NTc4NzQ2NTZlNjQ2NTY0MjA3Mzc1NjM2ODIwNzQ2ODYxNzQyMDczNzQ2NDNhM2E2NjY5NmM2
NTYyNzU2NjIwM2QzZDIwNmU2MTc0Njk3NjY1NWY2NjY5NmM2NTYyNzU2Nj4gVGoKRVQKCjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKMi40Nzg1IFR3CgpCVAo0OC4yNCAzMDUuMzA2IFRkCi9GMS4wIDEwLjUgVGYKPDQ4NmY3NzY1
NzY2NTcyMmMyMDc0Njg2NTIwNjE3MzczNzU2ZDcwNzQ2OTZmNmUyMDc0Njg2MTc0MjA3Mzc0NjQz
YTNhNjY2OTZjNjU2Mjc1NjYyMDZkNzU3Mzc0MjA2MjY1MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2NTY0
MjA2OTZlMjA3NDY1NzI2ZDczMjA2ZjY2MjA2MTZlMjA0NjQ0MjA2ZjZlMjA2MTIwNTA2ZjczNjk3
OD4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4y
IDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgoxLjg3MzcgVHcKCkJUCjQ4LjI0IDI4OS41MjYgVGQK
L0YxLjAgMTAuNSBUZgo8NjM2ZjZkNzA2YzY5NjE2ZTc0MjA3Mzc5NzM2NTZkMjA2ZTY1NjU2NDIw
NmU2Zjc0MjA2MjY1MjA3NDcyNzU2NTJlMjA0MTIwNjM2ZjZlNjY2ZjcyNmQ2OTZlNjcyMDY5NmQ3
MDZjNjU2ZDY1NmU3NDYxNzQ2OTZmNmUyMDYzNmY3NTZjNjQyMDYyNjUyMDYyNzU2OTZjNzQyMDc1
NzA2ZjZlMjA2MTIwNDMyMDczNzQ2NDY5NmY+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFND
TgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKMS43MTUz
IFR3CgpCVAo0OC4yNCAyNzMuNzQ2IFRkCi9GMS4wIDEwLjUgVGYKPDQ2NDk0YzQ1MmEyMDZmNzIy
MDc1NzA2ZjZlMjA3MzZmNmQ2NTIwNmY3NDY4NjU3MjIwNmM2Zjc3MmQ2YzY1NzY2NTZjMjA2NDY1
NzM2MzcyNjk3MDc0NmY3MjJlMjA1MDZmNzM2OTc4MjA2ZDY5Njc2ODc0MjA2MjY1MjA3Mzc1NzA3
MDZmNzI3NDY1NjQyMDc0Njg3MjZmNzU2NzY4MjA2MTZlMjA2NTZkNzU2YzYxNzQ2OTZmNmU+IFRq
CkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMjU3Ljk2NiBUZAovRjEuMCAxMC41IFRmCls8
NmM2MT4gMjAuMDE5NSA8Nzk2NTcyMjA2ZjZlNmM3OT4gODkuODQzOCA8MmU+XSBUSgpFVAoKMC4w
IDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgpCVAo0OC4yNCAyMzAuMTg2IFRkCi9GMS4wIDEwLjUgVGYKWzw1NDY4NjU3MzY1MjA2MzZm
NmU3MzY5NjQ2NTcyPiAyMC4wMTk1IDw2MTc0Njk2ZjZlNzMyMDY5NmU2NTc2Njk3NDYxNjI2Yzc5
MjA2YzY1NjE2NDIwNzQ2ZjIwNjEyMDZkNmY3MjY1MjA2MzZmNmQ3MDZjNjU3ODIwNzA3MjZmNzA2
ZjczNjE2YzJlPl0gVEoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAu
MiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMTg2LjA3NCBUZAovRjIuMCAyMiBU
Zgo8NzM3NTcyNzY2NTc5MjA2ZjY2MjA2NTc4Njk3Mzc0Njk2ZTY3MjA2NjY5NmM2NTYyNzU2NjIw
Njk2ZDcwNmM2NTZkNjU2ZTc0NjE3NDY5NmY2ZTczPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAu
MCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgowLjgyNDQgVHcK
CkJUCjQ4LjI0IDE1Ni44ODYgVGQKL0YxLjAgMTAuNSBUZgo8NGY2ZTZjNzkyMDYxMjA2NjY1Nzcy
MDZmNzA2NTZlMjA3MzZmNzU3MjYzNjUyMDY5NmQ3MDZjNjU2ZDY1NmU3NDYxNzQ2OTZmNmU3MzIw
Njg2MTc2NjUyMDYyNjU2NTZlMjA3Mzc1NzI3NjY1Nzk2NTY0MjA3MzZmMjA2NjYxNzIyZTIwNTQ2
ODY1MjA3NjY5NzM3NTYxNmMyMDQzMmIyYjIwNjk2ZTc0NjU3MjY2NjE2MzY1MjA3NzYxNzM+IFRq
CkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKMi42Mjc4IFR3CgpCVAo0OC4yNCAxNDEuMTA2IFRkCi9GMS4w
IDEwLjUgVGYKPDczNzU3Mjc2NjU3OTY1NjQyMDc1NzM2OTZlNjcyMDc0Njg2NTIwNjY3MjY1NjUy
MDc0Njk2NTcyMjA2OTZlNzM3NDYxNmM2YzYxNzQ2OTZmNmUyMDYxNzMyMDYxMjA2MzYxNmU2ZjZl
Njk2MzYxNmMyMDZlNmY2ZTIwNTA2ZjczNjk3ODIwNjU3ODY1NmQ3MDZjNjE3MjJlMjA0OTZlNzA3
NTc0MjA2NjcyNmY2ZDIwNzQ2ODZmNzM2NT4gVGoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NO
CjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4y
NCAxMjUuMzI2IFRkCi9GMS4wIDEwLjUgVGYKPDY1Nzg3MDY1NzI2OTY1NmU2MzY1NjQyMDc3Njk3
NDY4MjA2Zjc0Njg2NTcyMjA3Mzc5NzM3NDY1NmQ3MzIwNzc2Zjc1NmM2NDIwNjI2NTIwNjE3MDcw
NzI2NTYzNjk2MTc0NjU2NDJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNj
bgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA5Ny41NDYgVGQKL0Yx
LjAgMTAuNSBUZgo8NDk2ZDcwNmM2NTZkNjU2ZTc0NjE3NDY5NmY2ZTczMjA3Mzc1NzI3NjY1Nzk2
NTY0M2E+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAu
MiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgNjkuNzY2IFRkCi9GMS4w
IDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4w
IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDY5Ljc2NiBUZAov
RjEuMCAxMC41IFRmCls8NjE3MDYxNjM2ODY1MjA3Mzc0NjQ2Mzc4NzgyMDI4NjI2MTczNjU2NDIw
NmY2ZTIwNjk2ZDcwNmY3Mjc0MjA2ZjY2MjA3MjZmNjc3NTY1Nzc2MTc2NjUyMDczNzQ2MTZlNjQ2
MTcyNjQyMDZjNjk2MjcyPiAyMC4wMTk1IDw2MTcyNzkyMDY5NmQ3MDZjNjU2ZDY1NmU3NDYxNzQ2
OTZmNmUyMDMyMzAzMDM1Mjk+XSBUSgpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNj
bgpxCjAuMCAwLjAgMC4wIHNjbgowLjAgMC4wIDAuMCBTQ04KMSB3CjAgSgowIGoKW10gMCBkCi9T
dGFtcDEgRG8KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTQxLjAwOSAxNC4z
ODggVGQKL0YxLjAgOSBUZgo8Mzk+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAg
c2NuClEKUQoKZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago8PCAvVHlwZSAvUGFnZQovUGFyZW50
IDMgMCBSCi9NZWRpYUJveCBbMCAwIDU5NS4yOCA4NDEuODldCi9Dcm9wQm94IFswIDAgNTk1LjI4
IDg0MS44OV0KL0JsZWVkQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL1RyaW1Cb3ggWzAgMCA1OTUu
MjggODQxLjg5XQovQXJ0Qm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0NvbnRlbnRzIDcyIDAgUgov
UmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJ
XQovRm9udCA8PCAvRjIuMCAxNSAwIFIKL0YxLjAgOCAwIFIKPj4KL1hPYmplY3QgPDwgL1N0YW1w
MSA5MiAwIFIKPj4KPj4KL0Fubm90cyBbNzYgMCBSIDc3IDAgUiA3OCAwIFJdCj4+CmVuZG9iago3
NCAwIG9iagpbNzMgMCBSIC9YWVogMCA4NDEuODkgbnVsbF0KZW5kb2JqCjc1IDAgb2JqCls3MyAw
IFIgL1hZWiAwIDU0OS4wMyBudWxsXQplbmRvYmoKNzYgMCBvYmoKPDwgL0JvcmRlciBbMCAwIDBd
Ci9BIDw8IC9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwczovL3N0YWNrb3ZlcmZsb3cu
Y29tL3F1ZXN0aW9ucy84NjY3NTgxL2Zsb2NrLWluZy1hLWMtaWZzdHJlYW0tb24tbGludXgtZ2Nj
LTQtNi80NTUyNTAyOCM0NTUyNTAyOCkKPj4KL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQ4LjI0IDQ3
Mi43IDUxOS4yNjExIDQ4Ni45OF0KL1R5cGUgL0Fubm90Cj4+CmVuZG9iago3NyAwIG9iago8PCAv
Qm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8v
c3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzg2Njc1ODEvZmxvY2staW5nLWEtYy1pZnN0cmVh
bS1vbi1saW51eC1nY2MtNC02LzQ1NTI1MDI4IzQ1NTI1MDI4KQo+PgovU3VidHlwZSAvTGluawov
UmVjdCBbNDguMjQgNDU2LjkyIDk1LjE5NiA0NzEuMl0KL1R5cGUgL0Fubm90Cj4+CmVuZG9iago3
OCAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0EgPDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9V
UkkgKGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29jcHAub3JnL2ZvcnVtLyMhdG9waWMv
c3RkLXByb3Bvc2Fscy9YY1E0RlpKS0RiTSkKPj4KL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQ4LjI0
IDM4NS41OCA0NTYuNTIyIDM5OS44Nl0KL1R5cGUgL0Fubm90Cj4+CmVuZG9iago3OSAwIG9iagpb
NzMgMCBSIC9YWVogMCAyMTQuMzcgbnVsbF0KZW5kb2JqCjgwIDAgb2JqCjw8IC9MZW5ndGggNzY0
Mgo+PgpzdHJlYW0KcQoKLTAuNSBUYwovRGV2aWNlUkdCIGNzCjAuMiAwLjIgMC4yIHNjbgovRGV2
aWNlUkdCIENTCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSA3OTMuOTI2IFRkCi9GMS4wIDEw
LjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRj
CjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDc5My45MjYgVGQKL0Yx
LjAgMTAuNSBUZgo8NDc0ZTU1MjA2YzY5NjI3Mzc0NjQ2MzJiMmIzMz4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNTYuODgwNSA3NzIuMTQ2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDc3Mi4xNDYgVGQKL0YxLjAgMTAuNSBUZgo8NjM2YzYx
NmU2NzIwNmM2OTYyNjM3ODc4MmQzNDJlMzAyZTMxPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAu
MCAwLjAgMC4wIHNjbgoKLTAuNSBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpC
VAo1Ni44ODA1IDc1MC4zNjYgVGQKL0YxLjAgMTAuNSBUZgo8YTU+IFRqCkVUCgowLjAgMC4wIDAu
MCBTQ04KMC4wIDAuMCAwLjAgc2NuCgowLjAgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4y
IFNDTgoKQlQKNjYuMjQgNzUwLjM2NiBUZAovRjEuMCAxMC41IFRmCjw2ZjcwNjU2ZTIwNzc2MTc0
NjM2ZjZkMjA3NjMyPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIg
MC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA3MjIuNTg2IFRkCi9GMS4wIDEw
LjUgVGYKWzw1ND4gMjkuNzg1MiA8NmYyMDczNzU2ZDZkNjE3MjY5NzM2NTIwNjY2OTZlNjQ2OTZl
Njc3MzJlMjA3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDY5NzMyMDY2NzI2NTcxNzU2NTZlNzQ2
Yzc5MjA2OTZkNzA2YzY1NmQ2NTZlNzQ2NTY0MjA2OTZlMjA3NDY1NzI2ZDczMjA2ZjY2MjA0NjQ5
NGM0NTJhPiAxMjAuMTE3MiA8MmU+XSBUSgpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgowLjA0NzggVHcKCkJUCjQ4LjI0
IDY5NC44MDYgVGQKL0YxLjAgMTAuNSBUZgpbPDU0Njg2OTczMjA3Mzc1Njc2NzY1NzM3NDczMjA3
NzY1MjA2MzZmNzU2YzY0MjA2ZDYxNmI+IDIwLjAxOTUgPDY1MjA3Mzc0NjQzYTNhNjY2OTZjNjU2
Mjc1NjYyMDNkM2QyMDczNzQ2NDY5NmY1ZjY2Njk2YzY1NjI3NTY2MjA2MTczMjA3NDY4NjUyMDY0
NjU2NjYxNzU2Yzc0MjA2MTZlNjQyMDcwNzI2Zjc2Njk2NDY1MjA2ZTYxNzQ2OTc2NjU1ZjY2Njk2
YzY1NjI3NTY2MjA2MTczPl0gVEoKRVQKCgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAg
MC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA2NzkuMDI2
IFRkCi9GMS4wIDEwLjUgVGYKPDYxNmUyMDZmNzA3NDY5NmY2ZTYxNmMyMDZmNzA3NDY5NmQ2OTcz
NjE3NDY5NmY2ZTJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIg
MC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA2MzkuMTg2IFRkCi9GMi4wIDE4
IFRmCjw2MTcwNjE2MzY4NjUyMDczNzQ2NDYzNzg3OD4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQg
NjExLjE2NiBUZAovRjEuMCAxMC41IFRmCjw3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDY5NzMy
MDYyNjE3MzY1NjQyMDZmNmUyMDQ2NDk0YzQ1MmE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4w
IDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDU4
My4zODYgVGQKL0YxLjAgMTAuNSBUZgo8NjM2ZjZlNzM3NDcyNzU2Mzc0NmY3MjczMjA2MTcyNjUy
MDcwNzI2Zjc2Njk2NDY1NjQyMDY2NmY3MjIwNjI2Zjc0NjgyMDQ2NDk0YzQ1MmEyMDYxNmU2NDIw
NDY0NDNhPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgpxCjAuOTYwOCAw
Ljk2MDggMC45NjA4IHNjbgo1Mi4yNCA1NjcuNTcgbQo1NDMuMDQgNTY3LjU3IGwKNTQ1LjI0OTEg
NTY3LjU3IDU0Ny4wNCA1NjUuNzc5MSA1NDcuMDQgNTYzLjU3IGMKNTQ3LjA0IDQ5MC42MSBsCjU0
Ny4wNCA0ODguNDAwOSA1NDUuMjQ5MSA0ODYuNjEgNTQzLjA0IDQ4Ni42MSBjCjUyLjI0IDQ4Ni42
MSBsCjUwLjAzMDkgNDg2LjYxIDQ4LjI0IDQ4OC40MDA5IDQ4LjI0IDQ5MC42MSBjCjQ4LjI0IDU2
My41NyBsCjQ4LjI0IDU2NS43NzkxIDUwLjAzMDkgNTY3LjU3IDUyLjI0IDU2Ny41NyBjCmgKZgow
LjggMC44IDAuOCBTQ04KMC43NSB3CjUyLjI0IDU2Ny41NyBtCjU0My4wNCA1NjcuNTcgbAo1NDUu
MjQ5MSA1NjcuNTcgNTQ3LjA0IDU2NS43NzkxIDU0Ny4wNCA1NjMuNTcgYwo1NDcuMDQgNDkwLjYx
IGwKNTQ3LjA0IDQ4OC40MDA5IDU0NS4yNDkxIDQ4Ni42MSA1NDMuMDQgNDg2LjYxIGMKNTIuMjQg
NDg2LjYxIGwKNTAuMDMwOSA0ODYuNjEgNDguMjQgNDg4LjQwMDkgNDguMjQgNDkwLjYxIGMKNDgu
MjQgNTYzLjU3IGwKNDguMjQgNTY1Ljc3OTEgNTAuMDMwOSA1NjcuNTcgNTIuMjQgNTY3LjU3IGMK
aApTClEKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgNTQ0Ljc0NSBU
ZAovRjMuMCAxMSBUZgo8MmYyZjIwNjU3ODc0NjU2ZTczNjk2ZjZlMjAyZDIwNzI2NTc0NzU3MjZl
MjA3NDY4NjUyMDYxNzM3MzZmNjM2OTYxNzQ2NTY0MjA2NjY5NmM2NTIwNjQ2NTczNjM3MjY5NzA3
NDZmNzI+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4y
IHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0IDUzMC4wMDUgVGQKL0YzLjAgMTEgVGYKPDY5
NmU3NDIwNjY2NDIwMjgyOTIwNjM2ZjZlNzM3NDIwN2I+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04K
MC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0
IDUxNS4yNjUgVGQKL0YzLjAgMTEgVGYKPGNhMjAyMDIwNzI2NTc0NzU3MjZlMjA1ZjUyNTczYTNh
NWY1ZjcyNzc1ZjY2Njk2YzY1NmU2ZjIwMjg1ZjQzNWY2NjY5NmM2NTJjMjA3NDY4Njk3MzJkM2U1
ZjQzNWY3Mzc0NjE3NDY1MjkzYj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBz
Y24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgNTAwLjUyNSBUZAov
RjMuMCAxMSBUZgo8N2Q+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCnEK
MC45NjA4IDAuOTYwOCAwLjk2MDggc2NuCjUyLjI0IDQ3NC42MSBtCjU0My4wNCA0NzQuNjEgbAo1
NDUuMjQ5MSA0NzQuNjEgNTQ3LjA0IDQ3Mi44MTkxIDU0Ny4wNCA0NzAuNjEgYwo1NDcuMDQgMzk3
LjY1IGwKNTQ3LjA0IDM5NS40NDA5IDU0NS4yNDkxIDM5My42NSA1NDMuMDQgMzkzLjY1IGMKNTIu
MjQgMzkzLjY1IGwKNTAuMDMwOSAzOTMuNjUgNDguMjQgMzk1LjQ0MDkgNDguMjQgMzk3LjY1IGMK
NDguMjQgNDcwLjYxIGwKNDguMjQgNDcyLjgxOTEgNTAuMDMwOSA0NzQuNjEgNTIuMjQgNDc0LjYx
IGMKaApmCjAuOCAwLjggMC44IFNDTgowLjc1IHcKNTIuMjQgNDc0LjYxIG0KNTQzLjA0IDQ3NC42
MSBsCjU0NS4yNDkxIDQ3NC42MSA1NDcuMDQgNDcyLjgxOTEgNTQ3LjA0IDQ3MC42MSBjCjU0Ny4w
NCAzOTcuNjUgbAo1NDcuMDQgMzk1LjQ0MDkgNTQ1LjI0OTEgMzkzLjY1IDU0My4wNCAzOTMuNjUg
Ywo1Mi4yNCAzOTMuNjUgbAo1MC4wMzA5IDM5My42NSA0OC4yNCAzOTUuNDQwOSA0OC4yNCAzOTcu
NjUgYwo0OC4yNCA0NzAuNjEgbAo0OC4yNCA0NzIuODE5MSA1MC4wMzA5IDQ3NC42MSA1Mi4yNCA0
NzQuNjEgYwpoClMKUQowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1OS4yNCA0
NTEuNzg1IFRkCi9GMy4wIDExIFRmCjwyZjJmMjA2NTc4NzQ2NTZlNzM2OTZmNmUyMDJkMjA2MTcz
NzM2ZjYzNjk2MTc0NjUyMDJhNzQ2ODY5NzMyMDc3Njk3NDY4MjA2MTZlMjA2ZjcwNjU2ZTIwNjY2
OTZjNjUyMDY0NjU3MzYzNzI2OTcwNzQ2ZjcyPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAw
LjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1OS4yNCA0Mzcu
MDQ1IFRkCi9GMy4wIDExIFRmCjw2MjYxNzM2OTYzNWY2NjY5NmM2NTYyNzU2NjJhMjA2MTc0NzQ2
MTYzNjgyMDI4Njk2ZTc0MjA1ZjVmNjY2NDI5MjA3Yj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQg
NDIyLjMwNSBUZAovRjMuMCAxMSBUZgo8Y2EyMDIwMjA3MjY1NzQ3NTcyNmUyMDVmNDM1ZjZmNzA2
NTZlMjAyODVmNWY2NjY0MmMyMDMwMmMyMDc0Njg2OTczMmQzZTVmNDM1ZjYyNzU2NjY2NjU3MjJj
MjA3NDY4Njk3MzJkM2U1ZjQzNWY2Mjc1NjY3MzY5N2E2NTI5M2I+IFRqCkVUCgowLjAgMC4wIDAu
MCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJU
CjU5LjI0IDQwNy41NjUgVGQKL0YzLjAgMTEgVGYKPDdkPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NO
CjAuMCAwLjAgMC4wIHNjbgpxCjAuOTYwOCAwLjk2MDggMC45NjA4IHNjbgo1Mi4yNCAzODEuNjUg
bQo1NDMuMDQgMzgxLjY1IGwKNTQ1LjI0OTEgMzgxLjY1IDU0Ny4wNCAzNzkuODU5MSA1NDcuMDQg
Mzc3LjY1IGMKNTQ3LjA0IDI4OS45NSBsCjU0Ny4wNCAyODcuNzQwOSA1NDUuMjQ5MSAyODUuOTUg
NTQzLjA0IDI4NS45NSBjCjUyLjI0IDI4NS45NSBsCjUwLjAzMDkgMjg1Ljk1IDQ4LjI0IDI4Ny43
NDA5IDQ4LjI0IDI4OS45NSBjCjQ4LjI0IDM3Ny42NSBsCjQ4LjI0IDM3OS44NTkxIDUwLjAzMDkg
MzgxLjY1IDUyLjI0IDM4MS42NSBjCmgKZgowLjggMC44IDAuOCBTQ04KMC43NSB3CjUyLjI0IDM4
MS42NSBtCjU0My4wNCAzODEuNjUgbAo1NDUuMjQ5MSAzODEuNjUgNTQ3LjA0IDM3OS44NTkxIDU0
Ny4wNCAzNzcuNjUgYwo1NDcuMDQgMjg5Ljk1IGwKNTQ3LjA0IDI4Ny43NDA5IDU0NS4yNDkxIDI4
NS45NSA1NDMuMDQgMjg1Ljk1IGMKNTIuMjQgMjg1Ljk1IGwKNTAuMDMwOSAyODUuOTUgNDguMjQg
Mjg3Ljc0MDkgNDguMjQgMjg5Ljk1IGMKNDguMjQgMzc3LjY1IGwKNDguMjQgMzc5Ljg1OTEgNTAu
MDMwOSAzODEuNjUgNTIuMjQgMzgxLjY1IGMKaApTClEKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNTkuMjQgMzU4LjgyNSBUZAovRjMuMCAxMSBUZgo8MmYyZjIwNjU3ODc0NjU2
ZTczNjk2ZjZlMjAyZDIwNjY2Yzc1NzM2ODIwNjE2ZTY0MjA2NDY1NzQ2MTYzNjgyMDY2NzI2ZjZk
MjA2NjY5NmM2NTIwNjQ2NTczNjM3MjY5NzA3NDZmNzIyMDc3Njk3NDY4NmY3NTc0MjA2MzZjNmY3
MzY5NmU2NzIwNjk3ND4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4y
IDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTkuMjQgMzQ0LjA4NSBUZAovRjMuMCAx
MSBUZgo8Njk2ZTc0MjA2NDY1NzQ2MTYzNjgyMDI4MjkyMDdiPiBUagpFVAoKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1
OS4yNCAzMjkuMzQ1IFRkCi9GMy4wIDExIFRmCjxjYTIwMjAyMDYzNmY2ZTczNzQyMDY5NmU3NDIw
NWY1ZjY2NjQyMDNkMjA2NjY0MjAyODI5M2I+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAu
MCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0IDMxNC42
MDUgVGQKL0YzLjAgMTEgVGYKPGNhMjAyMDIwNzI2NTc0NzU3MjZlMjA2MzZjNmY3MzY1MjAyODY2
NjE2YzczNjUyOTIwM2YyMDVmNWY2NjY0MjAzYTIwMmQzMTNiPiBUagpFVAoKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo1
OS4yNCAyOTkuODY1IFRkCi9GMy4wIDExIFRmCjw3ZD4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgow
LjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQg
MjQ5LjkyNiBUZAovRjIuMCAxOCBUZgo8NDc0ZTU1MjA2YzY5NjI3Mzc0NjQ2MzJiMmIzMz4gVGoK
RVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAw
LjIgMC4yIFNDTgoKQlQKNDguMjQgMjIxLjkwNiBUZAovRjEuMCAxMC41IFRmCjw0MjYxNzM2NTY0
MjA2ZjZlMjA2NzYzNjMyMDM3MmUzMTJlMzAyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAg
MC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgMTk0
LjEyNiBUZAovRjEuMCAxMC41IFRmCjw3Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDY5NzMyMDYy
NjE3MzY1NjQyMDZmNmUyMDQ2NDk0YzQ1MmE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAu
MCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDE2Ni4z
NDYgVGQKL0YxLjAgMTAuNSBUZgo8NzA3MjZmNzY2OTY0NjU3MzIwNjU3ODc0NjU2ZTczNjk2ZjZl
NzM+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAw
LjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU2Ljg4MDUgMTM4LjU2NiBUZAovRjEuMCAx
MC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBU
YwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo2Ni4yNCAxMzguNTY2IFRkCi9G
MS4wIDEwLjUgVGYKPDZjNjk2MjczNzQ2NDYzMmIyYjJkNzYzMzJmNjk2ZTYzNmM3NTY0NjUyZjY1
Nzg3NDJmNzM3NDY0Njk2ZjVmNjY2OTZjNjU2Mjc1NjYyZTY4MjAyNjIwMmQyMDQ2NDk0YzQ1MmEy
MDYxNmU2NDIwNDY0ND4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0w
LjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSAxMTYuNzg2
IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4w
IHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDEx
Ni43ODYgVGQKL0YxLjAgMTAuNSBUZgo8NmM2OTYyNzM3NDY0NjMyYjJiMmQ3NjMzMmY2OTZlNjM2
Yzc1NjQ2NTJmNjU3ODc0MmY3Mzc0NjQ2OTZmNWY3Mzc5NmU2MzVmNjY2OTZjNjU2Mjc1NjYyZTY4
MjAyNjIwNDY0OTRjNDUyYTIwNmY2ZTZjNzk+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAu
MCAwLjAgc2NuCnEKMC4wIDAuMCAwLjAgc2NuCjAuMCAwLjAgMC4wIFNDTgoxIHcKMCBKCjAgagpb
XSAwIGQKL1N0YW1wMiBEbwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OS4y
NCAxNC4zODggVGQKL0YxLjAgOSBUZgo8MzEzMD4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAg
MC4wIDAuMCBzY24KUQpRCgplbmRzdHJlYW0KZW5kb2JqCjgxIDAgb2JqCjw8IC9UeXBlIC9QYWdl
Ci9QYXJlbnQgMyAwIFIKL01lZGlhQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0Nyb3BCb3ggWzAg
MCA1OTUuMjggODQxLjg5XQovQmxlZWRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovVHJpbUJveCBb
MCAwIDU5NS4yOCA4NDEuODldCi9BcnRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQ29udGVudHMg
ODAgMCBSCi9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VD
IC9JbWFnZUldCi9Gb250IDw8IC9GMS4wIDggMCBSCi9GMi4wIDE1IDAgUgovRjMuMCA0MiAwIFIK
Pj4KL1hPYmplY3QgPDwgL1N0YW1wMiA5MyAwIFIKPj4KPj4KPj4KZW5kb2JqCjgyIDAgb2JqCls4
MSAwIFIgL1hZWiAwIDY2My4yMSBudWxsXQplbmRvYmoKODMgMCBvYmoKWzgxIDAgUiAvWFlaIDAg
MjczLjk1IG51bGxdCmVuZG9iago4NCAwIG9iago8PCAvTGVuZ3RoIDQ2ODAKPj4Kc3RyZWFtCnEK
L0RldmljZVJHQiBjcwowLjIgMC4yIDAuMiBzY24KL0RldmljZVJHQiBDUwowLjIgMC4yIDAuMiBT
Q04KCkJUCjQ4LjI0IDc4Ni42NjYgVGQKL0YyLjAgMTggVGYKPDYzNmM2MTZlNjcyMDZjNjk2MjYz
Nzg3OD4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIg
c2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNzU4LjY0NiBUZAovRjEuMCAxMC41IFRmCjw3
Mzc0NjQzYTNhNjY2OTZjNjU2Mjc1NjYyMDY5NzMyMDYyNjE3MzY1NjQyMDZmNmUyMDQ2NDk0YzQ1
MmE+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNj
bgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDczMC44NjYgVGQKL0YxLjAgMTAuNSBUZgo8NGU2
ZjIwNjU3ODc0NjU2ZTczNjk2ZjZlNzMyMDcwNzI2Zjc2Njk2NDY1NjQyZT4gVGoKRVQKCjAuMCAw
LjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFND
TgoKQlQKNDguMjQgNjkxLjAyNiBUZAovRjIuMCAxOCBUZgo8NmY3MDY1NmUyMDc3NjE3NDYzNmY2
ZDIwNzYzMj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4yIDAuMiAw
LjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNjYzLjAwNiBUZAovRjEuMCAxMC41IFRm
Cls8NDk2ZTYzNmM3NTY0NjU2NDIwNjE3MzIwNjk3NDIwNjk3MzIwNmY3MDY1NmUyMDczNmY3NTcy
NjM2NTIwNjE2ZTY0MjA3NDY4NjU3MjY1NjY2ZjcyNjUyMDYxNjM2MzY1NzM3MzY5NjI2YzY1MmUy
MDQ5NzQyMDZkNjE+IDIwLjAxOTUgPDc5MjA2ZTZmNzQyMDYyNjUyMDY5NmUyMDc3Njk2NDY1NzM3
MDcyNjU2MTY0MjA3NTczNjUyZT5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAg
c2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDYzNS4yMjYgVGQK
L0YxLjAgMTAuNSBUZgo8NjY2OTZjNjU2Mjc1NjYyMDY5NzMyMDYyNjE3MzY1NjQyMDZmNmUyMDYx
NmUyMDQ2NDQyZT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUg
VGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTYuODgwNSA2MDcuNDQ2IFRk
Ci9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNj
bgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDYwNy40
NDYgVGQKL0YxLjAgMTAuNSBUZgo8NjY2OTZjNjU2Mjc1NjYyMDYzNjE2ZTIwNjI2NTIwNjM2ZjZl
NzM3NDcyNzU2Mzc0NjU2NDIwNjY3MjZmNmQyMDYxNmUyMDQ2NDQyZT4gVGoKRVQKCjAuMCAwLjAg
MC4wIFNDTgowLjAgMC4wIDAuMCBzY24KCi0wLjUgVGMKMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIg
MC4yIFNDTgoKQlQKNTYuODgwNSA1ODUuNjY2IFRkCi9GMS4wIDEwLjUgVGYKPGE1PiBUagpFVAoK
MC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgoKMC4wIFRjCjAuMiAwLjIgMC4yIHNjbgow
LjIgMC4yIDAuMiBTQ04KCkJUCjY2LjI0IDU4NS42NjYgVGQKL0YxLjAgMTAuNSBUZgo8NjE2ZTIw
NjY2NDI4MjkyMDY2NzU2ZTYzNzQ2OTZmNmUyMDYzNjE2ZTIwNjI2NTIwNzU3MzY1NjQyMDc0NmYy
MDZmNjI3NDYxNjk2ZTIwNzQ2ODY1MjA0NjQ0MmU+IFRqCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4w
IDAuMCAwLjAgc2NuCgotMC41IFRjCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJU
CjU2Ljg4MDUgNTYzLjg4NiBUZAovRjEuMCAxMC41IFRmCjxhNT4gVGoKRVQKCjAuMCAwLjAgMC4w
IFNDTgowLjAgMC4wIDAuMCBzY24KCjAuMCBUYwowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIg
U0NOCgpCVAo2Ni4yNCA1NjMuODg2IFRkCi9GMS4wIDEwLjUgVGYKPDYxNmUyMDYxNzQ3NDYxNjM2
ODI4MjkyMDY2NzU2ZTYzNzQ2OTZmNmUyMDYzNjE2ZTIwNjI2NTIwNzU3MzY1NjQyMDc0NmYyMDYx
NzM3MzZmNjM2OTYxNzQ2NTIwNjEyMDY2Njk2YzY1NjI3NTY2MjA3NzY5NzQ2ODIwNjEyMDZlNjU3
NzIwNDY0NDJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4y
IDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0OC4yNCA1MjQuMDQ2IFRkCi9GMi4wIDE4IFRm
Cjw3NjY5NzM3NTYxNmMyMDYzMmIyYj4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAu
MCBzY24KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNDguMjQgNDk2LjAyNiBU
ZAovRjEuMCAxMC41IFRmCjw2MjYxNzM2OTYzNWY2NjY5NmM2NTYyNzU2NjIwNjk3MzIwNjI3NTY5
NmM3NDIwNmY2ZTIwNzQ2ZjcwMjA2ZjY2MjA0NjQ5NGM0NTJhPiBUagpFVAoKMC4wIDAuMCAwLjAg
U0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAuMiAwLjIgU0NOCgpCVAo0
OC4yNCA0NjguMjQ2IFRkCi9GMS4wIDEwLjUgVGYKPDRkNTM0NDRlMjA2NDY1NzM2MzcyNjk2MjY1
NzMzYT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KcQowLjk2MDggMC45
NjA4IDAuOTYwOCBzY24KNTIuMjQgNDUyLjQzIG0KNTQzLjA0IDQ1Mi40MyBsCjU0NS4yNDkxIDQ1
Mi40MyA1NDcuMDQgNDUwLjYzOTEgNTQ3LjA0IDQ0OC40MyBjCjU0Ny4wNCA0MDQuOTUgbAo1NDcu
MDQgNDAyLjc0MDkgNTQ1LjI0OTEgNDAwLjk1IDU0My4wNCA0MDAuOTUgYwo1Mi4yNCA0MDAuOTUg
bAo1MC4wMzA5IDQwMC45NSA0OC4yNCA0MDIuNzQwOSA0OC4yNCA0MDQuOTUgYwo0OC4yNCA0NDgu
NDMgbAo0OC4yNCA0NTAuNjM5MSA1MC4wMzA5IDQ1Mi40MyA1Mi4yNCA0NTIuNDMgYwpoCmYKMC44
IDAuOCAwLjggU0NOCjAuNzUgdwo1Mi4yNCA0NTIuNDMgbQo1NDMuMDQgNDUyLjQzIGwKNTQ1LjI0
OTEgNDUyLjQzIDU0Ny4wNCA0NTAuNjM5MSA1NDcuMDQgNDQ4LjQzIGMKNTQ3LjA0IDQwNC45NSBs
CjU0Ny4wNCA0MDIuNzQwOSA1NDUuMjQ5MSA0MDAuOTUgNTQzLjA0IDQwMC45NSBjCjUyLjI0IDQw
MC45NSBsCjUwLjAzMDkgNDAwLjk1IDQ4LjI0IDQwMi43NDA5IDQ4LjI0IDQwNC45NSBjCjQ4LjI0
IDQ0OC40MyBsCjQ4LjI0IDQ1MC42MzkxIDUwLjAzMDkgNDUyLjQzIDUyLjI0IDQ1Mi40MyBjCmgK
UwpRCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjU5LjI0IDQyOS42MDUgVGQK
L0YzLjAgMTEgVGYKPDY2Njk2YzY1NjQ2NTczNjMyMDY2NjQyODI5MjA2MzZmNmU3Mzc0M2I+IFRq
CkVUCgowLjAgMC4wIDAuMCBTQ04KMC4wIDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIg
MC4yIDAuMiBTQ04KCkJUCjU5LjI0IDQxNC44NjUgVGQKL0YzLjAgMTEgVGYKPDY2Njk2YzY1NjI3
NTY2MmEyMDYxNzQ3NDYxNjM2ODI4MjA2NjY5NmM2NTY0NjU3MzYzMjA2NjY0MjAyOTNiPiBUagpF
VAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAuNzkyMiBz
Y24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgU0NOCgoyLjUzODcgVHcKCkJUCjQ4LjI0IDM3Ni45ODYg
VGQKL0YxLjAgMTAuNSBUZgpbPDY4NzQ3NDcwNzMzYTJmMmY2ZDczNjQ2ZTJlNmQ2OTYzNzI2Zjcz
NmY2Njc0MmU2MzZmNmQyZjY1NmUyZDc1NzMyZjZjNjk2MjcyPiAyMC4wMTk1IDw2MTcyNzkyZjYx
NjEzMjM0MzMzODMxMzIyODc2M2Q3NjczMmUzNjMwMjkyZTYxNzM3MDc4Pl0gVEoKRVQKCgowLjAg
VHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjIgMC4yIDAuMiBzY24KMC4yIDAu
MiAwLjIgU0NOCgoyLjUzODcgVHcKCkJUCjM3Mi4zODUzIDM3Ni45ODYgVGQKL0YxLjAgMTAuNSBU
Zgo8MjA+IFRqCkVUCgoKMC4wIFR3CjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24KMC4y
NTg4IDAuNTQ1MSAwLjc5MjIgc2NuCjAuMjU4OCAwLjU0NTEgMC43OTIyIFNDTgoKMi41Mzg3IFR3
CgpCVAozNzcuNjQzNSAzNzYuOTg2IFRkCi9GMS4wIDEwLjUgVGYKPDY4NzQ3NDcwNzMzYTJmMmY2
ZDczNjQ2ZTJlNmQ2OTYzNzI2ZjczNmY2Njc0MmU2MzZmNmQyZjY1NmUyZDc1NzMyZj4gVGoKRVQK
CgowLjAgVHcKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgowLjI1ODggMC41NDUxIDAu
NzkyMiBzY24KMC4yNTg4IDAuNTQ1MSAwLjc5MjIgU0NOCgpCVAo0OC4yNCAzNjEuMjA2IFRkCi9G
MS4wIDEwLjUgVGYKWzw2YzY5NjI3Mj4gMjAuMDE5NSA8NjE3Mjc5MmY2MTYxMzIzNDMzMzgzMTMw
Mjg3NjNkNzY3MzJlMzYzMDI5MmU2MTczNzA3OD5dIFRKCkVUCgowLjAgMC4wIDAuMCBTQ04KMC4w
IDAuMCAwLjAgc2NuCjAuMiAwLjIgMC4yIHNjbgowLjIgMC4yIDAuMiBTQ04KCkJUCjQ4LjI0IDMz
My40MjYgVGQKL0YxLjAgMTAuNSBUZgo8NTQ2ODZmNzU2NzY4MjA3NDY4NjU3MzY1MjA2NDY5NjQy
MDZlNmY3NDIwNjE3MDcwNjU2MTcyMjA3NDY4NjUyMDY4NjU2MTY0NjU3MjczMjA0OTIwNjU3ODYx
NmQ2OTZlNjU2NDJlPiBUagpFVAoKMC4wIDAuMCAwLjAgU0NOCjAuMCAwLjAgMC4wIHNjbgpxCjAu
MCAwLjAgMC4wIHNjbgowLjAgMC4wIDAuMCBTQ04KMSB3CjAgSgowIGoKW10gMCBkCi9TdGFtcDEg
RG8KMC4yIDAuMiAwLjIgc2NuCjAuMiAwLjIgMC4yIFNDTgoKQlQKNTM1Ljk3OCAxNC4zODggVGQK
L0YxLjAgOSBUZgo8MzEzMT4gVGoKRVQKCjAuMCAwLjAgMC4wIFNDTgowLjAgMC4wIDAuMCBzY24K
UQpRCgplbmRzdHJlYW0KZW5kb2JqCjg1IDAgb2JqCjw8IC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAw
IFIKL01lZGlhQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0Nyb3BCb3ggWzAgMCA1OTUuMjggODQx
Ljg5XQovQmxlZWRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovVHJpbUJveCBbMCAwIDU5NS4yOCA4
NDEuODldCi9BcnRCb3ggWzAgMCA1OTUuMjggODQxLjg5XQovQ29udGVudHMgODQgMCBSCi9SZXNv
dXJjZXMgPDwgL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldCi9G
b250IDw8IC9GMi4wIDE1IDAgUgovRjEuMCA4IDAgUgovRjMuMCA0MiAwIFIKPj4KL1hPYmplY3Qg
PDwgL1N0YW1wMSA5MiAwIFIKPj4KPj4KL0Fubm90cyBbODkgMCBSIDkwIDAgUiA5MSAwIFJdCj4+
CmVuZG9iago4NiAwIG9iagpbODUgMCBSIC9YWVogMCA4NDEuODkgbnVsbF0KZW5kb2JqCjg3IDAg
b2JqCls4NSAwIFIgL1hZWiAwIDcxNS4wNSBudWxsXQplbmRvYmoKODggMCBvYmoKWzg1IDAgUiAv
WFlaIDAgNTQ4LjA3IG51bGxdCmVuZG9iago4OSAwIG9iago8PCAvQm9yZGVyIFswIDAgMF0KL0Eg
PDwgL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHBzOi8vbXNkbi5taWNyb3NvZnQuY29t
L2VuLXVzL2xpYnJhcnkvYWEyNDM4MTJcKHY9dnMuNjBcKS5hc3B4KQo+PgovU3VidHlwZSAvTGlu
awovUmVjdCBbNDguMjQgMzczLjkyIDM3Mi4zODUzIDM4OC4yXQovVHlwZSAvQW5ub3QKPj4KZW5k
b2JqCjkwIDAgb2JqCjw8IC9Cb3JkZXIgWzAgMCAwXQovQSA8PCAvVHlwZSAvQWN0aW9uCi9TIC9V
UkkKL1VSSSAoaHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9hYTI0Mzgx
MFwodj12cy42MFwpLmFzcHgpCj4+Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszNzcuNjQzNSAzNzMu
OTIgNTQ3LjA0IDM4OC4yXQovVHlwZSAvQW5ub3QKPj4KZW5kb2JqCjkxIDAgb2JqCjw8IC9Cb3Jk
ZXIgWzAgMCAwXQovQSA8PCAvVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cHM6Ly9tc2Ru
Lm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9hYTI0MzgxMFwodj12cy42MFwpLmFzcHgpCj4+
Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0OC4yNCAzNTguMTQgMjAyLjk4ODggMzcyLjQyXQovVHlw
ZSAvQW5ub3QKPj4KZW5kb2JqCjkyIDAgb2JqCjw8IC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9G
b3JtCi9CQm94IFswIDAgNTk1LjI4IDg0MS44OV0KL0xlbmd0aCAxNjIKPj4Kc3RyZWFtCnEKL0Rl
dmljZVJHQiBjcwowLjAgMC4wIDAuMCBzY24KL0RldmljZVJHQiBDUwowLjAgMC4wIDAuMCBTQ04K
MSB3CjAgSgowIGoKW10gMCBkCnEKMC4yNSB3Ci9EZXZpY2VSR0IgQ1MKMC44NjY3IDAuODY2NyAw
Ljg2NjcgU0NOCjQ4LjI0IDMwLjAgbQo1NDcuMDQgMzAuMCBsClMKUQpRCgplbmRzdHJlYW0KZW5k
b2JqCjkzIDAgb2JqCjw8IC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9Gb3JtCi9CQm94IFswIDAg
NTk1LjI4IDg0MS44OV0KL0xlbmd0aCAxNjIKPj4Kc3RyZWFtCnEKL0RldmljZVJHQiBjcwowLjAg
MC4wIDAuMCBzY24KL0RldmljZVJHQiBDUwowLjAgMC4wIDAuMCBTQ04KMSB3CjAgSgowIGoKW10g
MCBkCnEKMC4yNSB3Ci9EZXZpY2VSR0IgQ1MKMC44NjY3IDAuODY2NyAwLjg2NjcgU0NOCjQ4LjI0
IDMwLjAgbQo1NDcuMDQgMzAuMCBsClMKUQpRCgplbmRzdHJlYW0KZW5kb2JqCjk0IDAgb2JqCjw8
IC9UeXBlIC9PdXRsaW5lcwovQ291bnQgMzAKL0ZpcnN0IDk1IDAgUgovTGFzdCAxMTkgMCBSCj4+
CmVuZG9iago5NSAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDY2MDA2OTAwNmMwMDY1MDAyMDAwNzMw
MDc0MDA3MjAwNjUwMDYxMDA2ZDAwNzMwMDIwMDA2MTAwNmUwMDY0MDAyMDAwNjEwMDYzMDA2MzAw
NjUwMDczMDA3MzAwMjAwMDc0MDA2ZjAwMjAwMDc0MDA2ODAwNjUwMDIwMDA2NjAwNjkwMDZjMDA2
NTAwMjAwMDY0MDA2NTAwNzMwMDYzMDA3MjAwNjkwMDcwMDA3NDAwNmYwMDcyPgovUGFyZW50IDk0
IDAgUgovQ291bnQgMAovTmV4dCA5NiAwIFIKL0Rlc3QgWzcgMCBSIC9YWVogMCA4NDEuODkgbnVs
bF0KPj4KZW5kb2JqCjk2IDAgb2JqCjw8IC9UaXRsZSA8ZmVmZjAwNDQwMDY1MDA2NjAwNjkwMDZl
MDA2OTAwNzQwMDY5MDA2ZjAwNmUwMDczPgovUGFyZW50IDk0IDAgUgovQ291bnQgMAovTmV4dCA5
NyAwIFIKL1ByZXYgOTUgMCBSCi9EZXN0IFsxMCAwIFIgL1hZWiAwIDg0MS44OSBudWxsXQo+Pgpl
bmRvYmoKOTcgMCBvYmoKPDwgL1RpdGxlIDxmZWZmMDA0ZDAwNmYwMDc0MDA2OTAwNzYwMDYxMDA3
NDAwNjkwMDZmMDA2ZT4KL1BhcmVudCA5NCAwIFIKL0NvdW50IDIKL0ZpcnN0IDk4IDAgUgovTGFz
dCA5OSAwIFIKL05leHQgMTAwIDAgUgovUHJldiA5NiAwIFIKL0Rlc3QgWzEwIDAgUiAvWFlaIDAg
NjM4LjI3IG51bGxdCj4+CmVuZG9iago5OCAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDRlMDA2MTAw
NzQwMDY5MDA3NjAwNjUwMDIwMDA0NjAwNjkwMDZjMDA2NTAwMjAwMDQ0MDA2NTAwNzMwMDYzMDA3
MjAwNjkwMDcwMDA3NDAwNmYwMDcyMDA3Mz4KL1BhcmVudCA5NyAwIFIKL0NvdW50IDAKL05leHQg
OTkgMCBSCi9EZXN0IFsxMCAwIFIgL1hZWiAwIDU0My4xOSBudWxsXQo+PgplbmRvYmoKOTkgMCBv
YmoKPDwgL1RpdGxlIDxmZWZmMDA0MzAwMjAwMDczMDA3NDAwNjQwMDY5MDA2ZjAwMjAwMDY2MDA3
NTAwNmUwMDYzMDA3NDAwNjkwMDZmMDA2ZTAwNzMwMDIwMDA2MjAwNjEwMDczMDA2NTAwNjQwMDIw
MDA2ZjAwNmUwMDIwMDA0NjAwNDkwMDRjMDA0NTAwMmE+Ci9QYXJlbnQgOTcgMCBSCi9Db3VudCAw
Ci9QcmV2IDk4IDAgUgovRGVzdCBbMjAgMCBSIC9YWVogMCA4NDEuODkgbnVsbF0KPj4KZW5kb2Jq
CjEwMCAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDQzMDA3NTAwNzIwMDcyMDA2NTAwNmUwMDc0MDAy
MDAwNTMwMDZmMDA2YzAwNzUwMDc0MDA2OTAwNmYwMDZlMDA3Mz4KL1BhcmVudCA5NCAwIFIKL0Nv
dW50IDAKL05leHQgMTAxIDAgUgovUHJldiA5NyAwIFIKL0Rlc3QgWzIwIDAgUiAvWFlaIDAgNTU4
LjgxIG51bGxdCj4+CmVuZG9iagoxMDEgMCBvYmoKPDwgL1RpdGxlIDxmZWZmMDA0MjAwNjUwMDc0
MDA3NDAwNjUwMDcyMDAyMDAwNTMwMDZmMDA2YzAwNzUwMDc0MDA2OTAwNmYwMDZlPgovUGFyZW50
IDk0IDAgUgovQ291bnQgMgovRmlyc3QgMTAyIDAgUgovTGFzdCAxMDMgMCBSCi9OZXh0IDEwNCAw
IFIKL1ByZXYgMTAwIDAgUgovRGVzdCBbMjAgMCBSIC9YWVogMCAyNTcuOTMgbnVsbF0KPj4KZW5k
b2JqCjEwMiAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDRjMDA2OTAwNmUwMDZiMDAyMDAwNjIwMDY1
MDA3NDAwNzcwMDY1MDA2NTAwNmUwMDIwMDA3MjAwNjUwMDcxMDA3NTAwNjkwMDcyMDA2NTAwNmQw
MDY1MDA2ZTAwNzQwMDczMDAyMDAwNjYwMDZmMDA3MjAwMjAwMDQ2MDA0OTAwNGMwMDQ1MDAyYTAw
MjAwMDYxMDA2ZTAwNjQwMDIwMDA2ZTAwNjEwMDc0MDA2OTAwNzYwMDY1MDAyMDAwNjYwMDY5MDA2
YzAwNjUwMDIwMDA2ODAwNjEwMDZlMDA2NDAwNmMwMDY1MDA3Mz4KL1BhcmVudCAxMDEgMCBSCi9D
b3VudCAwCi9OZXh0IDEwMyAwIFIKL0Rlc3QgWzIwIDAgUiAvWFlaIDAgMTYyLjg1IG51bGxdCj4+
CmVuZG9iagoxMDMgMCBvYmoKPDwgL1RpdGxlIDxmZWZmMDA1MjAwNjUwMDZjMDA2MTAwNzQwMDY5
MDA2ZjAwNmUwMDIwMDA3NDAwNmYwMDIwMDA3MDAwNzIwMDY1MDA3NjAwNjkwMDZmMDA3NTAwNzMw
MDIwMDA3MDAwNzIwMDZmMDA3MDAwNmYwMDczMDA2MTAwNmMwMDczPgovUGFyZW50IDEwMSAwIFIK
L0NvdW50IDAKL1ByZXYgMTAyIDAgUgovRGVzdCBbMjggMCBSIC9YWVogMCA3NDYuNTUgbnVsbF0K
Pj4KZW5kb2JqCjEwNCAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDUwMDA3MjAwNmYwMDcwMDA2ZjAw
NzMwMDYxMDA2Yz4KL1BhcmVudCA5NCAwIFIKL0NvdW50IDIKL0ZpcnN0IDEwNSAwIFIKL0xhc3Qg
MTA2IDAgUgovTmV4dCAxMDcgMCBSCi9QcmV2IDEwMSAwIFIKL0Rlc3QgWzI4IDAgUiAvWFlaIDAg
NDYwLjg5IG51bGxdCj4+CmVuZG9iagoxMDUgMCBvYmoKPDwgL1RpdGxlIDxmZWZmMDA3MzAwNzQw
MDY0MDAzYTAwM2EwMDZlMDA2MTAwNzQwMDY5MDA3NjAwNjUwMDVmMDA2NjAwNjkwMDZjMDA2NTAw
NWYwMDY0MDA2NTAwNzMwMDYzMDA3MjAwNjkwMDcwMDA3NDAwNmYwMDcyPgovUGFyZW50IDEwNCAw
IFIKL0NvdW50IDAKL05leHQgMTA2IDAgUgovRGVzdCBbMjggMCBSIC9YWVogMCAxNDQuMjMgbnVs
bF0KPj4KZW5kb2JqCjEwNiAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDczMDA3NDAwNjQwMDNhMDAz
YTAwNzMwMDc0MDA2NDAwNjkwMDZmMDA1ZjAwNjYwMDY5MDA2YzAwNjUwMDYyMDA3NTAwNjY+Ci9Q
YXJlbnQgMTA0IDAgUgovQ291bnQgMAovUHJldiAxMDUgMCBSCi9EZXN0IFs0NyAwIFIgL1hZWiAw
IDg0MS44OSBudWxsXQo+PgplbmRvYmoKMTA3IDAgb2JqCjw8IC9UaXRsZSA8ZmVmZjAwNDkwMDZk
MDA3MDAwNmMwMDY1MDA2ZDAwNjUwMDZlMDA3NDAwNjEwMDc0MDA2OTAwNmYwMDZlPgovUGFyZW50
IDk0IDAgUgovQ291bnQgMAovTmV4dCAxMDggMCBSCi9QcmV2IDEwNCAwIFIKL0Rlc3QgWzQ3IDAg
UiAvWFlaIDAgNTU2LjU5IG51bGxdCj4+CmVuZG9iagoxMDggMCBvYmoKPDwgL1RpdGxlIDxmZWZm
MDA1MDAwNzIwMDZmMDA2MjAwNmMwMDY1MDA2ZDAwNzMwMDIwMDA3NDAwNmYwMDIwMDA2MjAwNjUw
MDIwMDA2MTAwNjQwMDY0MDA3MjAwNjUwMDczMDA3MzAwNjUwMDY0MDAyMDAwNjIwMDY1MDA2NjAw
NmYwMDcyMDA2NTAwMjAwMDc0MDA2ODAwNjkwMDczMDAyMDAwNjMwMDYxMDA2ZTAwMjAwMDYyMDA2
NTAwMjAwMDZkMDA2MTAwNjQwMDY1MDAyMDAwNjkwMDZlMDA3NDAwNmYwMDIwMDA2MTAwMjAwMDcw
MDA3MjAwNmYwMDcwMDA2ZjAwNzMwMDYxMDA2YzAwMjAwMDc0MDA2ZjAwMjAwMDQ5MDA1MzAwNGY+
Ci9QYXJlbnQgOTQgMCBSCi9Db3VudCAxCi9GaXJzdCAxMDkgMCBSCi9MYXN0IDEwOSAwIFIKL05l
eHQgMTEwIDAgUgovUHJldiAxMDcgMCBSCi9EZXN0IFs0NyAwIFIgL1hZWiAwIDMwMy4wNSBudWxs
XQo+PgplbmRvYmoKMTA5IDAgb2JqCjw8IC9UaXRsZSA8ZmVmZjAwNDkwMDZkMDA3MDAwNmMwMDY5
MDA2MzAwNjEwMDc0MDA2OTAwNmYwMDZlMDA3MzAwMjAwMDY2MDA2ZjAwNzIwMDIwMDA3NDAwNjgw
MDY1MDAyMDAwNjQwMDY1MDA2NjAwNjkwMDZlMDA2OTAwNzQwMDY5MDA2ZjAwNmUwMDIwMDA2ZjAw
NjYwMDIwMDA2MTAwMjAwMDY2MDA2OTAwNmMwMDY1MDAyMDAwNzMwMDc0MDA3MjAwNjUwMDYxMDA2
ZD4KL1BhcmVudCAxMDggMCBSCi9Db3VudCAwCi9EZXN0IFs1MyAwIFIgL1hZWiAwIDg0MS44OSBu
dWxsXQo+PgplbmRvYmoKMTEwIDAgb2JqCjw8IC9UaXRsZSA8ZmVmZjAwNDEwMDZjMDA3NDAwNjUw
MDcyMDA2ZTAwNjEwMDc0MDA2OTAwNzYwMDY1MDA3MzAwMjAwMDc0MDA2ZjAwMjAwMDc0MDA2ODAw
NjkwMDczMDAyMDAwNzAwMDcyMDA2ZjAwNzAwMDZmMDA3MzAwNjEwMDZjMDAzYT4KL1BhcmVudCA5
NCAwIFIKL0NvdW50IDMKL0ZpcnN0IDExMSAwIFIKL0xhc3QgMTEzIDAgUgovTmV4dCAxMTQgMCBS
Ci9QcmV2IDEwOCAwIFIKL0Rlc3QgWzU2IDAgUiAvWFlaIDAgNzM1LjMgbnVsbF0KPj4KZW5kb2Jq
CjExMSAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDUzMDA3NDAwNjEwMDZlMDA2NDAwNjEwMDcyMDA2
NDAwNjkwMDczMDA2OTAwNmUwMDY3MDAyMDAwNmUwMDZmMDA2ZTAwMmQwMDczMDA3NDAwNjEwMDZl
MDA2NDAwNjEwMDcyMDA2NDAwMjAwMDY1MDA3ODAwNzQwMDY1MDA2ZTAwNzMwMDY5MDA2ZjAwNmUw
MDczPgovUGFyZW50IDExMCAwIFIKL0NvdW50IDAKL05leHQgMTEyIDAgUgovRGVzdCBbNTYgMCBS
IC9YWVogMCA2MTguNDQgbnVsbF0KPj4KZW5kb2JqCjExMiAwIG9iago8PCAvVGl0bGUgPGZlZmYw
MDUwMDA3MjAwNmYwMDc2MDA2OTAwNjQwMDY1MDAyMDAwNjgwMDY5MDA2NzAwNjgwMDY1MDA3MjAw
MjAwMDZjMDA2NTAwNzYwMDY1MDA2YzAwMjAwMDY5MDA2ZTAwNzQwMDY1MDA3MjAwNjYwMDYxMDA2
MzAwNjUwMDczMDAyMDAwNjkwMDZlMDA3MzAwNzQwMDY1MDA2MTAwNjQ+Ci9QYXJlbnQgMTEwIDAg
UgovQ291bnQgMAovTmV4dCAxMTMgMCBSCi9QcmV2IDExMSAwIFIKL0Rlc3QgWzU2IDAgUiAvWFla
IDAgNDAxLjkgbnVsbF0KPj4KZW5kb2JqCjExMyAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDQ0MDA2
ZjAwMjAwMDZlMDA2ZjAwNzQwMDY4MDA2OTAwNmUwMDY3PgovUGFyZW50IDExMCAwIFIKL0NvdW50
IDAKL1ByZXYgMTEyIDAgUgovRGVzdCBbNTYgMCBSIC9YWVogMCAyODYuNyBudWxsXQo+PgplbmRv
YmoKMTE0IDAgb2JqCjw8IC9UaXRsZSA8ZmVmZjAwNDQwMDY5MDA3MzAwNjMwMDc1MDA3MzAwNzMw
MDY5MDA2ZjAwNmUwMDczPgovUGFyZW50IDk0IDAgUgovQ291bnQgMwovRmlyc3QgMTE1IDAgUgov
TGFzdCAxMTcgMCBSCi9OZXh0IDExOCAwIFIKL1ByZXYgMTEwIDAgUgovRGVzdCBbNTYgMCBSIC9Y
WVogMCAxMTUuOTQgbnVsbF0KPj4KZW5kb2JqCjExNSAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDQ4
MDA2ZjAwNzcwMDIwMDA3NDAwNmYwMDIwMDA3MjAwNjUwMDcwMDA3MjAwNjUwMDczMDA2NTAwNmUw
MDc0MDAyMDAwNjEwMDIwMDA2ZTAwNjEwMDc0MDA2OTAwNzYwMDY1MDAyMDAwNjYwMDY5MDA2YzAw
NjUwMDIwMDA2NDAwNjUwMDczMDA2MzAwNzIwMDY5MDA3MDAwNzQwMDZmMDA3Mj4KL1BhcmVudCAx
MTQgMCBSCi9Db3VudCAwCi9OZXh0IDExNiAwIFIKL0Rlc3QgWzY3IDAgUiAvWFlaIDAgODQxLjg5
IG51bGxdCj4+CmVuZG9iagoxMTYgMCBvYmoKPDwgL1RpdGxlIDxmZWZmMDA0MzAwMmIwMDJiMDAy
MDAwNjEwMDZlMDA2NDAwMjAwMDUwMDA2ZjAwNzMwMDY5MDA3OD4KL1BhcmVudCAxMTQgMCBSCi9D
b3VudCAwCi9OZXh0IDExNyAwIFIKL1ByZXYgMTE1IDAgUgovRGVzdCBbNjcgMCBSIC9YWVogMCA0
NjUuNjkgbnVsbF0KPj4KZW5kb2JqCjExNyAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDQ5MDA2ZDAw
NzAwMDZjMDA2NTAwNmQwMDY1MDA2ZTAwNzQwMDYxMDA3NDAwNjkwMDZmMDA2ZTAwMjAwMDZmMDA2
NjAwMjAwMDczMDA3NDAwNjQwMDNhMDAzYTAwNjYwMDY5MDA2YzAwNjUwMDYyMDA3NTAwNjY+Ci9Q
YXJlbnQgMTE0IDAgUgovQ291bnQgMAovUHJldiAxMTYgMCBSCi9EZXN0IFs3MyAwIFIgL1hZWiAw
IDg0MS44OSBudWxsXQo+PgplbmRvYmoKMTE4IDAgb2JqCjw8IC9UaXRsZSA8ZmVmZjAwNDgwMDY5
MDA3MzAwNzQwMDZmMDA3MjAwNzk+Ci9QYXJlbnQgOTQgMCBSCi9Db3VudCAwCi9OZXh0IDExOSAw
IFIKL1ByZXYgMTE0IDAgUgovRGVzdCBbNzMgMCBSIC9YWVogMCA1NDkuMDMgbnVsbF0KPj4KZW5k
b2JqCjExOSAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDczMDA3NTAwNzIwMDc2MDA2NTAwNzkwMDIw
MDA2ZjAwNjYwMDIwMDA2NTAwNzgwMDY5MDA3MzAwNzQwMDY5MDA2ZTAwNjcwMDIwMDA2NjAwNjkw
MDZjMDA2NTAwNjIwMDc1MDA2NjAwMjAwMDY5MDA2ZDAwNzAwMDZjMDA2NTAwNmQwMDY1MDA2ZTAw
NzQwMDYxMDA3NDAwNjkwMDZmMDA2ZTAwNzM+Ci9QYXJlbnQgOTQgMCBSCi9Db3VudCA1Ci9GaXJz
dCAxMjAgMCBSCi9MYXN0IDEyNCAwIFIKL1ByZXYgMTE4IDAgUgovRGVzdCBbNzMgMCBSIC9YWVog
MCAyMTQuMzcgbnVsbF0KPj4KZW5kb2JqCjEyMCAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDYxMDA3
MDAwNjEwMDYzMDA2ODAwNjUwMDIwMDA3MzAwNzQwMDY0MDA2MzAwNzgwMDc4PgovUGFyZW50IDEx
OSAwIFIKL0NvdW50IDAKL05leHQgMTIxIDAgUgovRGVzdCBbODEgMCBSIC9YWVogMCA2NjMuMjEg
bnVsbF0KPj4KZW5kb2JqCjEyMSAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDQ3MDA0ZTAwNTUwMDIw
MDA2YzAwNjkwMDYyMDA3MzAwNzQwMDY0MDA2MzAwMmIwMDJiMDAzMz4KL1BhcmVudCAxMTkgMCBS
Ci9Db3VudCAwCi9OZXh0IDEyMiAwIFIKL1ByZXYgMTIwIDAgUgovRGVzdCBbODEgMCBSIC9YWVog
MCAyNzMuOTUgbnVsbF0KPj4KZW5kb2JqCjEyMiAwIG9iago8PCAvVGl0bGUgPGZlZmYwMDYzMDA2
YzAwNjEwMDZlMDA2NzAwMjAwMDZjMDA2OTAwNjIwMDYzMDA3ODAwNzg+Ci9QYXJlbnQgMTE5IDAg
UgovQ291bnQgMAovTmV4dCAxMjMgMCBSCi9QcmV2IDEyMSAwIFIKL0Rlc3QgWzg1IDAgUiAvWFla
IDAgODQxLjg5IG51bGxdCj4+CmVuZG9iagoxMjMgMCBvYmoKPDwgL1RpdGxlIDxmZWZmMDA2ZjAw
NzAwMDY1MDA2ZTAwMjAwMDc3MDA2MTAwNzQwMDYzMDA2ZjAwNmQwMDIwMDA3NjAwMzI+Ci9QYXJl
bnQgMTE5IDAgUgovQ291bnQgMAovTmV4dCAxMjQgMCBSCi9QcmV2IDEyMiAwIFIKL0Rlc3QgWzg1
IDAgUiAvWFlaIDAgNzE1LjA1IG51bGxdCj4+CmVuZG9iagoxMjQgMCBvYmoKPDwgL1RpdGxlIDxm
ZWZmMDA3NjAwNjkwMDczMDA3NTAwNjEwMDZjMDAyMDAwNjMwMDJiMDAyYj4KL1BhcmVudCAxMTkg
MCBSCi9Db3VudCAwCi9QcmV2IDEyMyAwIFIKL0Rlc3QgWzg1IDAgUiAvWFlaIDAgNTQ4LjA3IG51
bGxdCj4+CmVuZG9iagoxMjUgMCBvYmoKPDwgL051bXMgWzAgPDwgL1AgKGkpCj4+IDEgPDwgL1Ag
KDEpCj4+IDIgPDwgL1AgKDIpCj4+IDMgPDwgL1AgKDMpCj4+IDQgPDwgL1AgKDQpCj4+IDUgPDwg
L1AgKDUpCj4+IDYgPDwgL1AgKDYpCj4+IDcgPDwgL1AgKDcpCj4+IDggPDwgL1AgKDgpCj4+IDkg
PDwgL1AgKDkpCj4+IDEwIDw8IC9QICgxMCkKPj4gMTEgPDwgL1AgKDExKQo+Pl0KPj4KZW5kb2Jq
CjEyNiAwIG9iago8PCAvTGVuZ3RoMSAxMzY1NgovTGVuZ3RoIDg2NTIKL0ZpbHRlciBbL0ZsYXRl
RGVjb2RlXQo+PgpzdHJlYW0KeJyVegl4E+eZ//fNjGRZtmXrsmzJ1mFZli8dtixfsuTbFvKBD1k+
MZZvg20ZHwHjEkoIoUDIUSglhAUaiJcmPJSmLLmzeZKQtJvNdtOEpkmWTXnStE2aJdmU5p8H7OH/
zoyMhXHSrvx8Hs03M+/7fr/3/jQII4SEyIp4aKJvzD/R7Yv5BmbOIIQlQ6Ozg+75yBz4/jJCaddG
A33+g9v2/BmhjPNwzxPDY9NbNiXHdSOU2QP3NAwPD/hj3uUfR8h0Dq4nj/m3TKBRPArn78K5dm2z
Jfub1+7fDOfX4LxnIjA1LdAKhhEye+H838b9YwO6oRkjQhYtQjwayPWLfSdrEbLDOcqFgREjL0KR
8JWP/u4HEyQFlPhhgnBhRGSUKDpGLJHK5LGKuHilKiFRjTRaXZI+2ZBiTE1Lz8g0mS3WrGwbyrGz
zFAeyi8odBQ5XcUlpWXlFZVV1e41nprauvq1DY1/n/nSp+kfv5X9NP+f7ibQOze/wpd4FxCJFAhJ
baSezHERtmw1IZeJCH2Smbh81d3dJNNbVEqLXi7XW5Qqi17Gu3Djj/SVVLtWJNLaU425zDGXpTdD
XiJ+zdILAwSBHju+ft/VTZfBP94FWoOv0Br2XhtCVBV7L5xjnVSH5TpSL2WG3m5jh43UwbDJ9STe
iRNr6Y8JO03Xz9XTH9fN1b/4Tv1Hf/Nsq4ULc7W/+n0NEY8fpgOzdA8+wYxZ/PAsPkCPMWOWDjDr
JZHn5ue8y7w3kQvVox6EdEYRyazSDqvOM5P2kMWHYRfpxDq5Pgm+i3CYQk06sNyQDTdiESmXqQmc
YwaI+MxXhYukDj1haB/dWT/39GyRpWXWY3QYZZndBwZ797YaU5p3duMZkSSCwpukSWUFpiiJRf9S
tDbDkS5ZGCoa8rkTaYelxp6Q2TiBzTLTmpzO3hh9rrGovTDhfPqaXI1r0zF/645ej8bc4m3Lrhhv
yDA3bHCUDfrqUukZ8/rOVkODT5CYZyk7UvdmtCyS8nXHZzqT8SfK4ubhspqptamUO63Kpt7QZqwo
d2coCyu94AugK1zP4s9qfiaoH8R4ygx9ndjJlyE5nDDrk5sJAEniwnlyEYk90pJtI/t/ub2wcPsv
949sK5ESe7ZevXS+pDv/xGWse/ZZrPmv4/ldJb949ypDqwxoNQRpAWRGu5qQyGUEYGp3kXhOWvo9
oHW3w3E30PpeKUvr3V+UdOUf/y/6yrPP0h9dPpHfXXL+EkvLS/LJE0BLDDLn8UgbaVBE4TCDVC/l
GQ1eN3bYnyrATjc9jzvc9KsFT9noN9y4jbr22Bu4kn7x5eMD/cf+lX4BV7x6YpBd5y5sIK9RB1AE
nIj1Yp1dJ7aJdXJido7ejWfn8Bxxgt6F52bxVvq+WbjfSV/E+7GA8RYDYyR2F7bnmCl7Ti5jN3h/
cuP2roHu2KSUpNi6Am1+ZryvdOtws8qn7SqSqeSyhDSNw6UwlbO8bfgK4SbmWPztOrmNkOMrR44g
9tp28MsdwEcKgWSFR25f6Y3b7nBEiHM3BUQ94AS0FeCDs7P4vc3fhEWyftd183MqEXxAioyMdkER
QBZz6gVGWMIDjdvA0O2sgYsIKtGx5fzs3Rdm8vNnnt6+5RdbHIuyhOIhT81gsUpVPOCpGSpJIC7/
lP7s9dHR17HiiSew7LUNG16j//Lk4S8eb219/IvDh6+eamk5dZVb225wxLd5LzFeb7OzfMSMF6aA
NRRjmxiYg6Nd3KN3mlTGqhKn2lSoKa5utj20U2l26vt9Qk2hlcqx1udrnFkChcFu2HAjw1qoEfoY
2pAPyI9hbRZmZYwT64A+UCV1dvDnpQXJgy7PwEqeM7dtbwSDed9clCIPE/iECw9iX1OgQh1vW5tb
1ZotMZRYVbaBQ33+I6MF1Iz7Bw8eaad3KNPz1Ab62CG8b/2hXdurHOsrDdnecWekxmZ0DHjSstrv
Zte6GbAmQB4P2EsQ0QxsDwU3VBY27qh5cKC4qJRrY+LMgnPcm23r2esrLa2Yac2Oszc7qtqCcg2C
XMc2ubLatlSn+Lx1Dn1m3eD0VsfAD9ebqhz6Mn9HUv3dXaUjnrRhU9PMmqLusqRQMTObZ+srt/ZV
iSlpcm79UEXTPf6KdKnB1WxyVeZ2lhlYe9FDnO6COBHH2ouc04+OXQQESDuozCbHTAAV8QBvsltl
ciWpFn9cyChwcQ8x+wpNuwiSR4UpdQaDNpJ+Hf8BP3yaVRmrzNNe8u2F+il81TQ6EbCKLIUlTruE
jmPx23Tzc9DneWRfxo8NyEapTqo3mkm9jmSN9pZ3LGH2afHGtZmZTZPV9jpHpjSrjDgj9AnIiLg0
LT1l1Mx09j15d3X59mdmJn/UllxcpnGu69c37vI3bmkwCqJiBCLiEv2mM1YjF9KuiNjc0ZOjw2fm
yo1Fa5IKSjJr87QsLttAtzGg23RUCKImEaSLDJGEcSgXxU3w9SA3ycithlty7TkpxIEjxyLine6W
7O7DGwsdm06ODJ7d7k4sbNt8qMO33ZvWUCfNrJhN9ZTmygljVb9zfGobb5h+m74kNyZKCkeP9o6e
3+FueRpr/s3/3Pz9A/nJRfVpjpLs1lLD4mm5LkN+5IO9JU8+97MTDIazoD8FYCiEfId1SdEYcqwc
413448U/joeDwZMHaQEvZngQTzqu7+byZDesTQVrM6ICVAfxaZX8qCaXMOcFNWMU4eW8CJbNJcZu
i3eyvLC3ypi94ad39Rwayk11D7pqt3VkVX3/wsTU2RkH/rB8rC49xbenzz+prxzG1vi89tKC9iIN
nFQU1mRKcMATaK3S6uq6xkqq7x102bt31JUPNpZqkpt6Jsr9j2zIKxrZ/26au9+R0968NiNnfrpk
uCaNMlg6qjMMpR32vDZ3sTbRuaaVq3mGb35KLrB6czJWJZEu1wBs+Atxvzw1KXWReXYwNC7R43ee
eEwY66jpzG3/0UZH0aaTQ8Nnv1+tKmifO9HXOlWekKIQpTlq78tuLrGIiNQqv2Nss7qovQNbcY4q
26jIGT46HHh2V03DaXrh/Ma3LhwOODXZJdqUHIHWYVISTVhlKtJRu1+9u+ilf/FuqdWz8s5DLjhN
ebl4vTIbiFecz6/MDn8vW5BTyxM6kUjH1XG9kOeeAp4KlLF6plvBFj91R+ajr61kvXouJN13CAB5
GV2BvPw+4jO5EcvDsXwXGVhsIM4Rz7jx+3voffSDexg5d+FL5DXySrDehKjEDPLawsNkYOFhoh7y
3oHZ2dvp5dnDMdy2izi32EAGruzBm/DMHtroZtfddvMr8jDYhgHsHmG9ePWcwdr/ykqZEG5rn12j
Uea2OEpac+MMLpPStP6hPv+pLRX2wYPrX1mJBj6K85LXB2ad9lZnUrp7vV2sy9ZleV367PV727x7
J7uNi9fvLLFBRvjwTkE8TmazXBjjdLG3InIetmG2UmVOIdBYMGnGUOWGkTp8rD5cWF5poSON6vQk
jRS/fgL/OjI+KVOtWnzLMhcuaDqltYvDpLEJkn34P/Cn78VZxDlWny8q2ZVFvXwjSpseDxG7V5ys
+AS/1XncY6h0r7XSu9l4UQ8x5iWQSYfMyBHMvXImQlBpwXQn5lKfTkth252ZMANTO4wV63KrppvN
9AL99eIxpd5pVqrMziQlYcBCTC12v9G6pTZJvWZLx5sPdGxxa5JqZ1v3UO7K4Xq7RBBZuG574+sX
2XxCfm7KU4f7fn7Dr62ebGq4qz5lUFu+wVMz4FJytS3EtlPBGmFJfyEhi0VRjUPCONRFJH/k0SGb
ylqaEl/QWT792KDZOvyTTTVTbeVKcax9dH7ykT//U4P38a95b+pd3iyd3SCzdtdYWk5+cWTPH052
JFqLkyJSNMbGsgwokGJ/Oo9lr4+zugTceExuVYLFBWsx3e14MREJMxMxcCrmdXnnr//z4v4QdKaO
ffNkx6J969NbnX/963ni8mn6f/91KBQI/3P0lwuXm098dhhn4bIbcQwGjL7mgS9EFMNyiXQb42B+
hWpYhz/C+7IqzUqeaKPoxgVlktOsYmoxJSUQbhBSioxSM30aX6Ulg4xEbfQRX3hCnom8yqZ4+kgb
c//iR/1LfHuAL7NahrI4tJpYwRq4Ak2mmqhY3MkyZRfMMY0zVVh5DYvn+uk6rpJgWX7NLhhYMrVH
UNe8B0HX4M28pOQURpm5ybZVtZ6bt8Se7fnkYhEm7U/R/+9nvs5/wZE/n/zppny1rTI1AXLLPU9P
5+RufeV+RyCDEUlAyASJOSmxQx/IltW70g4eufqYNzIKe0x5iWzd47DSD1nNQUz4QsAEuoIlHL4F
l6BguhXn3L3kBRVbcQ1y9deZEBPxqpJcJhVxRGVy6lWEd/kKayb497R2uRoLGg37ne7Fx5avLEhM
eQnhPhSUmXgMZA6p4VeTqZ5lxdpKUAhWOI7RH0JIJwQreKB981NaxtJOhMCyKmkRnCmkZUNVhtDl
ue9+sldPzxhaHx6l/rS8hhv6vU+PLeHMewrolsAJE9dT9ECSKcrCsRqDsEwQN+Kw74Se3K3LjI/I
tuGL+tLSylT6PXzOMVZAxQ7d21GeQh8/u4T9LWsNCkdtSnFYk6OVUq9XlVVtop9anG9s9sWkV+fh
6/vp1+4wYVb0xZdQqK/qvg3rJQdegTaIgA+aS9MVlGyj6DbIw9V5phsP6+xlukdo9xKPMBvwyF2y
wTwx1uPVoQjHtyuZJwkDQ48l6IwAbZAZ85L4tHEZAPwOPo1P4deXZfOFq2zpVNX1j3nxN/7zjpXf
GKMO3GETrO6ugHyZTA27ulh4BSrU/kXEqYNeNni8mbjMfFERBDtJHV2ou8P2bxwk94UYkA3i9BTE
kTneW/94z8yb85768tGTX51oaDhx7eSjV095b3xo6j8+OXm8LzOz758mJ08MmG7vmeWvbdx4MbRn
/uKUz3fqC7SUJ6hdsH49st5hBcFolrGEC7mcVOtDgkDxjpe+5yy45zeHdzDnFZ+PrbvXa2SS6L7Q
tTsCx/o7T++oo+dZZyeOGFv3+JmOhJNjik5jcdCinGCWZ4sN1nWWtoi+BY+yHS9uDc+uH3bp2hp/
cm+7cP/beyu/C5tDCy9vix3Z35LckzHys3ujN7+Kw45/B0pcLq0FjNgKxBDi0vrVDUZLsXWcIaQG
CeT0lvITe+Z8Tj39lydYQ7nNmY1MJWL3jebSex5aqkH2XW9q8olS3YX4LbqDBS3UnC++3jTXUSSx
pDZsaWiaWqMDW+6FnvYryEnFTE7iOtZgW8iAGNJk8UMTlILrt/D1/keGcuqqSV3ZoHvvo1rPbMf6
B7rN5VtO+bse6LW1ehS5baWOdSVJ2pqt7R37e3Oq731Oll6zscRVW3JXR+6ubfm+NeUGY/vYfd62
veuzU0qaTWXl1nVrzDqnz+5cV1OebGga2LaWaaoYv0sL1nV6pgu4DURGLraVZJN1BibeZ5zNsrjT
wsD1mslplFIRkKh3MNlaluIyv/Hpsq9Tm9hKAQ8GqwPWxzXgY8eAlz2Iy50Z5VuyAfHJ7Mu7qkLD
ra1zW037jpY0bo5g50q3vyCzBX62jVQt+/bClfZt9cnWlpkq0hIye2nw5KYiViYJQgJmjzQfISZL
KFw4T8rmjlsShGF9OIRKBgJ2BtrEWIU0eCt1FKNEkyjamHCeFPB55RUWfM2oNiWro+n5Z+in6Dde
pPcI45PMahWRY3E5hfwXlGZxdJrqGu/0wp7B56s9J/uILZFqtTLcbvH5IpNcthvF1NyNXdQ1bXoc
YGmxQTW+uGndLzwNL/aRAS5WxgB+eSBzLbffuixpMM9xnQHYWgS7kR3SO4RjM16GljE6FYba9zlx
YmocH78sUWeZsxIh582aGozKxfcitvJEKvmbH4dLYoSlFXw6LsqQZzEnYB991rDOrCIy+HqzUkgK
peJnX1Ek8AwSRRTP5xPp89Np7+JjRVk+X0VErDozCVfR56J0yYYYfaLPF52Um4o/IwwOuBweExsZ
IVMlq+hL2Kh3wdo8YI+DsDYFo4+QvT3dkjVSVQs0QZldKTIKDO/GVRLR5SYnd0a+yeu9QQVr1CaK
DtogU3N8TV8mL9z0MfulWGfXkRcWSsiX6cuzTFwZhH4hjepGIsZjsSyW2/gKE5FSti1MueWwS2HG
qF/aUcgtZppmApsaW1wD1Sk7W2fcmm8ca9JELe2FA/fVdt/fbRGpsyBh/kUr1ha5O0sqZlqsf/7L
E5GpNTitZ32qZ0PpPJ/SF3cRB3RFTdbCarvHEmvw7u5d/J+M/CSR71yGOyfR2DjnPXksjD+Xt67c
APIaQN5ZvgyZUCkXo9koqA9bEf7EMn4YP8zGbVrhkOaHkZiazdtwdMDRU+eIjUqmn4lhKksGrhg8
S8BHoCis7SkaOLohj3Y0bCxRqUo3NlasdyYkOP2E8eDv7i9XWstST3BbtR6uJv+BvjPdarPU2hPL
9/0WMB49Fdh4aqKgYOLx0bGTo7nBvb4TgHPaUlxcJQ7GMnU615wRFYNnvldZOffP/pLtgyVdnTHG
8hzH+orkhx9f/4A+WpbZeo+s+AeXfnzq8n358Tlr7dWFVl+pIXP0wp4PfttQHJmaoK/K5/ZXgC91
kcWreDnKLeuQk0JhSzGasXPJoXDoDq4slopkwBHTj8cKFA4OmdxcDsCi2EiSJFirE+NZOq1hYynA
NdpY3uNMuOsKi80zlhoWlQNLyGVnptRITrPXrndySAUKCyce3/jB7zh5ySuAk4BBCifxw3Ts7iLI
GiNhRE3EOjUZ0sUStsm5CPxeXE6LIfDzraWff9B3bNyx6CPS6ibW2Ds9BRJRfGbHbvLLZ59qvK8n
58ZCzUNv78IanOSae3q2e+Inw1lxqbYEfopSU12UysQXSAzkTn4aygK0ltOB3Ra6O7KkMZCFa/Js
xLnF3WyD8vzz2d33eRvGy9XxJqchSpNjzHQkR2Md/RGTQHzBSgz5B7vu78mSp+RoEzISozUOc0JS
eW/prH8RMWmE2XOw0DLKTu1BrWgUbQ1aOveTXNit9p0wcr/VOW51+py/spuZuSFbmoqgH4T4QAbj
FFLO35luIYlP2aOUaQn8aKVcmS7Tm8yd+9YxwVkgS1bFSJMsqj93fb/RUHrfW/t++256dZdNnqqV
lVRlVlrirT0P+Q1uZ1Z0dGq2I0ljUkcvnIgrGqwff9CbpLLX236V0Vicsrm1L7syU+rt72uhNLHG
RHFknDwqMipjpq12R7cdYxIL49Qpini1mGdu3FTW9kBf7rH9RR0lqeHh6vRcnbM9XVLc2GNrv783
J0IaFxVj1MWKE4034kz1+VpDWWeuxakXRafXkj07t6pd/vK99+7m8gX04tSHYP+Fofq8PUjk3hbf
xEuGzym2dvH9lfFB2PV26+4ua1x6IcS2o3F2n6tknVPN3BDU71JUcCU4lerE5yz+wyM0V+8Tr5YP
uw2W1rkauoGppri60wL/ZkDGOKYDyLtdwmBZIl2xH+dZKtv4eJzrA56bl2jT4+PSNVKpJj0uPl0r
YYsRYg/IIvQtHOfqE15JslUdGam2JsMxKkoNBTdx80+0DD8B/GNROrNzwZbbtyG1kjs+VjT6o3Zd
dJ7PoWGF+KFEkxEXl8HwZo8SynNjnmlN/UzHSm5lZcC1d/Dm9HMOeBdxNchSWUuGyVctazmVhXS4
/DDiAhbbRyr5ie1T3qqMt37MCnSn1jDSZSiFWTb8WvWeBuIAvbHJ54tIW1uBSyee5QrbENUtfJbQ
mm614zhDfrouWhnt8/V3cvYE1RzRw+rqWzRlX+KrxOxvesrF50MpX7/EKYKhVQB9qQ9iXesqtqkI
5q6l4+r2uYrB9iy+r9IXpitY88SlKqGmoq7Fmt1R55SKNe7Gdmv993zmoO0qbE3Mdq4i5LS8Mz8u
xJSJ7azq5gvWpEHWqbYxxzvsOcs77qKLQyZyu7aU3TJwdp3Ul7DO/O9Y53csR7yEKB/XqITa6rXt
WY3b2y0KEDqMfpTxv6r1hfHfIvQdwt4mG5cfTSBbNNMF4BjuZzYu1dzxS7Hpb58Hzs2V/vUq839R
qC7fWFe3oSxRXcYe1YSR/oj+Y9UD7z0ECSaucv+lhybPzhQVzZydnDwzVVg4dYbhp4K4Pgv8pEy1
t7IwWa5nYqEjSsSrusASYsT5FcUJ3nGrrBGAvcNnpSso8aB8ubohP1xZp9C1S0nabpamJScKXjPl
JYZzG3rUBhbUZ4NFDosdrOUirCUHVbGVJVc7QubJzbujwMi7bVtlZYVxcfHRCkZIrvy6s8gwYLeY
3WBjCo3FidvKDFrGyneOKcGyVxYbJ9hrNw4xshO8FdUGY5sVkGznYQ2Q71du5nNAx3IZHzKkiApK
TxxY/Dl/2SgdRqEs3dlRMTEmN7tzrEUpRSaNVMBcKwg1xzfNjU59fbU21yhvqcmo7vL3GOmXbvlI
F9Q9ZVQXU9Xeqg9DLGNl65yysnM+W7etzaoymiSxOS2uPG+BWlHQ61k7U5uSN/hA65qJ2pS66pbO
HCiwwVAqGqdrkgs3/EimymvMTcvTRuV2V6epsirTUvKs2Vp9aa2/vGp0TYraVpmSXz40GZdZlGws
sJoSksrqe0satjSmgrzGm58Tj/GqmD1SA1St8qC+oVSCM+gObXK2NoolNAaXNio9KzeufsKtP2po
T9JnxHTjSPpaS5uA38GPDOfpPFvbiDNNan3KyNqFmcX6kV6gbwG//ITysHXYyqo1NObepjEqj9UI
/TxEvRpvV3bj3T4Tp6OAPKvZVeEvVjO7xJAzP2JD/nyhOy3a3Ht4BP+FVdGik4kQ1tatHjxvddza
nxNA/DoKsli4d1lutcEkYyHQMuMVLTP0y3oBgZQup0CwLyohXkaF8RSJGtEBYXh5RTR+Op79hYp+
8Xn66UhlUqaavObzWW1ivYLeltzqrVHGltY1GPCD8WaxPfgL1cIZcjfzCxUnD4EQ/2OQh+nYOCnw
KlKQxlU696DI5K/filTFyXj88FTNoCCivFKELyjVmXpo3b85dc1A//dj9DVWND6+rnK6Ivg9wlhp
DI/PEyuUUZeoisWfGFqaPUrbj/qwR+lgxYzUu2wLZ4i3dy+c5mT1+ZKzxVYFfdrQ1lqrVFaubTIQ
G1n5YRnUIZDfzfTwITKTt7fwFqYN/a4WPlaDwdRISbGF698t2Zp3sMnUmKJa/EI4x5eo4/Y8GC6L
ERZWQvsuNeRnZ6sxQdOmFmjfBWz7Hq/YvUGRQD5jUECQS8hJo/9Eb+Rad4UmU/vMLyO1SXq2cY9U
21JwPe6x50PjLo6NlKdpn3kEmnbOPiAO7oL1MG9KBNEX8UBO9hfL1TQQoi5qF1+doVdL6F8ll1Q1
b9jbKRk+NLYmnt4lUuoyAP7P+S5nWPghkUYVS/EjjMo94WBDfMrDmcWpvkMbq9Jj/K7RAz5yuzZN
KVyypAP65ka30rTDs2RHICeYM3kK5FRw75us3F2QY+KZZItGGib0CRdeIJrol1NzdPIIwicjxYtn
ZhLMTp2FPt9E7pSnu9IEWO9d2M6tvx+fI3ZQBPM+18pKsT/N3V+Y3+tJT/f05hf2u9OI972TlWp1
5aTXu6lKra7axLx3Rk7h/dy+B/6H3jvjUd/24hn7SUUutAXROBJn4zb8fXwYv4T/HX+OrxOFxDBx
jpSQDeQx8isqktpK/YYXyavl9fCmeT/gfcBP5m/lv8xfCMsPmwh7RZAg8AjuEvwmnAr3hh8Mf1cY
JxwUPhcRE1EV8VDEZ5FtkfdG/jDys6iqqHuiPhApRd3RRLQ3+mD0b2LSYxpiXhNLxB7xOYlE4pOc
lfy3NFk6Kv13WY7sB7Lzsndl1xETVBAhg/EEeoesQDPULLLxvkQe/CqaIS6yo4xCyAvzu8DhncQc
ssFxO8Hsls+iLhi7YQzD2AxDD2MTjG0wZmF0M9cID5qH0cvQuDUQauOdgizjQPXUp2iG9zYcF2A8
g5i9wBl+G6onvoTx4c1PeUe4a2E7UD1fBde/RFPUJe7IK4ZrHUD7TyiN9wLSCHqQhOdGMdQLyEOe
ufk1tQMNAn0D+SXI9SkMN9pEXEN5VD2y8GTIQDyILMTgzT9RZ+H7HFKFPYgKeGmogDrG3q9iniEv
ogryKOoi3kZGeMZCPYYE/E8QQZ1AQmoXElAK5CM+Qf0MPsx7gYL9i6cREnrpWro+/JvgG9HLHy87
40VnUQx6AfFWXCfgnKK+wA/BFcQ7wrOBNaq5I/mfaBB/RSAigkdQPIogqN9D21SCttyE59gfD6rX
rq1GJUhI3+RkEOwn2rQIH//oPdCWB3BFSMtFbuZzcxANrvrOspd934ACCfgoHOJkBIpEUUgE1WkM
EiMJeBjzpmkseEocikdK6EYSUCJSQxbWIh1KQsnQT6UgI3hAGvRyGdBPmpAZ8pYV8mg2skGlxrzA
nQeVeCFyAGZlUP9UQvVWDbF4DVSkNagW1aF6tBY1oEbUhJpBohaIG62oDbWjDtSJutA6tBs9zUqb
iHtvYWhhJccUU810wxk3z8T6/cF5DLL/ODhPoDD0ZHCegPU9FZwnYTUvB+dJkPFycJ5CQqwIzlNI
hnXBeR6KxvbgPA+pcUVwno9ibskWhpLwZPCeMFSBDwbnBUiOfxecF6B0/D/B+XAkI5Z4haNUIiM4
LwR7bQ7OC1E3cU9wPgKpid8H5yNQEUHfehNfTRYG5yNREdkWnI9CZvJgcD4KdZGvBOdFKJ1SB+dF
4Pfu8sDE7OTI0PC0Ntuala2tDgSGRge0a8b7zNrS0VFtE3NpSts0MDUweddAvxmVowCaQLNoEo2g
ITSMpsEosoOq14KKA/A3hEbRAJytQeOoD0xDCwXnKPxpQdlLT02xZwNwHABad8H/fmSuD0wHtM0D
kyODYB4BuCsAdzWzd4ygwaaBoZlR/yT72BCaAYJ+NFkXGA9Mz06AyGP+oZHxIa1JG0KlDiiMs5Rm
QWpOpjF4bAjojcN/LZiudjVe3y2Jb2ByaiQwrs0yW3O0M8Ngu8yFKbjEsNMCGGaAJAe+zaDh3vws
e39vBkORJciSHpnS+rXTk/7+gTH/5EZtYDAU+RCWIyxQfhjTwMEPIA2wC5hEG2EuAB7+LaDfgQtL
+O/jsfLxioGpkaFx7fSAf2yVpytYDTI6HWdFHABaYxX+ab92Znx4ZHwaLCZIYaBf2zurvUW2P4Rs
BTw0za5xBsgMs6JMcwaxggUzp0W9wF67ijD9qwkzPD09UWix9AX6B8xDLMTmvsCYZcICggQsrClO
w/OFEE0ssPAAS8UMNJYxNbPzY3B9AsZ4UDeWIOXNmzebx4LLYklPTc/0jwRWUN7M/pmByu1SL9Oe
grkZ4A42VDvSNzA+BYjNjPcPTGqnhwe0pRP+PjgEr2Rqlyww22yFaDoCVAaA7lQQIQbHftYmGRyG
WXRKgZ8f7uPObn8mE2ZW2nA2Y8Mha/SzEpgDk0OWUU6KKUvtmvLK+uZKEyPF6uv1h3A1A+VJwNQC
qIZyn4KZWjC8csgS9eBkleCULHc2tsMQOl85GLd+fXTR34gIARvG3rk+/7ulI+RhFP6NoBdx5Q77
+f8S8KV0CmVuZHN0cmVhbQplbmRvYmoKMTI3IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRv
cgovRm9udE5hbWUgL2I4MTVkYitOb3RvU2VyaWYKL0ZvbnRGaWxlMiAxMjYgMCBSCi9Gb250QkJv
eCBbLTIxMiAtMjUwIDEyNDYgMTA0N10KL0ZsYWdzIDYKL1N0ZW1WIDAKL0l0YWxpY0FuZ2xlIDAu
MAovQXNjZW50IDEwNjgKL0Rlc2NlbnQgLTI5MgovQ2FwSGVpZ2h0IDE0NjIKL1hIZWlnaHQgMTA5
OAo+PgplbmRvYmoKMTI4IDAgb2JqCjw8IC9MZW5ndGggMTI4NgovRmlsdGVyIFsvRmxhdGVEZWNv
ZGVdCj4+CnN0cmVhbQp4nGXXy27bRhiG4b2uQst0EUhzJgHDQJFuvOgBdXsBc3QE1JIgKwvfffm9
E6RpGyDGL4mceb5fwyF1+PT009P5dN8ffrtd6nO/78fp3G797fLlVvu+9JfTeWfsvp3q/esr/tbX
fN0dtpOf39/u/fXpPC77h4fd4fftw7f77X3/4cd2Kf2H3eHXW+u30/ll/+HPT8/b6+cv1+tf/bWf
7/vj7vFx3/rYBvo5X3/Jr31/4LSPT237/HR//7id888Rf7xf+97y2kxMvbT+ds213/L5pe8ejsfH
hzEed/3c/vOROR7nKWXUz/k2Dz1u/x630lAalZbSqnSUTqWn9CoDZVAZKaPKRJlULpSLypVyVZkp
s8pCWVRWyqqyUTaVnbKrHJRbogeD18hr8Bp5DV4jr8Fr5DV4jbwGr5HX4DXyGrxGXoPXyGvwGnkN
XiOvwWvkNXiNvAavkdfgNfIavEZei9fKa/FaeS1eK6/Fa+W1eK28Fq+V1+K18lq8Vl6L18pr8Vp5
LV4rr8Vr5bV4rbwWr5XX4rXyWrxWXofXyevwOnkdXievw+vkdXidvA6vk9fhdfI6vE5eh9fJ6/A6
eR1eJ6/D6+R1eJ28Dq+T1+F18jq8Tl6P18vr8Xp5PV4vr8fr5fV4vbwer5fX4/XyerxeXo/Xy+vx
enk9Xi+vx+vl9Xi9vB6vl9fj9fJ6vF7egDfIG/AGeQPeIG/AG+QNeIO8AW+QN+AN8ga8Qd6AN8gb
8AZ5A94gb8Ab5A14g7wBb5A34A3yBrxB3og3yhvxRnkj3ihvxLv91W7zdVf53y4TSRKVJJIkKkkk
SVSSSJKoJJEkUUkiSaKSRJJEJYkkiUoSSRKVJJIkKkkkSVSSSJKoJIkkSUkSSZKSJJIkJUkkSep8
wpvkTXiTvAlvkjfhTfImvEnehDfJm/AmeRPeJG/Cm+RNeJO8CW+SN+FN8i54F3kXvFWGBW/VxAve
qtkWvE2BFrxNyAVv02wL3s4BeDvj4u0Kv+DtSrzg7erDgrczMd7OxHg7E+PtCr/i7Uq84u1KvOLt
irni7eKseLsSr3i7Eq94h5Ar3iHDincIueIdQq54h2KueIeQK96BAe8QcsU74OAdMuTNa+fOnPEW
SrxZs2W8WYaMNyt8DpzGAXiLDBlvU4qMNytbxptlyJvXmnka3qIUGW9W+/LmtZYLLeOtjIu36YAi
r+X+UqZXjSqW0zRYcZTqQ5leSvpbKKMO4K5eEoMxwsK7ohd5XZWhyGu5fRS8WU0teAul+uvIVuZ6
kLfM/spbWQ9F41a8WbPV2V99ARUvN9cqr1klq+qvZeOt06txK/3dOvfdLhPivzeZSuOLyNtFoS+J
M1koWZkqQYhXCVL13VYWSlODqoIYtuE6KHVAY6HwRLFdYSrV7WYpFaQ5Sq3x5imlbywUHiPaXNha
Pk2ND1Wh21zYalBT4w17SFPj502qFZX0aruIt5J7ZmuUjLB5R+GJbVt6KkXvc2Hr3T4Xiibu06vT
+vRqJXW83O47C6UyAl6QncZXBsNb1d/Owq7ydvpbFb7P/jLu7K+ydfpblaKzUJo62efCVsyhp9WF
Pgy8TYbBQmkyDC7EponH3OjUhyGv4fFkyGu5YIa8lj1vzAuRcVfelXdkSkYolEwxFzYHNN5VoNEp
mXgwRfp+AerxWj8Avj221y+32/bEzq8EHtX1kH46928/JK6Xq87S/78B54bzTwplbmRzdHJlYW0K
ZW5kb2JqCjEyOSAwIG9iagpbMjU5IDMzMyA0MDggNTU5IDEwMDAgMTAwMCA3NDIgMjIwIDM0NiAz
NDYgNTAwIDU1OSAyNTAgMzEwIDI1MCAyODggNTU5IDU1OSA1NTkgNTU5IDU1OSA1NTkgNTU5IDU1
OSA1NTkgNTU5IDI4NiAyODYgNTU5IDU1OSA1NTkgNTAwIDEwMDAgNzA1IDY1MyA2MTMgNzI3IDYy
MyA1ODkgNzEzIDc5MiAzNjcgMzU2IDcwMCA2MjMgOTM3IDc2MyA3NDIgNjA0IDc0MiA2NTUgNTQz
IDYxMiA3MTYgMTAwMCAxMDQ2IDY2MCAxMDAwIDU5MSAxMDAwIDEwMDAgMTAwMCAxMDAwIDQ1OCAx
MDAwIDU2MiA2MTMgNDkyIDYxMyA1MzUgMzY5IDUzOCA2MzQgMzE5IDI5OSA1ODQgMzEwIDk0NCA2
NDUgNTc3IDYxMyA2MTMgNDcxIDQ1MSAzNTIgNjM0IDU3OSA4NjEgNTc4IDU2NCA1MTEgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMzYxIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAyNTAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDBdCmVuZG9iagoxMzAgMCBvYmoKPDwgL0xlbmd0
aDEgOTU4NAovTGVuZ3RoIDYyNDIKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQo+PgpzdHJlYW0KeJy9
WXl4W9WVv/e9J1mWbdmStdiSLWuXZVmLtVqWZXmN991RnMQ4lm15iSXLK+CGQAMkISQhZIGmKYEM
TcNSJgTKUGbKdBjCAFOa0pRJIdBA+aYNHy3t1zIMH03slznvSU4cE6B/jW353Xvefff87jm/e865
eggjhPjIjjhoaigWnuLWmyZA8hRCWDQaXRiR8KrXQPslhBRUND4UPjrw4CGE8l6BMSNjsblbP1/H
vweh/GLovz42FgkL27nHof8Z9HWx8K1TqAnPIaTMgb6qvdvm+Ntf9n0f+qXQH5iKz85xOjh/hP5h
6O+YDMciL5j+9yRCBSqEuDkw3bDwV98PI6RnxnvggxGDF6F0aHLRN/7gqy2CRBRz5SSfSklceKn8
tPQMQWYWQkJRtliCpDKUc/WhXCRX5OUrC1RqDdLq9AZjoanIXGyx2uwl36z7/+kHowbiL+SLXDES
IpTt5ZBOUi/LwCn6bG02x6hv6MMltRebsLOP/ncc7KPPNPyumj7bh4PUuTcv4Fb6x+fOdHS9cY7+
J9x6/o0edr7tWE9+Rh1EadARaoVqt1roFKolxPaD9EEcO4jjxEH6AJ6EP/rAARjvxKeJBuIIIkG/
Wy1xEhJ8+u23k9gQohScN5AZOmIBlYnVDk8QO0m1G1eQbpdBq+FKNFbC7aognA4lQX4kKem4+ejo
GXwhuF4kXEhbLMW2Td9ak7e2eaynLFxn8E09MTX79C3l1C32DQMT2x4Kn26sC9Jdb2F3+KH7drfP
R3/0tNTe6i0dbrHYem9PYPBd+YTFUAveX9YlVoK+CmhbCTN2J5oARkBINIZlMBKxgEhRkswFfzr3
2IQzzx7U6qtvKnVsXGMydd7cesfO6sFKVajHW2cQfPte38wTU7Gnt1Tbe2ZqKrZtrr3pe6+JC2vX
243lJnHVYLU6r3a+1z9YX3iHuSNeM3W7Z8NM+fp+z6b6wuLQbR11c311srSSntt7tz45ymwmRKB9
V/6CP6D6UDYyIuRdAUoLqxCu6u+TWyq0moBVobAGNNoKi3x1/6AtaMjKMgRt1gqDUGioILuvCoKM
IMjq5MG+43KeRyZmt+EUAZaApfxYomZt5MVqrCSvdsFkNkxaSaOATCHV+Kd+njBLrhaFlv6Yq7AY
tSL8Is7FT2WqjcU5+qW+jkxVblY6t+GBNJlMwkvNUSjSF/DD+MNTuTW5YmU2PxZLV5dZqecuN5l9
akEslpqtlORahWfwGW1rR7uuoKmtTUefAJb5wI8ywKhGVuRneUWkSBg/UaakK4UJt6pVFP6Sl5km
dV5fu6msfn6tjX6X/s1StEdmzBMK843SHiKEddiwNHhP7UC5Iqesv35PW8MmX46ifKCuiaqujTS6
RHxRcOOtzT97LZaa5yomz5mceWnR5y5vUdZE25rjDbqtyuDwmjX9Zbks96avfMLhAvdsEMMYAypx
wmE6A0AReXRXXQi4WPqBucmR5vm+OnlWtjX67F3P0p+f6t3wDE49efPTc2XqqoEKqTtUGd7RqSse
PLpPW7pGk+6Qmzd1uKKvYukTJ7D41Ul95TqHocqucEa6nF0Pf3To0PsHGxnfMnZ7FuwmR3rGagSX
0qqvt5eDkoo4WdAUMmLOs30/pv/6o6W+kMyQl5WVb5CGiONP4oyfDNEn3j47Pzt+bMJDfP44/fHr
8YQt3jOVyFOj65+hvziJ9Vh5ec264x8z+w9iwBegF7Tq1TBvYv9fpzhba7RirRqijJoI4CMFxaps
TtZ9mZc7QlJDflZWnkEWoqZ5+/i88iD9GL5Iy7fKinyaAXpnjJdbUki+X+zKS43SO8PNHTTagpI6
mbVqoXN1auFKLl/TTWn5/PYg/S/MvMK8QukdS+KEWmbFVJxPBYY6G5bOLtBhRk0sofIiu1Z6Z9LH
fwYfe5n48nWOdTo8XqHLwCiVsDKhAJODP6V//2Lf4EtY+eK3/21bpaZ2sEoZHKiaOjpksY0/tmBo
0TU1KIi7FQVWpeDWz8TXu1kXtCsqxppMrJt//1Anl4ctXZXRaKbOX0yf8npR0hbcHrBFDULLS/8K
UyRRqVf1E2PJ/b2MVZY+FuYZpL1LAdZGwnyDJESchjt5QkLGWKyXOB2SsHf0khDLC/wz2pOwHMuS
dxnLJdr0PN597c6itrAklxdbxkwsAuYChJw3xJjA5EtQk+EHqJUambZRmlBL/mrF1Fa2jZbnZvn4
lXMnc9T1k0sgROCtDR0i9WxmYv63WNZFU+UlpsunNq47Qnuvzp8yDPN7rtkba/GNLZ6Kr18QdU6s
KlFl0UO76XaJsVSXTlPXuEi04R68hqgBCYsLFsrLseipjMti6pNF7pfYuaglL0TZ5VsSy09wwQzY
IMWovwISXmUN6tTih8I8oyS09PE1l+PXiLcSvpex3qbGFu9d4eNEJFgkSAnbYEFc9kMMYvbKe5wz
iZyWiEErtgwTflZkZkY/572Nz9BXHnuavvxUKPSPmHPqBManNl7+s6Fn+6aB7V16fdfdmwZ29BiI
C0/Qf3g1CttD9uSTWPLKxMR/0H/84cGLj/T0PHLxIFy7ux+5mMirjP8vsLHBnsge5q+wBGzhFfmD
ulB5/8UTa0TKQslWiBDXYuL8fb/aXbvU72jZXFOg8G+q66CovifvbKVfYOm80iDl08fogKHrzr6u
hXbjMhbOKcBiRwHI8auSF1uAZLMJl0nxRlK7jHMFLB9jf2HCF4ewBmfa24ddn8lLSlz5vJq+XaPN
qv+5h7kLO5YgZus3+XLzygdq4yt58vI/d97eXyWh+4qDpuyYwNTgw6fpKIue+NTQPN3cFq0rSHA7
ALVUE8S6uhvXUkYrubJ6Whn8ZIlKisi/94W4zVjVbSlqGg2U91dritZuC00c3GBs2fFCdPr4hKsg
uCkoc3X7TU1eVV7zXWPjhzaZ2w6cEbu6RhzuBqu4d/t6i6a80+bqrAvqim+K3t7cfzhaxkbDCqvc
PLS2NMdebzW3NDYWmTeMbmke+sHN1Sx2NXDvPNjaDZ3knkvUTjeILdd5gnO+l+G4f+vLO3a8daCV
iWy9xMss780dU2tqJ1uLslj753Ca2O324ejxmYBz6pnbycxr/F/8ODRfX6BtmmkjtawUYFz5nL5A
Pn8lxNTOGApt8vnFSvIl+sICw40+sPUuahgJUJDhqZTBFICajMxeVacus8KoFZDselwQvxh34COl
5cX1TkVfoMchfd7oVmXcu7tm9rvrov8w4cnIs2t49F1mkaa8dm1Z7fw6x+8vPs6TO3FJb6++Nlx+
hEuqy3qI29X+TntFc2mHQ6bv2j6w9HlRKRRne02BwuzC7q1rHzuWwp12hio0gFcLeM/COcS8XJWx
pNWmrNpVQjE3hZvirMAMdnwtNUI1SZ31bj464h9o9UuzffQWQX5psUJe7Ffz8IcckqIExQfnhr87
7qGpQIddLLZ3BSIbNhCmB97ZWyO3Vxcei/GVpTZKW+xW8qP0o6qQwWJr6a3Z/TYWOMeObo4cnfC+
+/Ozb7JcGLjyCfkJ2NaygsdfIi1r8WTJRvRN/2RHU+vOFzYPHR5xy/yjHRlKp9ECxp3Z5r6pxSfK
zbGGHxSX7Xjn6In3d/jUZe0WddCudA80mM1jJ+/65S9yLQFtpjPP2FFlAlv1AxfFYCsbqoKq6Ev+
S6CROQ2woQJ4OTCvCIsAjhrMswXAhbO+bJm/daB8+KEJr3fzkaGym5rLJAKKwiSJFZZyTRb+09Ln
gc4SsbikM+BstEjWLdpKlfzYsaJqW27N7l8fPHR+b12uuVznc0iKjcrU6SKnnBe9NL1sM2/06AhY
jWBsRvnBZjxUBCbUcFPUAIZcgTcfq5UkazMpa7KBUISDB0XGQO6dr+2orb3zXxfiz95WvRQmjXVD
le4NjV6R1z78HfKDJ4+33RayLma03H92x/3vHmgM3vbCt8ZHDw1YGZsp1xS3l+sYn0HEJC9wjUwt
vZy3tW7nNddxlz0HOK4We0aL1GnOf/75ktGHo0N3t6m33sHPMebn6mR8LKcv5pud0gE2QhM/39Oy
6YFRj8zkUdVV5pY51Ap/f+3UniVXsnIgEUWLqWnqMOpGg+jmJMNZjdzkKZHluwCaUj++ejSDberx
JsIie/E4HVJZBcmSn2EYw3szsw2yV2U+alqg9hVlSPMyhcY0iU6RVTLy0ESaRlPAy1BIMtzmL0YO
ha0NBz84/Omf7tuZ5ymSK+w1hZZWr+rse41brUKTq9Ko9+qzF7dvufm5413dfy6odGt2ZWo8hbDC
DIHaYyr0qAWUVmZWZUtU0jQBT+avbTS03jXgwZjEKRK5SqRRmTvmG8Es3v17JufT0lSWMp2mzG2T
Zfk6Riqee00vF5k00mxV0aVLazvHIlWuNE2AvNOzrkKjDq73+m6q1htq+9n9BnU4Rw18hyzHVpcr
a56viA/kythGbhAagxZnrUkkMXg13KXdlLbMnJNf7JTmJGKDqKCubZ29/fZ1VqHGpeUSj1aPrtG7
1s0G6QWzK5+pS5SlVqrEVKLgRemnC/uM1uKyanWqdeCBMVpv98F+YPMx4CROck1Qn0CFlL3qjE1e
DzMJ/pTCFtRrK+35+fZKrT5oU8zLgHFJaPlmlzRnaZ7zoLFUKxRqS42GUp1IpCu9tMSSbpLBE1t8
PFE6Je0kAzuVgZ0SOT9F8jVWwhWY+d4CMpeGm4mxEvsxR5Y/dXiyo/D5rqTunBVwSIIkMKGReJ0E
Vb+rcxvO8kyWpPB1jUFcEDhxrYCjfKyhFv+Q16g2FmK1wZIpzx8d7d54kN7c2ZbACXYSM9+VeW9o
Ff+XjbBy5kvvJ5cMc5mgXj4JcaX7m7khY2khla1iBzxmuO6ockO2SIweDRefVPBZqkwf04sKGrs3
LnNGw6V9jRvstWbx1xCIGGbaowfKanX8zo3M/xUEIh69+35bx4Sfji3ziV0bRw1rK/171/ZNlL9+
Ed/Ad6KfbR9YBTQZy3cCrkz2hJyF1EwYhwvoX12BUzvpv9J/2/LKrkaciXlbTu9qXJLJnF1+f6dT
yl67HFLCRH9A/67+vnfux2osX3Pf2/fHTkz5fFMnYpM/mPR6J3/A7C0FxM//pPqRA0E9ln3DpSci
plErlSlxPl42E2aD5NVTNMMsid6ZL8D79alSSH3+kaObvZ7x7w7PHyiGxEdymLBuWQoTz46uXx8J
dDG1Qge9jaVfQyL3FVbb5TV733ng0Nt7atY32yyGkGpvgpGYfvPsz9/1ThyNbD465mRw99NijgVw
exDzTbg7UYYx4dzj/VLC9l5/nIMsmSwjGGsSA3pNuUXBJGYoZiRlzTeVDR3Z7PVOPDRcDjWPLNuE
j/I0AVsek7b1S+bRdetGk4mbFsegNit6MFVpNEtKyrTl5tyaPe8cOvjr3TW5tuqiROlz+Vkmdcc4
z7x59sw5z/j3RhIrSPKQyqIGUQlCq78kS+6pa/mTSqInzi31cLVlRbIE5x428cX2mo3BhZl7bkuV
GfN1Lp0sg5Ia3MrqGL+gzE50WbzK1Ngxa51Vtrazf6yoskiq8zU0VufQD1u8eanL5wfyQcBR9Xec
HwCPYdXpAZ+PHx2yGP3VClVZp8PdWpKTWxZu6L5jnSU49+hQ+J5QYXhq43p1wKLIDUZ7ame7rf6Z
E2JdZa/TEdCkVY7UG6RGZ57GbbPk5ld1T9R1fauzUO2p1dY1jExnqWwqtctmz88JtEeq1u7oKwG8
ZsAr5jQgJfP9nccrSfobCg/oebxOCVtpSIm7ChtVWd7GPk/dVFvRkeqxgmDBk5hLXwruT+Nt54ky
+erWLRuIfeMuTfUues/SjptCCb+4oQ7UUk1MTZMs/wzXxVLnDYIrudvCL2jo2mg/9sMsjVtP4dcy
deWWknqLJKfQo+TisxKdQync767Spr/6Jn7DUqpKjy1NVW9uNpk7ZxvwLotLkRJbPG5xylNiyVck
1HnAYE6ei1JgD1tJLXscYugry1ZiqFi82WyyYYBQ500SdYFSRL9Nf0qfSss3OjXEllCBPoO7K1fP
54hEmeRufoZF68cvkxf4Bf6SxRfILXBWhu2lVuXahfRtVXe7cioDDj7+Xp4vT5PL4LhyCSHue4Cj
HDqMSud1OiUJaNo0rAV0SUkSHgljsTeb/Oz1XGkKl5OakZW+gZdWUyfA5+TKYo0yi/7iwm//+AH9
tzS5pljJJXoVFYE0bgtflJVBcVML5Gep4NLxplGD3OrwG7BZXi502WOxdG3QsXiaeHypl5xWFeXw
YzGtU2iX0Z/r25qq5c5YC1HP+lAGXM4H3Ex0WImVZPMxG+YZbtsSX6dLr32bnoqt+NqxUywtwN4K
TG7x2bn4vEhpsznUb2GLrd2gWJpL28LNKsid35edU1bHXfpCpC8tcRRggqbNIZuCuDtFa5Hzpbkz
4RwFeUyfE4ul5TsLaZre5i+JxWrSc1Rm5X3P5rrkGm0slqF0GLAXN3k8kCSypOlSU8Ge+YLSBB8R
xOhHYS2wP7GEWYSATBFwACT77X+CFQmrg9Hhj3UR+yLHTT1aYDOosnRt7e16XWV9aOY7Ee3Eg2M1
ufS+dKWmUEY0lNcJuCKjXpORKc7gEUS6QEDupFK4ZFs91RQTaH3mkf8699bI0IOTDWbRLa6BHZ3k
9nyNiLMQK7AIbZnmSKRfZww6zRKJ06bn4f18RZ481aaNLb8JK0SVqA3djz7BBnwr/gUhJjqIe4mX
yCxyM3mYfJ2SUiHqMPU+x8M5xHmf8wm3lnuE+26KK2Uu5TleF+8E72JqWepA6i/4cn4P/1SaKC2U
djLt/XRV+nD6SxmGjDsR83IEEWLYLRRqoBbQdmILcsKVafuIONrH5SIeZwD5OL1omquFqw/5qC+Q
D84s09y9yEe6QeZHvpSHQdYGnxY0zVGA7HEYdwoFOJeQmnzqyufUG6iPU4K0lBcNwLWf2o8GyGpk
pLYgihNCWuIs0nJkiWvKfyMTyEzURzDWhBQcG4y3IRP5EQqQAWSGe27qPOys81cuccxIRj2a8DNv
79LjCPG30C10G392xYvSxI+DlTjQSZSFXkGcVfcJ6FMcP/Ei3EGcIxxIMliZuJK/RCP4UwIRaTyC
4lAEQf0WEVcq0a1X4DkT83B9e3s9UiE+fSWBgbeX6FUh/MgHb4NlmzjPwxDogg7258oIGrnhe08H
Ys5kGUgACCVIivKRDumRAU6JhaCnCKJZMURVO2Q8B3IiN2TvUqg7alEd7NN61IAaURNqRi3AmHbU
gTpRF9SfPWgtCqF1qBetRxvQRtTHasrHg1fXb2O1YorJZv3Qw8l3sHy0NynHSIy+k5QTiEI/TMqZ
d2tPJ+Uk0qAfJ+UkYDqflFMoE+cn5RRS4uKknAPypqScA/L1STkXSfAtyXYK0uA9yTEpqBafTMp5
MObTpBxO7kRKUp6KxERJUp6KCom6pJyPbEQsKeejfuKhpDwNKYlLSXkaKidzrr6JV5I9SXk6yGeS
8gxkJU8m5Rmoj/xNUi5ARVRpUi5APdRgTXxqYWZ8dGxO5bCXOFT18fhoNKJqnByyqqqiUVUXc2tW
1RWZjczcHBm2ohoUR1NoAc2gcTSKxtAc0MWRdLQKXBuH31EURRHoNaJJNISs0KoCSRSuXVefmmV7
EbhGYK6b4f8wsrbF5+Kq7sjM+AgQIw6j4jCqmx0xjkaq49FhIFEcZhpujU/G5xamAGksPDo+Oaqy
qK49rGJHtsLISXaWBUCcwBNDYdA/DvJR6FvgcwM90E5qWT3l1w4ORWZmx+OTqhKr3aWaHwMqM0Nm
YRCDQwUWsoKdXNCaR2Nu76DbNWhmFLDzW5j5WXXjs6qwam4mPByJhWcmVPGRlT5ZgWCcNWEYPnOg
Jgzmi7DLm0ETIIuzyG7oji+Zjp34m621+vHayOz46KRqLhKO3eDpWta3jLcnWYgRmCtWG54Lq+Yn
x8Yn54BLyRkiw6rBBdXVaYdXTFsLD82xa5yHacZYKHMJqqxSwchUaBDUq24AZvhGYMbm5qbKbLah
+HDEOsqa2DoUj9mmbAAkbmNJOgfPl0GcscHC4+wsVpjjmk2trDwG96fgM5n0jS058y233GKNJZfF
Tj07Nz88Hl818y3srxVmuR71tblnQTYP2oFILeNDkclZsNj85HBkRjU3FlFVTYWH4JK8U6xapqHD
aof4Og6zRGDe2aSFGDsOs8Rk7DDGWqcK9IVhXKJ3/TPFIFlNZAdD5BVrDLMIrPGZUVs0gWLW1tJY
U9fWXWdhUNx4veEVWq0w8wzY1AZWXal9FiQtQLwayBttsOfqYMuy2tlohvmB/e+lvLcps/x/Id+x
4e2tSyfeWb5CbkX8WR4ToXnLaev/ABLU2DEKZW5kc3RyZWFtCmVuZG9iagoxMzEgMCBvYmoKPDwg
L1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvNTdiNTRiK05vdG9TZXJpZi1Cb2xkCi9G
b250RmlsZTIgMTMwIDAgUgovRm9udEJCb3ggWy0yMTIgLTI1MCAxMzA2IDEwNThdCi9GbGFncyA2
Ci9TdGVtViAwCi9JdGFsaWNBbmdsZSAwLjAKL0FzY2VudCAxMDY4Ci9EZXNjZW50IC0yOTIKL0Nh
cEhlaWdodCAxNDYyCi9YSGVpZ2h0IDEwOTgKPj4KZW5kb2JqCjEzMiAwIG9iago8PCAvTGVuZ3Ro
IDEyODYKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQo+PgpzdHJlYW0KeJxl18tu20YYhuG9rkLLdBFI
cyYBw0CRbrzoAXV7AXN0BNSSICsL3335vROkaRsgxi+JnHm+X8Mhdfj09NPT+XTfH367Xepzv+/H
6dxu/e3y5Vb7vvSX03ln7L6d6v3rK/7W13zdHbaTn9/f7v316Twu+4eH3eH37cO3++19/+HHdin9
h93h11vrt9P5Zf/hz0/P2+vnL9frX/21n+/74+7xcd/62Ab6OV9/ya99f+C0j09t+/x0f/+4nfPP
EX+8X/ve8tpMTL20/nbNtd/y+aXvHo7Hx4cxHnf93P7zkTke5yll1M/5Ng89bv8et9JQGpWW0qp0
lE6lp/QqA2VQGSmjykSZVC6Ui8qVclWZKbPKQllUVsqqslE2lZ2yqxyUW6IHg9fIa/AaeQ1eI6/B
a+Q1eI28Bq+R1+A18hq8Rl6D18hr8Bp5DV4jr8Fr5DV4jbwGr5HX4DXyGrxGXovXymvxWnktXiuv
xWvltXitvBavldfitfJavFZei9fKa/FaeS1eK6/Fa+W1eK28Fq+V1+K18lq8Vl6H18nr8Dp5HV4n
r8Pr5HV4nbwOr5PX4XXyOrxOXofXyevwOnkdXievw+vkdXidvA6vk9fhdfI6vE5ej9fL6/F6eT1e
L6/H6+X1eL28Hq+X1+P18nq8Xl6P18vr8Xp5PV4vr8fr5fV4vbwer5fX4/Xyerxe3oA3yBvwBnkD
3iBvwBvkDXiDvAFvkDfgDfIGvEHegDfIG/AGeQPeIG/AG+QNeIO8AW+QN+AN8ga8Qd6IN8ob8UZ5
I94ob8S7/dVu83VX+d8uE0kSlSSSJCpJJElUkkiSqCSRJFFJIkmikkSSRCWJJIlKEkkSlSSSJCpJ
JElUkkiSqCSJJElJEkmSkiSSJCVJJEnqfMKb5E14k7wJb5I34U3yJrxJ3oQ3yZvwJnkT3iRvwpvk
TXiTvAlvkjfhTfIueBd5F7xVhgVv1cQL3qrZFrxNgRa8TcgFb9NsC97OAXg74+LtCr/g7Uq84O3q
w4K3MzHezsR4OxPj7Qq/4u1KvOLtSrzi7Yq54u3irHi7Eq94uxKveIeQK94hw4p3CLniHUKueIdi
rniHkCvegQHvEHLFO+DgHTLkzWvnzpzxFkq8WbNlvFmGjDcrfA6cxgF4iwwZb1OKjDcrW8abZcib
15p5Gt6iFBlvVvvy5rWWCy3jrYyLt+mAIq/l/lKmV40qltM0WHGU6kOZXkr6WyijDuCuXhKDMcLC
u6IXeV2VochruX0UvFlNLXgLpfrryFbmepC3zP7KW1kPReNWvFmz1dlffQEVLzfXKq9ZJavqr2Xj
rdOrcSv93Tr33S4T4r83mUrji8jbRaEviTNZKFmZKkGIVwlS9d1WFkpTg6qCGLbhOih1QGOh8ESx
XWEq1e1mKRWkOUqt8eYppW8sFB4j2lzYWj5NjQ9Vodtc2GpQU+MNe0hT4+dNqhWV9Gq7iLeSe2Zr
lIyweUfhiW1beipF73Nh690+F4om7tOr0/r0aiV1vNzuOwulMgJekJ3GVwbDW9XfzsKu8nb6WxW+
z/4y7uyvsnX6W5Wis1CaOtnnwlbMoafVhT4MvE2GwUJpMgwuxKaJx9zo1Ichr+HxZMhruWCGvJY9
b8wLkXFX3pV3ZEpGKJRMMRc2BzTeVaDRKZl4MEX6fgHq8Vo/AL49ttcvt9v2xM6vBB7V9ZB+Ovdv
PySul6vO0v+/AeeG808KZW5kc3RyZWFtCmVuZG9iagoxMzMgMCBvYmoKWzI1OSAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCA1MDEgNTU5IDEwMDAgMzEwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgNTU5IDU1OSAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAzMDQg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgNzUyIDY3MSA2NjcgNzY3IDY1MiA2MjEgNzY5
IDgxOCA0MDAgMTAwMCAxMDAwIDY1MyA5NTIgNzg4IDc4NyA2MzggMTAwMCA3MDcgNTg1IDEwMDAg
NzQ3IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDQ1OCAxMDAw
IDU5OSA2NDggNTI2IDY0OCA1NzAgNDA3IDU2MCA2NjYgMzUyIDEwMDAgNjM2IDM1MiA5ODUgNjY2
IDYxMiA2NDUgNjQ3IDUyMiA0ODcgNDA0IDY2NiA2MDUgODU1IDY0NSA1NzkgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwXQplbmRvYmoKMTM0IDAgb2JqCjw8IC9MZW5n
dGgxIDYxNjgKL0xlbmd0aCA0MjA0Ci9GaWx0ZXIgWy9GbGF0ZURlY29kZV0KPj4Kc3RyZWFtCnic
nTgLcFtVdvdc/Zw4sSVbsuPYkZ/8/Esk+SNZkhPbsizH8keOLORPJNvY8d8O/mHLiYF8gC4hiASS
TdYNmWWXoQE2y2cFoVmYAcpmIWzZLAXKBpqmu1mG7jDll+kATQE/99z3npNAabdTec6795537vmf
c+8zAULIalJCVOShgYm+6Z+9evxlxFwkBFJGxm8Z3qT/67/H+WUkOjQ+NdDX80L/SkKSb0ea+dGJ
6PxcSfIfcX0F1x+Pjg71JeykHxCiRSC5E33z0xAhPYToEnDNtbQW28qb3jqC60Jcd0xPzUarYqf/
DteM30OTfRNDusqTuE7hCFFkILvBxKxHhgkxVOJ75/TM0HT83816XEdxXTQ8PTKR/GzxY7g+QQgd
GtgR5WCLqpWQNavwPQMgzD5xDmryF39ITFEyUarURJOwYmXiquU3q5OStboUnKTqDWmEpIvINRlk
bWbWOmLMlog4Ysrhc/PyCwrXE7LBbLEWkeKSUpu9zOF0lZONf1n+//236f+7kRL0PZyjF0gmQbVd
DruLR7BrRDDwIvAuBqmIK/Slb/LogrpBhKradJc7JZgyiDCZPpj+gvey9+f4w+EF/IHt8mXG37j0
JVzCLMgm6AXIMejTKsBhNyBfnZrPyXeUuRxF4Chz2m3phvxUPkeNFHabC5Q7mt35oWBwS2Bscr/d
1b+1YpNjRWFTp7eyoIA+PONu2LfPKzysHx066qSZ3Rv9nYl1ScLZcEN9I2Ykhm73UhTuVVCyAlNF
67IngTYtnd99prlrYKCruZDmP9v+mfDVZ+0i7RjS7pRoiVbDu0GbX2CHnTIxDSxeQGpQIzWQ9dAL
v6WfkCTcqEnXFGgKXAWu9AK7xgW/fXxnU2tr087Hsx5M6057kJaZ9jgfeMC5x7TV/+STfty7sLQH
msgCVhdJ550uu/qib0PKfN6dR+46IOkBargXGjHlSKrDZBiDHFDX1hLx3fP4qMC9+M6O/nv+zoUF
EV+y9B68gvFD/ArgAV4Rnm2AZnrhG0EhJm8l+v859H8yZilGOMVmpPokmlNEy9yQip52OsoKNKn5
ouNf37bZtmaNbbM0pK+tLS9Xn391bXV5Of0gt+3Ie0facqVh8UL/PU+0uL6G9vZ7nmgU9cA6gzbU
Q0OISVegcbjsOiD08V+E6N0wFBhbzMdceAlpnDQLtdIwC+0GBcJL8/PzsG9hQbgVLaLkAPrIgzQq
Fg3JS4zqbdFTrfPMV7BLtt1F9HCKBhg3UBlUhjxHHpwSTkOT8APYBcI5ei74RfALKc8rySPwHLy4
LNtkUCFUwi6R9Dav97zXK/KsQZ4vSjxTHcjUkeeoEamaQGDcgueoyK8GiV9Ev64lRkLyePSmy00d
ZXyOxoG5nGbQJ4EmiTLVITVo4rIz0tKj7b039nUNrM3KXGc09k6+67rRzGetc6zrqQpZ25oLanOz
jIUB4as77xRtw7idQP7YXoB3iPHRYl0YpKJh5QInQikrWzpPOu1l1fO774hWb6QJR5WHjwm/ym7I
+OXrz/2tXtQT+byFfBIZJxcG3I3Vhuw0oEdWBTqm7I/0phr/+q09Jj1U7t3vq6313bOnNrHs4J5H
70oULr3zpJ6e1T+KOmG1wE8xxonoG7GC7QaTzmQ4+fHHXzKv02MfeYTfe+kFL9L2yrQYxVQdj1Q8
7jjVBp6P34cJ4QgSfeRhdnbi47jEcz02Bh2PYUHGcFx4eW4OPHNzXtrh9S7+XOxVaMs5tEWD2YyZ
nKZV5+RrU2xObX6OWnvg4uDgxcH791VX76umHzwmbHvsMXho8eu7ofvuu4UTYsz8KOs13L+KdWzZ
fl70gEZ0iY7VA7w2Ec0ubPMH58ZDdU3mrCyzfzMIe29WCZ/QN/WT8x2BROFMYpDx8yGX88gvlWSJ
/DSGtGzgC4rADBJfEOuLOftMdXnxuuqOihSnvQR5/0l4r6S76X5zFk2v7s2guYPn36spFU6jAOFn
7i33Jko175NrN5t1TtYY041g0KPWDlQUo1hwrXNCkqvaUjrV9ruuusbuqK2q54ahnpZmH324ymHz
ppXe1PGSNVS1y9WQteGm5vZeY9Ai1Q/LYbFmlx3/5gOw7wF6DD0+Kukg9Y8LREuIEjNPZ9fpxa7B
JtD9SndbWflGe3Bl5yDNX/y0pcYTpCmLFwalvRgl+Ffci6Mr1c7+FLz4Z0894g1W09KAf7ub+oL+
tqKH4PziWfqTxXwQBEovLJ5l+234OIP7V2MOsc2p4u5Uhf1rOtFxdKF7gk6EF452Yl3nCA8K90Cp
8A+wEwZE2Tbs6WeWnmB9MR0ts8GhA+Xlcj2cpClEL9atVE0VcklIlau5dgidrO/pGv3ClLsxEAoF
RutDpq3NVWXFuXrj1sCzGTXrTbXGpmhNRVWpM1nKL+T9Iv0U8yvtan7ZDVJ+XU2vF4dHeupDxUV9
/aGby/NyiyurQXloj5FeuKy/4+AbJuGHyX1iH0Jex1HP6+pf1ElqAFpW/8eDyfq6LYHNGx3lFeNz
f9pcBpEdipGR0dGsmoy77oGkZKaTS7T3U6xD5JRnc+mQFXIqEPMG642xA2Vxbl75zdWH+/uKikP1
PcMjZckwaXpjqu/Ng3foLy/mG/eSZV6nUKcUsgYjagRZHV2Z1PE0eXam573KuupKf5P33cHBrggV
/vn3it5y16f9YdQKkg7eseugRu9+rInZyOrxpNTj8DRYTmU+JwnWAWsvvM4/7w4UWfLy+czEo0dD
cNrt6/WvrF2tdXoL3UITnJZ7+9JaeAr10uEtBqNtc1bBslrpOr1aobdLdqt3j+60lvx6bLK14ZHb
mPPzvLV/9oyEk/Vk6a5b9ULerffDf/4qGzo1XWRZv1PoO7zpsYJmOaLW6Hg5pnAqsL48q0IbCm30
tjRDm/AEeLZWrEkVIvTTr4xdqNd23OejV6SzjHHgHS52IPja9kdHacLiFXjdjaeffO4wX4i1mCfa
7rBDduwPsT+43fTHbqmejGK/SWFWmnRSx+KvjsxYMQ462G/IMukD7BHcGChft97ZZIdDBZk6oXp5
+IzPyHBsEablPoMP5j9MGLvUDw3LjI+FGm68ORS0e0pz4N8KG/uEYzBaUZwp+d2G+XAG9323H5dh
P9b/6PWBgdcHYruczl1OmrJXeH/vXjAKf9P5YWfnh2Kt5GKtpGCtGNg5L0kVS8a1XCsPhvydo0OD
vSXWN24TE/QifdN4+33379V/9cYq4WC2qPskPk6IOhAwSI6AE7fcFLqPptRkCwG4ZJNsDKKuzMZs
+RaKrVSU5pDuQN/qpStGCh0jDQNdbfUt3irXhoqupq7IlsYAvBPg8pOzGg74jbV8obnAoltbv2lz
g74mXa7Xk/QZZk0qi991xcpi6bD/xzPPGEuKzUXONu/gYAg+dwuXNuWvrl1Z0w4b3C9J+SbySBD7
plSZy/3WBVsxEDcFgpaqEp4mCGmFDf0wKhxzW9Ku9skE5gOX1GSxQ86GFgYXOnxwZvEKTZB8gBcC
vIsnfF8/PtTYXENLGnzDHtoQ9IUKB+GEUAbnMEWfEkIosPvaeZEg9WMX68cF+GUg9uPxtsOHO7fT
7R2HD4fB+bbwjfDN22+DEpRsnxVj/RbuS2C5zYS6FHa8HN7afrk18IsbJuH4YtafQZDjJMYzQbxj
mAwKvDSYHKkOPghtV64IT1xBW9zCDup2Q4xKdYN9/iRedfPYncSIjYN9YBjQdVVQlm/GGwXrBmVO
EafGt+pfWwtNbtuWxjqz1eGwmusat9jcpkKopPrNVQcb8p31LQveisoK70JLvTO/4WDVZiLHJgqn
JDlQBFeZp10VKDK/JtAFpd8ryAqV/5Mg/fJXWQkZJ3eSY+Q0OUveIZfIZcgFJzRAD0RhP/wYzsFl
mkYt1EM76A76E/oGFRRaRZEioBhXzCseVZxTXFamKd3KfuV9yqeUryjPq6jKqKpUbVNFVSdUZ1Xv
q75Up6lt6gb1NvVR9W/Uv1F8iFZ9LkIhghFhN8IYwnqEBXn+PEIJQiVCK8JLCAcQXDKuRgaXPLYj
9CJ0ynz9CD4ZlvckI9hkqJFplnm45HWlPG6X3xllHjYZP4kQvG4/w+vl/dbvvBM/65V24WXSyazG
T6QP5f8KXPtViJgKvJuq5a9kzFbxJF6mAPgcDrHvOBqjL+D6gDTCJVIKNGEFTVStoFRBqeYSoUvb
6xc/Qhr2/wKyxcxxxENWCkuK7qUo6VTaweNJgZ/+8V1Zkvhb+iti+97v9QqmMGq1AutjFdZhMt7L
dMg5FWt7HZ4P2ey/DiSH5JMC/LJfTyzIx04cxIm1W0424X4v2UzqsOPXkwbSSJrwjGsmLVh1N5AQ
fsO1kw6ylYRJBG3vIt3kRtJDtgFo5ibHSkpqSlC6AehVN+SI2oCSfTdvxpWEB9RvWMYDajku4yn2
p3kZT/H7ea+MV5AN5KCMV5A28ksZryRJkCjjlSQLMmS8iqwGh4xXkbXglfFqkg7d8jyRmGBWpkkk
Xjgq47VEDedlvJasgoviXCfOl/NARzSYJxKNDnX4WqbBOV1ROzV9y8zYyGi0cGA9ZyspLeMwor6W
QFsrFwy1NNXVtpFaMkWmyS1khoyRETJKohiJAYwFh7EoIaWkDGdbiBmfPvR8AC1uxXkQ/d+C8ajD
/W3Is3RiUqYqJRNkMjQ0MjfeN4NEQ8h0Dp3aR2Z8U5NR39TMyBBnKyrhNnHSNm5GokWEzWm1WZmW
KGoKj8qoOM4ghyFRnSJUiMO04K4XhePM9VJkChsmkRWf1mUzvi3tf+PQMTQzOzY1yZUWlTjKMcOG
8PUsemdKJC0V1XCQclvfoLN/wDwxPT43i5ytMufRaHR6U3GxiLYOo8mzRbNTczMDQ8PM9KLt06KP
o+jzTaQY/yZwNo6iZ1HVYdnsWZQxi/M5lDyA8oevuqEIb2nT/93f18+XLfy2V769kvoKgaR/qnnt
VXVvcuUXxCz1l3/86uQD18altYoPFXiY4lko1/pzsHRXHA4SfzwhGH4a4L7I0z61OWyKayP+uD6E
k9sj6+Jqc3c4EtebCYkTS5yk+uMbguF4045InPDVa/B1uCoi4nZHuHfikFq0xhoHC3chvspsjVOL
PxSu4yMma1xhGVvDxT1BZOuJWONKC9tq4k23hv8l83eRTKQLL2Z+EsnkTXGVORz37YiILyIR5Key
rO7utMbVlqdzYD9K5/Z3d2fGCbLRWJ7OFVGeq6gES4qO21hsja+wcLuZkFeQDRdX5DXyXFyZ3xQn
wXBsKNbHsUl5pskUyYyJq5C0YgJXStppM7Um5Jho4d4WzVll4YrjGnQIx9Xzvr7tXJgb7JdYMLrV
TDKK5mJcfczXx8e4GC+K4xnzuAcp0T6GiHuG2AL3JImSqs6vMZkyufMxdANuakRt2mXdTCJZsoXn
zsvCeS7sb800xSESjqFBjXyM52KNMb6PbZC2sMEa17IwpKDeOmYAm6R8x4AYG/i+7duut4RtTbWg
EbG7mduaBvmYJs4Fw5WZL+MbveUU8YDH6wX/c1pMafHJiNvD7BkK8/2oPe/NxAF4L3reEwo/gxld
O+B9BjjAIc4NxDOGspZlGSxxxKJf8GFlZ1AutuwE/CIx0Vv+CzC2VukKZW5kc3RyZWFtCmVuZG9i
agoxMzUgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvMmFkNmJjK21w
bHVzMW1uLXJlZ3VsYXIKL0ZvbnRGaWxlMiAxMzQgMCBSCi9Gb250QkJveCBbMCAtMjMwIDEwMDAg
ODYwXQovRmxhZ3MgNAovU3RlbVYgMAovSXRhbGljQW5nbGUgMC4wCi9Bc2NlbnQgODYwCi9EZXNj
ZW50IC0xNDAKL0NhcEhlaWdodCA4NjAKL1hIZWlnaHQgMAo+PgplbmRvYmoKMTM2IDAgb2JqCjw8
IC9MZW5ndGggMTI4NgovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCj4+CnN0cmVhbQp4nGXXy27bRhiG
4b2uQst0EUhzJgHDQJFuvOgBdXsBc3QE1JIgKwvfffm9E6RpGyDGL4mceb5fwyF1+PT009P5dN8f
frtd6nO/78fp3G797fLlVvu+9JfTeWfsvp3q/esr/tbXfN0dtpOf39/u/fXpPC77h4fd4fftw7f7
7X3/4cd2Kf2H3eHXW+u30/ll/+HPT8/b6+cv1+tf/bWf7/vj7vFx3/rYBvo5X3/Jr31/4LSPT237
/HR//7id888Rf7xf+97y2kxMvbT+ds213/L5pe8ejsfHhzEed/3c/vOROR7nKWXUz/k2Dz1u/x63
0lAalZbSqnSUTqWn9CoDZVAZKaPKRJlULpSLypVyVZkps8pCWVRWyqqyUTaVnbKrHJRbogeD18hr
8Bp5DV4jr8Fr5DV4jbwGr5HX4DXyGrxGXoPXyGvwGnkNXiOvwWvkNXiNvAavkdfgNfIavEZei9fK
a/FaeS1eK6/Fa+W1eK28Fq+V1+K18lq8Vl6L18pr8Vp5LV4rr8Vr5bV4rbwWr5XX4rXyWrxWXofX
yevwOnkdXievw+vkdXidvA6vk9fhdfI6vE5eh9fJ6/A6eR1eJ6/D6+R1eJ28Dq+T1+F18jq8Tl6P
18vr8Xp5PV4vr8fr5fV4vbwer5fX4/XyerxeXo/Xy+vxenk9Xi+vx+vl9Xi9vB6vl9fj9fJ6vF7e
gDfIG/AGeQPeIG/AG+QNeIO8AW+QN+AN8ga8Qd6AN8gb8AZ5A94gb8Ab5A14g7wBb5A34A3yBrxB
3og3yhvxRnkj3ihvxLv91W7zdVf53y4TSRKVJJIkKkkkSVSSSJKoJJEkUUkiSaKSRJJEJYkkiUoS
SRKVJJIkKkkkSVSSSJKoJIkkSUkSSZKSJJIkJUkkSep8wpvkTXiTvAlvkjfhTfImvEnehDfJm/Am
eRPeJG/Cm+RNeJO8CW+SN+FN8i54F3kXvFWGBW/VxAveqtkWvE2BFrxNyAVv02wL3s4BeDvj4u0K
v+DtSrzg7erDgrczMd7OxHg7E+PtCr/i7Uq84u1KvOLtirni7eKseLsSr3i7Eq94h5Ar3iHDincI
ueIdQq54h2KueIeQK96BAe8QcsU74OAdMuTNa+fOnPEWSrxZs2W8WYaMNyt8DpzGAXiLDBlvU4qM
NytbxptlyJvXmnka3qIUGW9W+/LmtZYLLeOtjIu36YAir+X+UqZXjSqW0zRYcZTqQ5leSvpbKKMO
4K5eEoMxwsK7ohd5XZWhyGu5fRS8WU0teAul+uvIVuZ6kLfM/spbWQ9F41a8WbPV2V99ARUvN9cq
r1klq+qvZeOt06txK/3dOvfdLhPivzeZSuOLyNtFoS+JM1koWZkqQYhXCVL13VYWSlODqoIYtuE6
KHVAY6HwRLFdYSrV7WYpFaQ5Sq3x5imlbywUHiPaXNhaPk2ND1Wh21zYalBT4w17SFPj502qFZX0
aruIt5J7ZmuUjLB5R+GJbVt6KkXvc2Hr3T4Xiibu06vT+vRqJXW83O47C6UyAl6QncZXBsNb1d/O
wq7ydvpbFb7P/jLu7K+ydfpblaKzUJo62efCVsyhp9WFPgy8TYbBQmkyDC7EponH3OjUhyGv4fFk
yGu5YIa8lj1vzAuRcVfelXdkSkYolEwxFzYHNN5VoNEpmXgwRfp+AerxWj8Avj221y+32/bEzq8E
HtX1kH46928/JK6Xq87S/78B54bzTwplbmRzdHJlYW0KZW5kb2JqCjEzNyAwIG9iagpbNTAwIDEw
MDAgMTAwMCA1MDAgMTAwMCAxMDAwIDUwMCAxMDAwIDUwMCA1MDAgNTAwIDEwMDAgNTAwIDUwMCA1
MDAgNTAwIDUwMCA1MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDUw
MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDEwMDAgMTAwMCAxMDAwIDUwMCA1MDAgNTAwIDUwMCAxMDAw
IDEwMDAgNTAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCA1MDAgNTAwIDEwMDAgNTAwIDUwMCA1
MDAgNTAwIDEwMDAgNTAwIDUwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCA1MDAgMTAw
MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAxMDAwIDEwMDAgNTAwIDUwMCA1
MDAgNTAwIDUwMCAxMDAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAx
MDAwIDUwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDUwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDBdCmVuZG9iagoxMzggMCBvYmoKPDwgL0xlbmd0
aDEgMjM1NgovTGVuZ3RoIDExNzEKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQo+PgpzdHJlYW0KeJzV
VU1sG0UUfrO2E8dJ04CcFgnVGtKqCm2zmzhpQFEqNYrzV1wHxVVUCdSy9q53l9i71u66iYW4IHEj
UluKkLhw4EdIIA4ceuJQIQ4ckQC1F0QPXDggEBJShCDh2/EkcYMhZ9aanX3fzPvem2/ejIkRUYpG
KUH1ck2vE1MGgXxCxB63qs3Ky4n3L+D7HrDnq15ZRz9MpAygT9q1cKPvJwpgPwG7z7ZNfeDbrgLs
U7BP1fSNOj3JqrAXYfPlopbd+vKNddg27JfqXhD++MELz8L+Cva4q9fMX8uvrML+kyixDTrjsdX3
8ggFmybRGEX5IhY+u+jQhymHz/mfPwoF7HWlFGtAE+wCS3edHDp9fmJyPHv8WPfE6ZNDXYPpY+PZ
SaX0Vrly603DmV96zpqfs8pLhevKq2ubN+3K7UuLlflKZX7RsHdZh5MRdRrtO+wvNE9u/vURCuXK
dn670LMld2H/iQkkRp/SAH2OWmIHcmQUj//CbmKEEu8kxpFnptXHvqYK+00hpTehxBNxRYk/JGXn
Im3swO/pyHlheXmBLlJqe6eVQ3JTucqJvfvDfaL4pcRdTIFJcqd3KlTpqFMsaoylvLrplhrVqhlG
6AlW2stVa60j3oP+GqwWznA6NiXOKE1vS1yhbvpY4gr102cSj9EJuifxGE3R9xKPU4odl3ic0uwp
iSfoKDsv8QRlWE7iXTSwl1s3DTFfzummHLsj8SQNsgcST9IZ9rPEeyit7MbqoWHlrMRTpClFiafo
mvKaxHspozyUeC9NK9t7pywTm5J4H03Hrkr8CKmxOxI/Qi/GvpB4P52JZyTeT1fii7Nevek7lh3y
7OhYli94nlU1+ZJbVvlMtcpXoqGAr5iB6d8wDZVmyaM6NcknhyyyKcTWZnE5jeHNaQGjHvAqmbCW
yKUyqfiaAVJFv7LnFQjLRG+C6wbeBqkFL/R40fSdChXAE6JxKooZDlVWTKtR1X3hZlEDhDr5lz3X
C5t1pFzTLce1+AhvY7kMBlcwNZF1K6ca3CzwuXhzGkHrEOu/M1k1/cDxXD6mjk7whk2rYiDAUBSO
QwwVkkzgq0H2RPYZQzfORoyCUFA7Add56OuGWdP9Ne5V2pVvC+kIoXS0EBF0iGSKBfi0BszDSfoX
0f+hiyA+XI+D7jkzcCyXh6Ze6+CdEzsY7akrUjTBVcvpoc4bru24ISpGMpgGLzX5Hq3RRpuDUyjW
2ACNLVIJWwVxIESEcSohPO+QjNEpGTsM61OaVvYMU7WExGrZq2l1DYl4mijFEP5TuE00LNwTLCo4
9jVVBV7DeB3NlXujSeb19XW1JpclqIOwYTjeAeZ18VPB8mjW+9wBsAaio4byTtl0AyjWcA3T56Ft
8pm6XkYnR87x3QrMqqOUh08ZXK44TIbU0RA1GelgC3VmEE/HvJb1qM85IAdrOBvVcNsadZGB6vmW
Vm1lEWj5pdm5QnFuJMqi83r1tqgqmH1oqkHV9ugBkDwKb5bmUPlFvEda0cXdjpa6cP9W5vb1o9O/
K71JcY1988eHD3Z7/N9Rz1ayJG5b+fwNgW+YkgplbmRzdHJlYW0KZW5kb2JqCjEzOSAwIG9iago8
PCAvVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lIC80MjdkYWQrTm90b1NlcmlmCi9Gb250
RmlsZTIgMTM4IDAgUgovRm9udEJCb3ggWy0yMTIgLTI1MCAxMjQ2IDEwNDddCi9GbGFncyA2Ci9T
dGVtViAwCi9JdGFsaWNBbmdsZSAwLjAKL0FzY2VudCAxMDY4Ci9EZXNjZW50IC0yOTIKL0NhcEhl
aWdodCAxNDYyCi9YSGVpZ2h0IDEwOTgKPj4KZW5kb2JqCjE0MCAwIG9iago8PCAvTGVuZ3RoIDIy
OAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCj4+CnN0cmVhbQp4nF2QwW7DIAyG7zyFj+2hIkHaTghp
6i45bJ2W7QEImBRpAUTIIW8/Q6tO2sGWf/3+0I/5eXgdgi/AP3I0IxZwPtiMa9yyQZhw9oH1Aqw3
5a5aN4tOjBM87mvBZQgugpSMf5K5lrzD4cXGCY+MX7LF7MMMh+/zSHrcUvrBBUOBjikFFh099KbT
u14QeMNOgyXfl/1EzN/G154QRNP9LYyJFtekDWYdZmSy65R0TjEM9p8lbsDkzFVnJgUtdh11Gnsl
xRM+N+ruV77+8JHLbDlTpHaGlqWm8AEfl0oxVarWL32DcDAKZW5kc3RyZWFtCmVuZG9iagoxNDEg
MCBvYmoKWzI1OSAzNTQgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEw
MDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAw
IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDBdCmVuZG9iagp4cmVmCjAg
MTQyCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAwMjg5IDAw
MDAwIG4gCjAwMDAwMDA0OTIgMDAwMDAgbiAKMDAwMDAwMDYyNyAwMDAwMCBuIAowMDAwMDAwNjc4
IDAwMDAwIG4gCjAwMDAwMDA5NTAgMDAwMDAgbiAKMDAwMDAwMTUxOSAwMDAwMCBuIAowMDAwMDAx
ODE1IDAwMDAwIG4gCjAwMDAwMDE5ODIgMDAwMDAgbiAKMDAwMDAxMDU2NiAwMDAwMCBuIAowMDAw
MDEwOTIzIDAwMDAwIG4gCjAwMDAwMTA5NjcgMDAwMDAgbiAKMDAwMDAxMTAxNiAwMDAwMCBuIAow
MDAwMDExMDYwIDAwMDAwIG4gCjAwMDAwMTExMDQgMDAwMDAgbiAKMDAwMDAxMTI3NyAwMDAwMCBu
IAowMDAwMDExNDY0IDAwMDAwIG4gCjAwMDAwMTE1MDggMDAwMDAgbiAKMDAwMDAxMTU1MiAwMDAw
MCBuIAowMDAwMDIwNzI4IDAwMDAwIG4gCjAwMDAwMjEwOTMgMDAwMDAgbiAKMDAwMDAyMTEzNyAw
MDAwMCBuIAowMDAwMDIxMzg2IDAwMDAwIG4gCjAwMDAwMjE2MzQgMDAwMDAgbiAKMDAwMDAyMTY3
OCAwMDAwMCBuIAowMDAwMDIxNzIyIDAwMDAwIG4gCjAwMDAwMjE3NjYgMDAwMDAgbiAKMDAwMDAz
MTQzOSAwMDAwMCBuIAowMDAwMDMxODQ2IDAwMDAwIG4gCjAwMDAwMzE4OTAgMDAwMDAgbiAKMDAw
MDAzMjExMSAwMDAwMCBuIAowMDAwMDMyMzMwIDAwMDAwIG4gCjAwMDAwMzI1OTcgMDAwMDAgbiAK
MDAwMDAzMjg2NCAwMDAwMCBuIAowMDAwMDMzMDg2IDAwMDAwIG4gCjAwMDAwMzMzMDUgMDAwMDAg
biAKMDAwMDAzMzU3OCAwMDAwMCBuIAowMDAwMDMzODUzIDAwMDAwIG4gCjAwMDAwMzM4OTcgMDAw
MDAgbiAKMDAwMDAzMzk0MSAwMDAwMCBuIAowMDAwMDQzOTEzIDAwMDAwIG4gCjAwMDAwNDQyODUg
MDAwMDAgbiAKMDAwMDA0NDQ2MCAwMDAwMCBuIAowMDAwMDQ0Njk5IDAwMDAwIG4gCjAwMDAwNDQ5
MzYgMDAwMDAgbiAKMDAwMDA0NTE0NSAwMDAwMCBuIAowMDAwMDU0MjUyIDAwMDAwIG4gCjAwMDAw
NTQ2MDYgMDAwMDAgbiAKMDAwMDA1NDY1MCAwMDAwMCBuIAowMDAwMDU0Njk0IDAwMDAwIG4gCjAw
MDAwNTQ3MzggMDAwMDAgbiAKMDAwMDA1NDkwNiAwMDAwMCBuIAowMDAwMDY0MjUyIDAwMDAwIG4g
CjAwMDAwNjQ2MDYgMDAwMDAgbiAKMDAwMDA2NDY1MCAwMDAwMCBuIAowMDAwMDcyODAxIDAwMDAw
IG4gCjAwMDAwNzMxODAgMDAwMDAgbiAKMDAwMDA3MzIyMyAwMDAwMCBuIAowMDAwMDczMjY3IDAw
MDAwIG4gCjAwMDAwNzMzMTAgMDAwMDAgbiAKMDAwMDA3MzUzMSAwMDAwMCBuIAowMDAwMDczNTc0
IDAwMDAwIG4gCjAwMDAwNzM3NzcgMDAwMDAgbiAKMDAwMDA3NDAyMSAwMDAwMCBuIAowMDAwMDc0
MjY0IDAwMDAwIG4gCjAwMDAwNzQzMDggMDAwMDAgbiAKMDAwMDA4NDE4OCAwMDAwMCBuIAowMDAw
MDg0NTI5IDAwMDAwIG4gCjAwMDAwODQ1NzMgMDAwMDAgbiAKMDAwMDA4NTA1OCAwMDAwMCBuIAow
MDAwMDg1NzY5IDAwMDAwIG4gCjAwMDAwODU4MTMgMDAwMDAgbiAKMDAwMDA5NDcwMyAwMDAwMCBu
IAowMDAwMDk1MDc1IDAwMDAwIG4gCjAwMDAwOTUxMTkgMDAwMDAgbiAKMDAwMDA5NTE2MyAwMDAw
MCBuIAowMDAwMDk1NDA1IDAwMDAwIG4gCjAwMDAwOTU2NDUgMDAwMDAgbiAKMDAwMDA5NTg2NCAw
MDAwMCBuIAowMDAwMDk1OTA4IDAwMDAwIG4gCjAwMDAxMDM2MDMgMDAwMDAgbiAKMDAwMDEwMzk1
NyAwMDAwMCBuIAowMDAwMTA0MDAxIDAwMDAwIG4gCjAwMDAxMDQwNDUgMDAwMDAgbiAKMDAwMDEw
ODc3OCAwMDAwMCBuIAowMDAwMTA5MTYzIDAwMDAwIG4gCjAwMDAxMDkyMDcgMDAwMDAgbiAKMDAw
MDEwOTI1MSAwMDAwMCBuIAowMDAwMTA5Mjk1IDAwMDAwIG4gCjAwMDAxMDk1MDEgMDAwMDAgbiAK
MDAwMDEwOTcwOCAwMDAwMCBuIAowMDAwMTA5OTE1IDAwMDAwIG4gCjAwMDAxMTAxODUgMDAwMDAg
biAKMDAwMDExMDQ1NSAwMDAwMCBuIAowMDAwMTEwNTMxIDAwMDAwIG4gCjAwMDAxMTA4MjEgMDAw
MDAgbiAKMDAwMDExMDk4NSAwMDAwMCBuIAowMDAwMTExMTczIDAwMDAwIG4gCjAwMDAxMTEzNzIg
MDAwMDAgbiAKMDAwMDExMTYwNyAwMDAwMCBuIAowMDAwMTExNzk3IDAwMDAwIG4gCjAwMDAxMTIw
MDkgMDAwMDAgbiAKMDAwMDExMjM1NSAwMDAwMCBuIAowMDAwMTEyNTg1IDAwMDAwIG4gCjAwMDAx
MTI3NjkgMDAwMDAgbiAKMDAwMDExMjk4NyAwMDAwMCBuIAowMDAwMTEzMTY5IDAwMDAwIG4gCjAw
MDAxMTMzNDggMDAwMDAgbiAKMDAwMDExMzc4NCAwMDAwMCBuIAowMDAwMTE0MDcyIDAwMDAwIG4g
CjAwMDAxMTQzNDMgMDAwMDAgbiAKMDAwMDExNDYwMSAwMDAwMCBuIAowMDAwMTE0ODgwIDAwMDAw
IG4gCjAwMDAxMTUwMjkgMDAwMDAgbiAKMDAwMDExNTIyNSAwMDAwMCBuIAowMDAwMTE1NDk5IDAw
MDAwIG4gCjAwMDAxMTU2NzUgMDAwMDAgbiAKMDAwMDExNTkwNSAwMDAwMCBuIAowMDAwMTE2MDU2
IDAwMDAwIG4gCjAwMDAxMTYzNjIgMDAwMDAgbiAKMDAwMDExNjUyNCAwMDAwMCBuIAowMDAwMTE2
NzA0IDAwMDAwIG4gCjAwMDAxMTY4NzYgMDAwMDAgbiAKMDAwMDExNzA1NiAwMDAwMCBuIAowMDAw
MTE3MjA2IDAwMDAwIG4gCjAwMDAxMTc0MjEgMDAwMDAgbiAKMDAwMDEyNjE2NSAwMDAwMCBuIAow
MDAwMTI2MzgxIDAwMDAwIG4gCjAwMDAxMjc3NDQgMDAwMDAgbiAKMDAwMDEyODgwMSAwMDAwMCBu
IAowMDAwMTM1MTM0IDAwMDAwIG4gCjAwMDAxMzUzNTUgMDAwMDAgbiAKMDAwMDEzNjcxOCAwMDAw
MCBuIAowMDAwMTM3ODA4IDAwMDAwIG4gCjAwMDAxNDIxMDMgMDAwMDAgbiAKMDAwMDE0MjMxNyAw
MDAwMCBuIAowMDAwMTQzNjgwIDAwMDAwIG4gCjAwMDAxNDQ3NjEgMDAwMDAgbiAKMDAwMDE0NjAy
MyAwMDAwMCBuIAowMDAwMTQ2MjM5IDAwMDAwIG4gCjAwMDAxNDY1NDMgMDAwMDAgbiAKdHJhaWxl
cgo8PCAvU2l6ZSAxNDIKL1Jvb3QgMiAwIFIKL0luZm8gMSAwIFIKPj4Kc3RhcnR4cmVmCjE0NzY4
MAolJUVPRgo=
------=_Part_196_278162738.1504833420354--

.