Amalgamation #596
Amalgamation #596
Conversation
sjaeckel
force-pushed
the
add-pem-support
branch
from
5e59a9d to
3672210
Compare
sjaeckel
force-pushed
the
add-pem-support
branch
2 times, most recently
from
f486b8c to
abbeeaa
Compare
sjaeckel
force-pushed
the
add-pem-support
branch
7 times, most recently
from
30daf31 to
473ae9f
Compare
sjaeckel
force-pushed
the
add-pem-support
branch
12 times, most recently
from
37b9b8d to
33c35d0
Compare
sjaeckel
force-pushed
the
add-pem-support
branch
4 times, most recently
from
4d9823f to
ad1499d
Compare
sjaeckel
force-pushed
the
add-pem-support
branch
2 times, most recently
from
6f506cb to
2594f3a
Compare
sjaeckel
force-pushed
the
amalgamation
branch
3 times, most recently
from
b975c98 to
c8391c4
Compare
sjaeckel
force-pushed
the
amalgamation
branch
from
c8391c4 to
0165053
Compare
|
Cool! Just tested it, it works great! Thank you! It still includes aes_tab.c, safe_tab.c, sober128tab.c and whirltab.c, but very easy to manage. I will run some tests on TLSe using the new amalgamated version, but from the first runs it looks absolutely great! Thanks! |
better? |
|
Can't quite see the point with this sort of amalgamation, but if someone finds it useful, why not? |
What do you mean by "can't see the point"? What would you prefer/do instead? |
My remark wasn't specific to libtomcrypt. Amalgamation showed up on my radar just a few months ago, and I've yet to understand what's the underlying need. I can understand wanting to amalgamate a gazillion dependencies (I've looked at some rust projects and OMG the number of them!), but otherwise?... But like I said, if someone does find this useful, yeah ok sure, why not? |
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
* de-duplicate `struct oid_to_pbes` * add makefile target * add amalgamation to release * fix `small` demo * add header guards for `tomcrypt_private.h` * update docs * add CI job with amalgamated library Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
```
pre_gen/tomcrypt_amalgam.c: In function ‘pkcs_1_oaep_encode’:
pre_gen/tomcrypt_amalgam.c:64485:18: warning: ‘DB’ may be used uninitialized [-Wmaybe-uninitialized]
64485 | if ((err = hash_memory(lparam_hash_used, DB, 0, DB, &x)) != CRYPT_OK) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pre_gen/tomcrypt_amalgam.c:22613:5: note: by argument 2 of type ‘const unsigned char *’ to ‘hash_memory’ declared here
22613 | int hash_memory(int hash, const unsigned char *in, unsigned long inlen, unsigned char *out, unsigned long *outlen)
| ^~~~~~~~~~~
```
Use `out` instead of `DB`, since `out` is `LTC_ARGCHK`'ed.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Instead of wrongfully always returning OK, return the real error code.
This was uncovered by the amalgamation via the warning:
```
pre_gen/tomcrypt_amalgam.c: In function ‘der_decode_custom_type_ex’:
pre_gen/tomcrypt_amalgam.c:49820:10: warning: ‘*(unsigned int *)((char *)&ident + offsetof(ltc_asn1_list, type))’ may be used uninitialized [-Wmaybe-uninitialized]
49820 | if ((ident.type != root->type) ||
| ^
pre_gen/tomcrypt_amalgam.c:49780:18: note: ‘*(unsigned int *)((char *)&ident + offsetof(ltc_asn1_list, type))’ was declared here
49780 | ltc_asn1_list ident;
| ^~~~~
```
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
sjaeckel
force-pushed
the
amalgamation
branch
from
864b1ae to
92aef0a
Compare
I guess the most important is "lazyness". You don't want to manage all those libraries, so you simply take the single C files and add them directly to your project. |
|
I confirm the "lazyness" :). Also, it is simpler to manage when writing wrappers for various interpreters or microcontrollers. A few years ago I've seen this idea on sqlite (which offers an amalgamated version) - I just add it to my project and it just worked. Very easy when checking out libraries, for example: I come across a new XML library and I want to try it by using it in the simplest mode possible. I just write a few lines of C code and just compile the whole thing without any need of makefiles or cmake. This doesn't mean that this is the best way, but it is "quick to try". |
|
Ok, I can understand that part. I immediately find it a pity, then, that C has some unfortunate limitations that makes such things difficult, 'cause for example, static things that are meant for just one translation unit (source file) suddenly become "public" throughout the whole library. I saw a blog on this, by someone who tried to amalgamate OpenSSL.... oh boy. Side note: I have just recently gotten interested in Zig, BTW, and think it's much more conducive to amalgamation. Nothing I really thought of before, but you got me thinking, so thank you for showing me your points |
Checklist
This adds support to create and build an amalgamated version of the library, which is maybe useful for some.