Yo Achim! On Sun, 19 Feb 2017 13:50:16 +0100 Achim Gratz <strom...@nexgo.de> wrote:
> While hunting for changes that might have affected the DCF driver I've
> come across this gem:
>
> --8<---------------cut here---------------start------------->8---
> @@ -433,7 +433,13 @@ struct peer {
> #define CRYPTO_TO_ZERO(p) ((char *)&((p)->clear_to_zero))
> #define END_CRYPTO_TO_ZERO(p) ((char
> *)&((p)->end_clear_to_zero)) #define LEN_CRYPTO_TO_ZERO
> (END_CRYPTO_TO_ZERO((struct peer *)0) \
> - - CRYPTO_TO_ZERO((struct peer
> *)0)) +
> +/*
> + * It's ugly that refid is sometimes treated as a uint32_t and
> sometimes
> + * as a string; that should be fixed. Using this in memcpy() at least
> + * contains the problem.
> + */
> +#define REFIDLEN sizeof(uint32_t)
>
> #define LEN_PKT_NOMAC 48 /* min header length */
>
> --8<---------------cut here---------------end--------------->8---
>
> Luckily the macro isn't used anywhere, so it's not been doing any
> harm. In fact, all three CRYPTO macros are unused and can be
> eliminated.
I am unclear which macro you are referring to? I thought were you talking
about REFIDLEN, that is used a lot.
Can you be specific on which macros you think can be removed?
I think you mean these three?
spidey ntpsec # fgrep CRYPTO_TO_ * -r
include/ntp.h:#define CRYPTO_TO_ZERO(p) ((char *)&((p)->clear_to_zero))
include/ntp.h:#define END_CRYPTO_TO_ZERO(p) ((char
*)&((p)->end_clear_to_zero))
include/ntp.h:#define LEN_CRYPTO_TO_ZERO (END_CRYPTO_TO_ZERO((struct
peer *)0) \
If you canfirm I'll remove them.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
pgp8kb_57jsMZ.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
