C standards and committees (was Re: strangest systems I've sent email from)

Mouse mouse at Rodents-Montreal.ORG
Fri May 20 21:49:23 CDT 2016

>   I'm generally not a fan of shared libraries as:

> 	1) Unless you are linking against a library like libc or
> 	libc++, a lot of memory will be wasted because the *entire*
> 	library is loaded up, unlike linking to a static library where
> 	only those functions actually used are linked into the final
> 	executable

Yes and no.  (Caveat: the following discussion assumes a number of
things which are true in currently-common implementations; in cases
where they are false, the balance may well tip the other way.)

First, except for pages touched by dynamic linking (which should be
very few if the library was built properly), the library is shared
among all copies of it in use.  In a statically linked program, this is
true only across a single executable, with shared objects, it is true
across all executables linked with that library.

Second, even if the executable is the only one using the library, most
of it is demand-paged, occupying no physical memory unless/until it's
referenced.  (It still occupies virtual memory; if virtual memory is
tight - eg, you're doing gigabyte-sized datasets on a 32-bit machine -
then this can matter.)

> 	2) because of 1, you have a huge surface area exposed that can
> 	be exploited.


Also, it exposes more attack surface in another way: it means there are
two files, not one, the modification of which can subvert the
application.  (The executable itself and the shared object.)  Add one
more for each additional shared object used.

> 	3) It's slower.  Two reasons for this:

Even to the extent this is true, in most cases, "so what"?

Most executables are not performance-critical enough for dynamic-linker
overhead to matter.  (For the few that are, or for the few cases where
lots are, yes, static linking can help.)

> I use the uintXX_t types for interoperability---known file formats
> and network protocols, and the plain (or known types like size_t)
> otherwise.

uintXX_t does not help much with "known file formats and network
protocols".  You have to either still serialize and deserialize
manually - or blindly hope your compiler adds no padding bits (eg, that
it lays out your structs exactly the way you hope it will).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

More information about the cctalk mailing list