[Question] Redundant ternary operators in nhpoly1305/sha256 digest functions?

[Question] Redundant ternary operators in nhpoly1305/sha256 digest functions?

[Jang Ingyu]

From: Ingyu Jang <ingyujang25@korea.ac.kr>

Hi,

I noticed that in arch/x86/crypto/, several digest functions use
the ternary operator (?:) to chain function calls:

In nhpoly1305-avx2-glue.c and nhpoly1305-sse2-glue.c:

  return crypto_nhpoly1305_init(desc) ?:
         nhpoly1305_xxx_update(desc, src, srclen) ?:
         crypto_nhpoly1305_final(desc, out);

In sha256_ssse3_glue.c (sha256_ssse3_digest, sha256_avx_digest,
sha256_avx2_digest, sha256_ni_digest):

  return sha256_base_init(desc) ?:
         sha256_xxx_finup(desc, data, len, out);

However, all the functions being checked always return 0:
  - crypto_nhpoly1305_init() always returns 0
  - nhpoly1305_xxx_update() always returns 0
  - crypto_nhpoly1305_final() always returns 0
  - sha256_base_init() always returns 0

This makes the short-circuit evaluation of ?: unnecessary.

Is this intentional defensive coding for potential future changes,
or could this be cleaned up?

Thanks,
Ingyu Jang

Re: [Question] Redundant ternary operators in nhpoly1305/sha256 digest functions?

[Eric Biggers]

On Thu, Jan 15, 2026 at 12:38:39AM +0900, Jang Ingyu wrote:
> From: Ingyu Jang <ingyujang25@korea.ac.kr>
> 
> Hi,
> 
> I noticed that in arch/x86/crypto/, several digest functions use
> the ternary operator (?:) to chain function calls:
> 
> In nhpoly1305-avx2-glue.c and nhpoly1305-sse2-glue.c:
> 
>   return crypto_nhpoly1305_init(desc) ?:
>          nhpoly1305_xxx_update(desc, src, srclen) ?:
>          crypto_nhpoly1305_final(desc, out);
> 
> In sha256_ssse3_glue.c (sha256_ssse3_digest, sha256_avx_digest,
> sha256_avx2_digest, sha256_ni_digest):
> 
>   return sha256_base_init(desc) ?:
>          sha256_xxx_finup(desc, data, len, out);
> 
> However, all the functions being checked always return 0:
>   - crypto_nhpoly1305_init() always returns 0
>   - nhpoly1305_xxx_update() always returns 0
>   - crypto_nhpoly1305_final() always returns 0
>   - sha256_base_init() always returns 0
> 
> This makes the short-circuit evaluation of ?: unnecessary.

This code was written to be compatible with the crypto_shash API, which
is defined to have an error code for every hashing operation.  So it was
defensive coding to assume that an error might occur, even though
apparently in these particular cases no error was possible.

> Is this intentional defensive coding for potential future changes,
> or could this be cleaned up?

It was already cleaned up as part of the migration into lib/crypto/,
where hashing operations now always succeed and return void.  SHA-256
was cleaned up in 6.17.  The NH cleanups are queued for 6.20.

- Eric