On Tue, 28 Dec 2021 at 03:34, Troy Lee <leet...@gmail.com> wrote: > > Hi Klaus, > > On Thu, Dec 23, 2021 at 11:57 PM Klaus Heinrich Kiwi > <kl...@klauskiwi.com> wrote: > > > > Em qui., 23 de dez. de 2021 às 09:54, Cédric Le Goater <c...@kaod.org> > > escreveu: > > > > > > [ Adding Klaus ] > > > > Thanks Cedric. It's been a while since I've looked at this but I'll do my > > best.. > > > > > > > > On 12/22/21 03:22, Troy Lee wrote:
> > > > + /* > > > > + * Read the message length in bit from last 64/128 bits > > > > + * and tear the padding bits from iov > > > > + */ > > > > + uint64_t stream_len; > > > > + > > > > + memcpy(&stream_len, iov[i].iov_base + iov[i].iov_len - > > > > 8, 8); > > > > + stream_len = __bswap_64(stream_len) / 8; > > > > + > > > > I no longer have access to the aspeed workbook I guess, but what is > > the actual specification here? is the message length 64 or 128 bits? > > and bswap seems arch-dependent - you probably want to be explicit if > > this is big or little-endian and use the appropriate conversion > > function. > The message length is described in RFC4634: > - SHA224 or SHA256 should be 64-bit. > - SHA384 or SHA512 should be 128-bit. > And it should be in big-endian. You can read a 64-bit BE value with uint64_t val = ldq_be_p(iov[i].iov_base + iov[i].iov_len - 8); or similar. (We don't have a similar function for 128 bits because there's no fully-portable native C data type for that.) -- PMM
