bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: noloader@gmail.com
Cc: bug-gnulib@gnu.org
Subject: Re: test-bitrotate.c missing test cases
Date: Sun, 29 Mar 2020 17:40:54 +0200	[thread overview]
Message-ID: <2790438.WTOhFlp6Ne@omega> (raw)
In-Reply-To: <CAH8yC8k8D3Wd3NkdmzMgaSFx6M1MRgHWx4q1FBh3TZfh2s0HAg@mail.gmail.com>

Jeffrey,

> Forgive my ignorance... No'oping 0 leaks timing information

There are only few algorithms where leaking timing information is an
issue. For most of the code we deal with, the developer wants to get
optimal performance.

> I also don't think developers are going to write a rotate like:
> 
>     if (n != 0)
>         x = rotr32(x, n);

Sure they will. Here's an example from lib/vasnprintf.c, where a shift
count of 0 is treated specially:


      /* Copy a, shifting it left by s bits, yields r.
         Memory layout:
         At the beginning: r = roomptr[0..a_len],
         at the end: r = roomptr[0..b_len-1], q = roomptr[b_len..a_len]  */
      r_ptr = roomptr;
      if (s == 0)
        {
          memcpy (r_ptr, a_ptr, a_len * sizeof (mp_limb_t));
          r_ptr[a_len] = 0;
        }
      else
        {
          const mp_limb_t *sourceptr = a_ptr;
          mp_limb_t *destptr = r_ptr;
          mp_twolimb_t accu = 0;
          size_t count;
          for (count = a_len; count > 0; count--)
            {
              accu += (mp_twolimb_t) *sourceptr++ << s;
              *destptr++ = (mp_limb_t) accu;
              accu = accu >> GMP_LIMB_BITS;
            }
          *destptr++ = (mp_limb_t) accu;
        }


Bruno



  reply	other threads:[~2020-03-29 15:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-29  9:00 test-bitrotate.c missing test cases Jeffrey Walton
2020-03-29 10:27 ` Jeffrey Walton
2020-03-29 12:53 ` Bruno Haible
2020-03-29 13:10   ` Jeffrey Walton
2020-03-29 15:40     ` Bruno Haible [this message]
2020-03-31  6:31       ` Jeffrey Walton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2790438.WTOhFlp6Ne@omega \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=noloader@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).