I'm sorry, I still don't fully understand the point you are trying to make, but I'll try...
On Mon, Dec 02, 2013 at 08:26:04PM +0000, Albretch Mueller wrote: > as I mentioned in relation to adler32's hashing implementation, there > are quite a few important libraries heavily using it: > ~ > > http://packages.debian.org/search?searchon=contents&keywords=adler32&mode=filename&suite=stable&arch=any This isn't a very reliable way to ascertain this, because... > I think code correlation issues, even if not a totally trivial, > syntactic problem (compilers could take care of), pertains only to > adler32's hashing implementation, yet in the case of such relatively > straightforward and simple piece of code (more than) 16 libraries > include their own implementations: > ~ > golang | grub | lib32go0 | lib64go0 | libavutil | libbotan1 | > libcrypto++ | libgcj12 | libghc | libgo0 | libsrecord | libwireshark | > openswan | php5 | ri1 | tcllib ...You are listing binary package search results. Several of those binary packages are from the same source package (e.g., lib32go0, lib64go0, libgo0 all belong to the source package gcc-4.7). The simplicity of the hash implementation is one reason that there is such code duplication. I recall once looking for an MD5 library for a program I was working on and finding instead embedded copies of MD5 implementations everywhere. I eventually took the public domain one from dpkg. Libraries don't come for free. The work required to create a shared "libmd5" library would far outweigh the work writing the algorithm itself. The same is probably true for all individual hash algorithms. Shared libraries that offer a collection of hashes do exist, there is also a cost for a downstream user to use a library: license concerns (GPL vs. openssl for example); portability issues; increasing the complexity of source builds for some. > In the search results above, golang > ~ > and many such as rsync and zlib do their own adler32 hashing in code modules > ~ Even when an appropriate shared library does exist, you could only use it in C directly: for C++ or scripting languages you would need to wrap the C library in native bits to make it work. To do this for a simple algorithm and the wrapping would once again outweigh the algorithm. In many cases, you would also lose one of the reasons you were writing in a higher-level language in the first place, with your library interface either a close match to the C semantics or a thick abstraction layer. In some cases you would get better performance re-implementing the algorithm. In some cases, of course, you get better performance using a C (or assembler) implementation. > For example, this is what {kadav, swift} @cs.wisc.edu say about > (similar) code patterns: > ~ > http://pages.cs.wisc.edu/~kadav/study/study.pdf I don't see the resemblance between this paper and what I have interpreted you as trying to say above. P.S.: what's with all the tildes? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203101350.ga4...@bryant.redmars.org
