[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems when linking against the profiled libc



On Mon, Dec 03, 2001 at 02:22:51PM +0200, Nadav Har'El wrote:
> On Mon, Dec 03, 2001, Adi Stav wrote about "Re: Problems when linking against the profiled libc":
> > On Sun, Dec 02, 2001 at 04:15:16PM +0200, Nadav Har'El wrote:
> > > (e.g., openssl - one of the most obfuscated libraries I've seen).
> > 
> > I thought the OpenSSL source (especially internal API's) was totally 
> > beautiful... Obviously we have very different tastes :) Takes a 
> > while to understand its abstractions, but they make perfect sense
> > when you consider what they are meant for. Rather GNUish in their C 
> > code-reuse fanaticism, I thought.
> 
> It may be beautiful if you spend a month researching it. When you just
> want to have look at it and see why something isn't exactly what you expected,
> it's a bit frustrating to see that it has a dozen static functions with the
> same name, dozens of functions written in assembly (and not just assembly -
> they have some sort of perl wizardry to convert their own file formats into
> what the assembler expects). It's a little, well..., obfuscated.
> 
> I guess that's what happens, though, when you try to get efficient function
> overloading (e.g., the function that computers a hash can use MD5 or SHA1,
> can run a function written in assembler or contact a special cryptography
> coprocessor, and so on).

Exactly... They have nearly impossible goals and restraints -- crypto
functions have to run at assembly speed, while they have to support
every sort of assembler and compiler on all architectures, implement
all algorithms and allow them to work with all versions of the 
protocol and all file formats. You have to have at least some layers 
of abstraction for that (which makes reading more difficult). But 
when you read the code with those restraints in mind you realize that 
almost without fail every solution they use is ingenious. They meet 
every one of the goals, while still being reasonably readable, and 
having effectively zero code duplication. 

I find it easiest to read the code starting from their "apps" 
directory (otherwise you can't tell where to start) and using a tag-
aware editor.

=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il