[PATCH v4 1/3] libcrypt: make crypt() itself more modular

[William Pitcock]

Hi,

On Mon, Dec 19, 2011 at 1:30 PM, Bernhard Reutner-Fischer
<rep.dot.nop at gmail.com> wrote:
> On Dec 19, 2011 6:24 PM, "Mike Frysinger" <vapier at gentoo.org> wrote:
>>
>> all three look fine to me
>> Acked-by: Mike Frysinger <vapier at gentoo.org>
>
> I somehow fear that unrolling the macro adds considerable bloat. What are
> the size(1) of sha256 and sha512 with the macro impl?

petrie:~/uClibc$ size lib/libcrypt.a
   text    data     bss     dec     hex filename
    319      64       0     383     17f crypt.os (ex lib/libcrypt.a)
   5044       0   70229   75273   12609 des.os (ex lib/libcrypt.a)
   2624       0      35    2659     a63 md5.os (ex lib/libcrypt.a)
   1844       0       0    1844     734 sha256.os (ex lib/libcrypt.a)
   2822       0      16    2838     b16 sha256-crypt.os (ex lib/libcrypt.a)
   2431       0       0    2431     97f sha512.os (ex lib/libcrypt.a)
   3854       0      16    3870     f1e sha512-crypt.os (ex lib/libcrypt.a)

>
> Would be perfect with a func impl, most likely.

I agree that the macro approach is suboptimal for both type-safety
reasons and expansion issues, however, Ulrich's implementation uses an
inline function which is unsafe, and the macro version of the code
would need some reworking to work as a standalone function.  This also
raises the question of what to do with the function -- should we just
make an internal file for libcrypt for utility functions or just have
them as static inlined functions inside the code?

I think despite the suboptimal aspects of the macro approach, for now
we should keep it as is -- as the modifications to use a func impl
would be fairly substantial and would need to be tested extensively
verses the already known-to-be-working code.  Perhaps this should be
moved to a func impl with further cleanup of libcrypt?  I intend to
get rid of UCLIBC_HAS_CRYPT_STUB for example at some point... this
cleanup could be done at the same time.

William