Kostya Shishkov <[email protected]> writes: > On Sun, Jul 01, 2012 at 11:10:29AM +0100, Måns Rullgård wrote: >> Kostya Shishkov <[email protected]> writes: >> >> >> > +/** >> >> > + * @brief Encrypts using the Blowfish algorithm. >> >> > + * >> >> > + * @param bf an AVBlowfish context >> >> > + * @param xl left eight bytes halves of input to be encrypted >> >> > + * @param xr right eight bytes halves of input to be encrypted >> >> > + */ >> >> > +void av_blowfish_encrypt(struct AVBlowfish *bf, uint32_t *xl, uint32_t >> >> > *xr); >> >> >> >> Eight bytes where? uint32_t is four bytes. Whatever this is trying to >> >> say, it is confusing. >> > >> > This function encrypts block of eight bytes passed as two 32-bit integers. >> >> That's a weird interface. Why not pass a pointer to uint8_t? > > My guess is that it was done after traditional way of block cyphers. > But adding at least some functions for encrypt/decrypt input as a stream of > bytes would be good IMO.
When does anyone ever have the data in pairs of ints rather than a block of chars? This would be much easier to use if it accepted an arbitrary-length piece of data and iterated over it, padding the final block as necessary. The interface in the patch is not only inconvenient for most use cases, it also requires 32-bit alignment of the data, which may not always be easy to guarantee. The overhead of an unaligned access (AV_RN32) is minimal compared to cost of processing. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
