[gnutls-devel] GnuTLS | crypto-selftests: mark CFB8 block sizes tests optional (!1743)

[Read-only notification of GnuTLS library development activities]

Alexander Sosedkin commented on a discussion on lib/crypto-selftests.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1743#note_1401471547

> -		if (!(flags & GNUTLS_SELF_TEST_FLAG_ALL) || ret < 0) \
> -		return ret
> +#define CASE(x, func, vectors)			\
> +	case x:					\
> +		CHECK(x, func, vectors)
>  
> -#define NON_FIPS_CASE(x, func, vectors)                                      \
> -	case x:                                                              \
> -		if (_gnutls_fips_mode_enabled() == 0) {                      \
> -			ret = func(x, V(vectors), flags);                    \
> -			if (!(flags & GNUTLS_SELF_TEST_FLAG_ALL) || ret < 0) \
> -				return ret;                                  \
> -		}
> +#define NON_FIPS_CASE(x, func, vectors)			\
> +	case x:						\
> +		if (_gnutls_fips_mode_enabled() == 0)	\

I'm not sure I understand your concern. For a self-contained macro designed to mimic a function call as closely as possible and thus aiming for one statement, stray `;` might cause problems, yes. But I'm not sure whether that matters for a macro that's meta enough to include pieces of control flow like "case" inside it.

I find incorporating `do { ... } while (0)` into `CHECK` a good idea. For the current state of affairs, it is both difficult to analyze the across-macro immplications and difficult to spot that one needs to mind them in the first place.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1743#note_1401471547
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20230523/1118ad84/attachment.html>