Re: Poor performance of unlimited integer size

--===============3031389238511942919==
Content-Type: multipart/alternative; boundary="----4UCAUJGAU2DZCH830U693JSNXJ14SI"
Content-Transfer-Encoding: 7bit

------4UCAUJGAU2DZCH830U693JSNXJ14SI
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Dennis,

learning by example is always the best=2E
Learning and making life easier was also my motivation for writing Gdar=2E
I haven't looked on dar_manager in detail yet, but a decent versioning of =
archived files is great=2E Would be nice to have a GUI there :)

Hope Gdar worked for you=2E Haven't had much time in between to work on it=
=2E

Yes, my backup solution would also be based on libdar=2E

The inhibit shutdown topic is unfortunately not a simple one=2E
A solution for all Desktop environments and Distributions would of course =
be preferable=2E
But I also like a convenient user experience=2E I would be happy to have a=
 nice fitting solution for KDE and Gnome, for all other environments there =
could be a backup solution=2E
The thing with overwriting the close event, like Editors are doing it, wor=
ks well=2E But it requires a program Window=2E As far as I know, this does =
not work with a background process, without having a permanent Window=2E
A solution based on systemd would be nice, but the inhibit shutdown does o=
nly work if the shutdown is triggered directly via systemd=2E I could not g=
et it working with the shutdown command, or if the shutdown is initiated vi=
a the desktop=2E

Do you see my point?
But I think this discussion is nothing special about the libdar API :)

Best regards,
Tobias

Am 10=2E August 2018 12:33:21 MESZ schrieb Dennis Katsonis <dennisk@netspa=
ce=2Enet=2Eau>:
>On 08/10/2018 05:13 PM, Tobias Specht wrote:
>> Hi Dennis,
>>=20
>> nice to hear you are planing to write a backup application with
>libdar=2E
>> I'm using the libdar API with my small tool Gdar myself:
>> https://github=2Ecom/peckto/gdar
>> http://www=2Epeckto=2Ede/gdar/gdar (Webseite having currently some
>linking=20
>> problems=2E=2E=2E)
>> It's GTK though=2E Gdar can only extract dar archives at the moment=2E
>> Feel free to work with my code, or use it as an libdar example :)
>>=20
>
>
>
>> I'm planing a larger tool with automated backup too=2E
>> But I'm still in the planing phase=2E=2E=2E
>> Trying to solve some general problems with backups in desktop
>environments,
>> like inhibit/delay shutdown:
>> https://forum=2Ekde=2Eorg/viewtopic=2Ephp?f=3D305&t=3D141575=20
>> If you have an idea on it, let me know=2E
>>=20
>
>Thank you=2E  Even though I've started, I'm still thinking it might be
>better to work with an existing program than create yet another
>program=2E
> I'm a self-taught hobby programmer, and part of the motive is simply
>having something maybe worthwhile to work on=2E  It's actually
>dar_manager
>and the database which interests me more, and allowing the user to
>easily see which versions of which files are in their backup, and
>restore them=2E  Restoration from backups is more often to recover a
>small
>number of accidentally deleted or overwritten files, than full system
>restores, or perhaps to see a file as it was some time ago=2E
>
>I played around with GDar a couple of years ago or so=2E
>
>Is this tool you are working on going to be libdar based?
>
>As for the shutdown, I don't know how to do it under KDE, and I don't
>think you can (with good reason)=2E  The answer provided in that thread,
>where I presume the mainwindow overrides the closeEvent slot to at
>least
>give a warning is probably the best one=2E
>
>The problem is, if it were possible, it would only work under KDE=2E  Run
>the software under FVWM, or Fluxbox, or something else, and it won't
>inhibit closure of the windowing system=2E  This would lead to users
>having incomplete backups, possibly without them knowing=2E  It also
>doesn't inhibit closure from another user logged in, or the root user=2E
>
>I would use systemd-inhibit=2E
>
>See the second answer here=2E
>https://unix=2Estackexchange=2Ecom/questions/34489/how-to-disable-shutdow=
n-so-that-an-important-process-cannot-be-interrupted#264745
>
>
>> About your initial problem, I'm using fedora and dar as an rpm
>myself=2E
>> Did you write the packet maintainer about the compiler flag?
>> Maybe he can add it to the building instructions=2E
>>=20
>
>Yes, I did make the suggestion=2E
>
>> Hi Denis :)
>>=20
>> nice to hear you are improving the libdar API=2E
>> Will have a look on it=2E
>>=20
>> Best regards,
>> Tobias
>>=20
>> Am Donnerstag, 9=2E August 2018, 22:29:11 CEST schrieb Denis Corbin:
>>> On 09/08/2018 13:37, Dennis Katsonis wrote:
>>>> Hello,
>>>
>>> Hello Dennis,
>>>
>>>> I am developing a front end for Dar which is intended not just to
>>>> provide a graphical way of creating archive, but also provide
>>>> basic backup management=2E  The application will be written using the
>>>> Qt toolkit and using libdar directly=2E
>>>
>>> nice! :)
>>>
>>> Be aware that next to come major release 2=2E6=2E0 brings some API
>>> re-design to simplify the use (less libdar specify auxiliary types)
>>> and added new features=2E though there will be the same API in the
>>> specific 'libdar5' namespace and I will be available to help you
>>> migrating to the API v6 upon request=2E
>>>
>>>> I note that the version of dar compiled for Fedora uses the
>>>> unlimited integer size=2E  The performance of dar on archives with
>>>> large numbers of files is not satisfactory, and would unfortunately
>>>> also mean that the graphical application would stall and delay=2E
>>>
>>> this is know limitation of the 'infinint' dar/libdar flavor
>>> http://dar=2Elinux=2Efree=2Efr/doc/Limitations=2Ehtml
>>>
>>>> The following command on an archive containing about 1 million
>>>> files takes 10 minutes=2E
>>>>
>>>> $ time /usr/bin/dar -l root > /dev/null
>>>>
>>>> /usr/bin/dar -l root > /dev/null  615=2E30s user 1=2E81s system 107%
>>>> cpu 9:31=2E64 total
>>>>
>>>> Memory usage peaks at 2124MB=2E
>>>>
>>>>
>>>> This delay is seen when listing, when scanning a reference archive
>>>> when creating a differential backup or when adding the archive to
>>>> a dar_manager database=2E  It also causes a delay when extracting a
>>>> file, which kind of defeats the purpose of having random access to
>>>> files=2E It would probably take as long to extract a file from a
>>>> compressed tarball=2E
>>>>
>>>> It also means that dar cannot complete a backup of my root
>>>> directory on my laptop with 2G of RAM=2E
>>>>
>>>> I compiled dar 2=2E5=2E16 with the --enable-mode=3D64 option, and the
>>>> performance greatly increased=2E
>>>>
>>>> For the exact same archive, using 64 bit integers=2E
>>>>
>>>> $ time /usr/bin/dar -l root > /dev/null
>>>>
>>>> dar -l root > /dev/null  28=2E89s user 0=2E48s system 97% cpu 30=2E25=
3
>>>> total
>>>>
>>>> A 20x speed increase=2E
>>>>
>>>> Memory usage peaked at 879MB, still high, but far better=2E
>>>> dar_manager operations were faster, but still slow=2E
>>>>
>>>> For smaller archives, the difference is less noticable=2E  It seems
>>>> that dar operations increase exponentially in CPU time as the
>>>> number of files increase=2E  For smaller archives, the difference was
>>>> less noticeable, but still there=2E
>>>
>>> the memory requirement is not exponential but proportional to the
>>> number of file saved=2E The CPU requirement is rawly proportional to
>the
>>> volume of data to treat (CRC computation, compression, encryption,
>>> =2E=2E=2E)=2E This is true for both 64 bits and infinint flavors, thou=
gh the
>>> infinint flavor does not rely on CPU integer operation where from
>its
>>> slowness=2E
>>>
>>>> The dar website seems to suggest that the cost of infinint is
>>>> modest, but my testing indicates that for what would be a regular
>>>> backup scenario, the cost is high=2E
>>>
>>> Where have you read that? This should be an error to be fixed=2E
>>>
>>>> Looking at the page listing the limitations, the limitations of 64
>>>> bit integers seems to far, far exceed what is required, and what
>>>> technology today can support anyway, and likely what technology
>>>> for many years to come can support=2E
>>>>
>>>> I suggest that inifint as an integer type should not be the
>>>> default=2E
>>>
>>> =2E=2E=2E that's to be considered, though there is warning at compilat=
ion
>>> time when you compile using infinint=2E=2E=2E thus, if the one that
>compile
>>> does not even read that warning, he will neither read documentation,
>>> limitations and will blindly complain for any problem he will meet,
>>> such people drain a lot of time and are always unsatisfied at the
>>> end=2E=2E=2E so that's usually a good thing for me they do not use dar=
, it
>>> saves me time to do more interesting things than trying to justify
>and
>>> explain =2E=2E=2E
>>>
>>>> It add in some cases unacceptable costs for no practical gain=2E
>>>> While some distributors compile with 64 bit integers (MacOSX brew),
>>>> other use the default (Fedora) which leads to a dar binary which
>>>> people may consider broken or buggy=2E
>>>
>>> Well, that's correct=2E=2E=2E
>>>
>>>> My other question is that the API uses infinint for values
>>>> internally=2E How does a libdar compiled with 64 bit integers impact
>>>> what is returned from methods returning an infinint?
>>>
>>> infinint and 64 bits flavors only differ by the way the "infinint"
>>> class is implemented=2E infinint is an alias (typedef if you prefer)
>to
>>> either "class real_infinint" or "class limitint" (32 or 64 bits
>>> integer underneath)=2E Both classes have the same interface with the
>>> reste of libdar, only their implementation differ=2E
>>>
>>> There is still infinint class up to the API=2E=2E=2E in APIv6 I've pus=
hed
>>> away a lot of internal types (including infinint) using pimpl idiom
>>> for some classes, but that was too complicated or it would have
>>> impacted performances to do it for all API related classes=2E=2E=2E th=
us
>the
>>> API remains indirectly dependent on either real_infinint/limitint
>>> class used in libdar=2E I other words, if you program has been
>>> dynamically linked with libdar64 it won't be possible to have it
>>> dynamically linked with libdar (relying on infinint), at least
>today=2E
>>> I have not done the test with APIv6 but I pretty sure it wont work=2E
>>>
>>>> I plan to possible use a linked-in libdar compiled with 64 bit
>>>> integers to ensure good performance=2E  Does infinint convert
>>>> internall from a native 64 bit to an infinint type?
>>>
>>> Not exactly=2E both classes (limitint and real_infinint) do the same
>>> thing in particular they store/read integers the same way into a dar
>>> archive=2E So the resulting archive is the same=2E If an integer is to=
o
>>> large to be handled by class limitint, the class will detect
>overflow
>>> during arithmetic operation or while reading integer from an archive
>>> and libdar will abort with an Elimitint exception=2E
>>>
>>> Historically libdar relied on real_infinint (class was named
>infinint
>>> at that time) but due to poor performances the limitint class has
>been
>>> created to be substitued to class infinint (now renamed as
>>> real_infinint)=2E Internally dar does not directly manipulate 64 bits
>>> intergers, for dates, for sizes, for offset, for anything, unless
>when
>>> dealing with system calls and library calls, where the "infinint"
>>> class has the ability to convert from and to those classical integer
>>> types like size_t and the like=2E
>>>
>>> So if your plan is to statically link your program with libdar64
>there
>>> is no issue, it will work flawlessly=2E
>>>
>>>> Thanks, Dennis
>>>
>>> Cheers,
>>> Denis
>>>
>>>
>>=20
>>=20
>>=20
>>=20
>>
>-------------------------------------------------------------------------=
-----
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot=2Eorg! http://sdm=2Elink/slashdot
>> _______________________________________________
>> Dar-libdar_api mailing list
>> Dar-libdar_api@lists=2Esourceforge=2Enet
>> https://lists=2Esourceforge=2Enet/lists/listinfo/dar-libdar_api
>>=20

------4UCAUJGAU2DZCH830U693JSNXJ14SI
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body>Hi Dennis,<br>
<br>
learning by example is always the best=2E<br>
Learning and making life easier was also my motivation for writing Gdar=2E=
<br>
I haven&#39;t looked on dar_manager in detail yet, but a decent versioning=
 of archived files is great=2E Would be nice to have a GUI there :)<br>
<br>
Hope Gdar worked for you=2E Haven&#39;t had much time in between to work o=
n it=2E<br>
<br>
Yes, my backup solution would also be based on libdar=2E<br>
<br>
The inhibit shutdown topic is unfortunately not a simple one=2E<br>
A solution for all Desktop environments and Distributions would of course =
be preferable=2E<br>
But I also like a convenient user experience=2E I would be happy to have a=
 nice fitting solution for KDE and Gnome, for all other environments there =
could be a backup solution=2E<br>
The thing with overwriting the close event, like Editors are doing it, wor=
ks well=2E But it requires a program Window=2E As far as I know, this does =
not work with a background process, without having a permanent Window=2E<br=
>
A solution based on systemd would be nice, but the inhibit shutdown does o=
nly work if the shutdown is triggered directly via systemd=2E I could not g=
et it working with the shutdown command, or if the shutdown is initiated vi=
a the desktop=2E<br>
<br>
Do you see my point?<br>
But I think this discussion is nothing special about the libdar API :)<br>
<br>
Best regards,<br>
Tobias<br><br><div class=3D"gmail_quote">Am 10=2E August 2018 12:33:21 MES=
Z schrieb Dennis Katsonis &lt;dennisk@netspace=2Enet=2Eau&gt;:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 08/10/2018 05:13 PM, Tobias Specht wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-=
left: 1px solid #729fcf; padding-left: 1ex;"> Hi Dennis,<br> <br> nice to h=
ear you are planing to write a backup application with libdar=2E<br> I'm us=
ing the libdar API with my small tool Gdar myself:<br> <a href=3D"https://g=
ithub=2Ecom/peckto/gdar">https://github=2Ecom/peckto/gdar</a><br> <a href=
=3D"http://www=2Epeckto=2Ede/gdar/gdar">http://www=2Epeckto=2Ede/gdar/gdar<=
/a> (Webseite having currently some linking <br> problems=2E=2E=2E)<br> It'=
s GTK though=2E Gdar can only extract dar archives at the moment=2E<br> Fee=
l free to work with my code, or use it as an libdar example :)<br> <br></bl=
ockquote><br><br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt=
 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I'm =
planing a larger tool with automated backup too=2E<br> But I'm still in the=
 planing phase=2E=2E=2E<br> Trying to solve some general problems with back=
ups in desktop environments,<br> like inhibit/delay shutdown:<br> <a href=
=3D"https://forum=2Ekde=2Eorg/viewtopic=2Ephp?f=3D305&amp;t=3D141575">https=
://forum=2Ekde=2Eorg/viewtopic=2Ephp?f=3D305&amp;t=3D141575</a> <br> If you=
 have an idea on it, let me know=2E<br> <br></blockquote><br>Thank you=2E  =
Even though I've started, I'm still thinking it might be<br>better to work =
with an existing program than create yet another program=2E<br> I'm a self-=
taught hobby programmer, and part of the motive is simply<br>having somethi=
ng maybe worthwhile to work on=2E  It's actually dar_manager<br>and the dat=
abase which interests me more, and allowing the user to<br>easily see which=
 versions of which files are in their backup, and<br>restore them=2E  Resto=
ration from backups is more often to recover a small<br>number of accidenta=
lly deleted or overwritten files, than full system<br>restores, or perhaps =
to see a file as it was some time ago=2E<br><br>I played around with GDar a=
 couple of years ago or so=2E<br><br>Is this tool you are working on going =
to be libdar based?<br><br>As for the shutdown, I don't know how to do it u=
nder KDE, and I don't<br>think you can (with good reason)=2E  The answer pr=
ovided in that thread,<br>where I presume the mainwindow overrides the clos=
eEvent slot to at least<br>give a warning is probably the best one=2E<br><b=
r>The problem is, if it were possible, it would only work under KDE=2E  Run=
<br>the software under FVWM, or Fluxbox, or something else, and it won't<br=
>inhibit closure of the windowing system=2E  This would lead to users<br>ha=
ving incomplete backups, possibly without them knowing=2E  It also<br>doesn=
't inhibit closure from another user logged in, or the root user=2E<br><br>=
I would use systemd-inhibit=2E<br><br>See the second answer here=2E<br><a h=
ref=3D"https://unix=2Estackexchange=2Ecom/questions/34489/how-to-disable-sh=
utdown-so-that-an-important-process-cannot-be-interrupted#264745">https://u=
nix=2Estackexchange=2Ecom/questions/34489/how-to-disable-shutdown-so-that-a=
n-important-process-cannot-be-interrupted#264745</a><br><br><br><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1=
px solid #729fcf; padding-left: 1ex;"> About your initial problem, I'm usin=
g fedora and dar as an rpm myself=2E<br> Did you write the packet maintaine=
r about the compiler flag?<br> Maybe he can add it to the building instruct=
ions=2E<br> <br></blockquote><br>Yes, I did make the suggestion=2E<br><br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; bord=
er-left: 1px solid #729fcf; padding-left: 1ex;"> Hi Denis :)<br> <br> nice =
to hear you are improving the libdar API=2E<br> Will have a look on it=2E<b=
r> <br> Best regards,<br> Tobias<br> <br> Am Donnerstag, 9=2E August 2018, =
22:29:11 CEST schrieb Denis Corbin:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #ad7fa8; padding=
-left: 1ex;"> On 09/08/2018 13:37, Dennis Katsonis wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px =
solid #8ae234; padding-left: 1ex;"> Hello,<br></blockquote><br> Hello Denni=
s,<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=
=2E8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> I am developin=
g a front end for Dar which is intended not just to<br> provide a graphical=
 way of creating archive, but also provide<br> basic backup management=2E  =
The application will be written using the<br> Qt toolkit and using libdar d=
irectly=2E<br></blockquote><br> nice! :)<br><br> Be aware that next to come=
 major release 2=2E6=2E0 brings some API<br> re-design to simplify the use =
(less libdar specify auxiliary types)<br> and added new features=2E though =
there will be the same API in the<br> specific 'libdar5' namespace and I wi=
ll be available to help you<br> migrating to the API v6 upon request=2E<br>=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex;=
 border-left: 1px solid #8ae234; padding-left: 1ex;"> I note that the versi=
on of dar compiled for Fedora uses the<br> unlimited integer size=2E  The p=
erformance of dar on archives with<br> large numbers of files is not satisf=
actory, and would unfortunately<br> also mean that the graphical applicatio=
n would stall and delay=2E<br></blockquote><br> this is know limitation of =
the 'infinint' dar/libdar flavor<br> <a href=3D"http://dar=2Elinux=2Efree=
=2Efr/doc/Limitations=2Ehtml">http://dar=2Elinux=2Efree=2Efr/doc/Limitation=
s=2Ehtml</a><br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt =
0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> The f=
ollowing command on an archive containing about 1 million<br> files takes 1=
0 minutes=2E<br><br> $ time /usr/bin/dar -l root &gt; /dev/null<br><br> /us=
r/bin/dar -l root &gt; /dev/null  615=2E30s user 1=2E81s system 107%<br> cp=
u 9:31=2E64 total<br><br> Memory usage peaks at 2124MB=2E<br><br><br> This =
delay is seen when listing, when scanning a reference archive<br> when crea=
ting a differential backup or when adding the archive to<br> a dar_manager =
database=2E  It also causes a delay when extracting a<br> file, which kind =
of defeats the purpose of having random access to<br> files=2E It would pro=
bably take as long to extract a file from a<br> compressed tarball=2E<br><b=
r> It also means that dar cannot complete a backup of my root<br> directory=
 on my laptop with 2G of RAM=2E<br><br> I compiled dar 2=2E5=2E16 with the =
--enable-mode=3D64 option, and the<br> performance greatly increased=2E<br>=
<br> For the exact same archive, using 64 bit integers=2E<br><br> $ time /u=
sr/bin/dar -l root &gt; /dev/null<br><br> dar -l root &gt; /dev/null  28=2E=
89s user 0=2E48s system 97% cpu 30=2E253<br> total<br><br> A 20x speed incr=
ease=2E<br><br> Memory usage peaked at 879MB, still high, but far better=2E=
<br> dar_manager operations were faster, but still slow=2E<br><br> For smal=
ler archives, the difference is less noticable=2E  It seems<br> that dar op=
erations increase exponentially in CPU time as the<br> number of files incr=
ease=2E  For smaller archives, the difference was<br> less noticeable, but =
still there=2E<br></blockquote><br> the memory requirement is not exponenti=
al but proportional to the<br> number of file saved=2E The CPU requirement =
is rawly proportional to the<br> volume of data to treat (CRC computation, =
compression, encryption,<br> =2E=2E=2E)=2E This is true for both 64 bits an=
d infinint flavors, though the<br> infinint flavor does not rely on CPU int=
eger operation where from its<br> slowness=2E<br><br><blockquote class=3D"g=
mail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8=
ae234; padding-left: 1ex;"> The dar website seems to suggest that the cost =
of infinint is<br> modest, but my testing indicates that for what would be =
a regular<br> backup scenario, the cost is high=2E<br></blockquote><br> Whe=
re have you read that? This should be an error to be fixed=2E<br><br><block=
quote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-le=
ft: 1px solid #8ae234; padding-left: 1ex;"> Looking at the page listing the=
 limitations, the limitations of 64<br> bit integers seems to far, far exce=
ed what is required, and what<br> technology today can support anyway, and =
likely what technology<br> for many years to come can support=2E<br><br> I =
suggest that inifint as an integer type should not be the<br> default=2E<br=
></blockquote><br> =2E=2E=2E that's to be considered, though there is warni=
ng at compilation<br> time when you compile using infinint=2E=2E=2E thus, i=
f the one that compile<br> does not even read that warning, he will neither=
 read documentation,<br> limitations and will blindly complain for any prob=
lem he will meet,<br> such people drain a lot of time and are always unsati=
sfied at the<br> end=2E=2E=2E so that's usually a good thing for me they do=
 not use dar, it<br> saves me time to do more interesting things than tryin=
g to justify and<br> explain =2E=2E=2E<br><br><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; =
padding-left: 1ex;"> It add in some cases unacceptable costs for no practic=
al gain=2E<br> While some distributors compile with 64 bit integers (MacOSX=
 brew),<br> other use the default (Fedora) which leads to a dar binary whic=
h<br> people may consider broken or buggy=2E<br></blockquote><br> Well, tha=
t's correct=2E=2E=2E<br><br><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; padding-left: 1ex;=
"> My other question is that the API uses infinint for values<br> internall=
y=2E How does a libdar compiled with 64 bit integers impact<br> what is ret=
urned from methods returning an infinint?<br></blockquote><br> infinint and=
 64 bits flavors only differ by the way the "infinint"<br> class is impleme=
nted=2E infinint is an alias (typedef if you prefer) to<br> either "class r=
eal_infinint" or "class limitint" (32 or 64 bits<br> integer underneath)=2E=
 Both classes have the same interface with the<br> reste of libdar, only th=
eir implementation differ=2E<br><br> There is still infinint class up to th=
e API=2E=2E=2E in APIv6 I've pushed<br> away a lot of internal types (inclu=
ding infinint) using pimpl idiom<br> for some classes, but that was too com=
plicated or it would have<br> impacted performances to do it for all API re=
lated classes=2E=2E=2E thus the<br> API remains indirectly dependent on eit=
her real_infinint/limitint<br> class used in libdar=2E I other words, if yo=
u program has been<br> dynamically linked with libdar64 it won't be possibl=
e to have it<br> dynamically linked with libdar (relying on infinint), at l=
east today=2E<br> I have not done the test with APIv6 but I pretty sure it =
wont work=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt =
0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> I pla=
n to possible use a linked-in libdar compiled with 64 bit<br> integers to e=
nsure good performance=2E  Does infinint convert<br> internall from a nativ=
e 64 bit to an infinint type?<br></blockquote><br> Not exactly=2E both clas=
ses (limitint and real_infinint) do the same<br> thing in particular they s=
tore/read integers the same way into a dar<br> archive=2E So the resulting =
archive is the same=2E If an integer is too<br> large to be handled by clas=
s limitint, the class will detect overflow<br> during arithmetic operation =
or while reading integer from an archive<br> and libdar will abort with an =
Elimitint exception=2E<br><br> Historically libdar relied on real_infinint =
(class was named infinint<br> at that time) but due to poor performances th=
e limitint class has been<br> created to be substitued to class infinint (n=
ow renamed as<br> real_infinint)=2E Internally dar does not directly manipu=
late 64 bits<br> intergers, for dates, for sizes, for offset, for anything,=
 unless when<br> dealing with system calls and library calls, where the "in=
finint"<br> class has the ability to convert from and to those classical in=
teger<br> types like size_t and the like=2E<br><br> So if your plan is to s=
tatically link your program with libdar64 there<br> is no issue, it will wo=
rk flawlessly=2E<br><br><blockquote class=3D"gmail_quote" style=3D"margin: =
0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> T=
hanks, Dennis<br></blockquote><br> Cheers,<br> Denis</blockquote><br><br> <=
br> <br> <br> <br><hr><br> Check out the vibrant tech community on one of t=
he world's most<br> engaging tech sites, Slashdot=2Eorg! <a href=3D"http://=
sdm=2Elink/slashdot">http://sdm=2Elink/slashdot</a><br><hr><br> Dar-libdar_=
api mailing list<br> Dar-libdar_api@lists=2Esourceforge=2Enet<br> <a href=
=3D"https://lists=2Esourceforge=2Enet/lists/listinfo/dar-libdar_api">https:=
//lists=2Esourceforge=2Enet/lists/listinfo/dar-libdar_api</a><br> <br></blo=
ckquote><br><br></pre></blockquote></div></body></html>
------4UCAUJGAU2DZCH830U693JSNXJ14SI--


--===============3031389238511942919==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============3031389238511942919==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Dar-libdar_api mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

--===============3031389238511942919==--