Nikos Mavrogiannopoulos nmav@gnutls.org writes:
In modern compilers you cannot rely on that. The constructions if(0){} and other impossible situations are optimized out early.
Examples? I would expect any serious C compiler to do basic type checking of dead code (even if I don't expect to get all warnings generated by optimization passes, i.e., the warnings you normally get only if you compile with -O). If gcc stopped doing type checking on dead code, I would likely file a bug report.
Can you give an example usage where you'd want to get a compiler warning, but you don't get one?
The change of the cipher_func to accept a size_t instead of unsigned. https://gitorious.org/gnutls/gnutls/commit/488cfe9a57840faeb2e35250757d8d33d...
Hmm. In that case, I'd recommend declaring the function as
static nettle_cipher_func padock_aes_encrypt;
(or with nettle_crypt_func, before the introduction of nettle_cipher_func). Then you would have gotten a warning for mismatch between declaration and definition, when that type was changed. But that's of little help now, I guess.
What do you suggest to do with the nettle macros? They are intended for use with the various _CTX() macros, and for that purpose, I think the current definitions with casts and all are adequate, so I'd prefer to not simply delete the cast.
We could add additional macros, say
#define GCM_ENCRYPT_NO_CAST(ctx, encrypt, length, dst, src) \ gcm_encrypt(&(ctx)->gcm, &(ctx)->key, &(ctx)->cipher, \ (encrypt), (length), (dst), (src))
Question is, does that solve a real problem? My initial feeling is that when there's nothing "magic" left inside the macro, using it provides little benefit; code would likely be clearer by calling gcm_encrypt directly. What do you think?
Regards, /Niels