On Mon, 2020-11-09 at 01:18 +, Daniel Golle wrote:
> On Mon, Nov 09, 2020 at 07:20:35AM +0900, Martin Schanzenbach wrote:
> > Well, good catch ;)
> >
> > I agree with David that this very likely was not the issue.
> > We all are on LE systems (unless you have an old powerbook or a
> > sparc?).
On Mon, Nov 09, 2020 at 07:20:35AM +0900, Martin Schanzenbach wrote:
> Well, good catch ;)
>
> I agree with David that this very likely was not the issue.
> We all are on LE systems (unless you have an old powerbook or a
> sparc?). Which means that the only reason why that assert may fail is
> if
Well, good catch ;)
I agree with David that this very likely was not the issue.
We all are on LE systems (unless you have an old powerbook or a
sparc?). Which means that the only reason why that assert may fail is
if the caller forgot to convert the size field to BE.
My money is on this: Your cha
I thought so too. That's why I was really surprised that it made any
difference because it was also in an assert statement.
Maybe I changed anything else during configuration which lead to
passing the testcases but I can't think of anything.
Anyway in worst case, nothing changed by that commit. O
I don't understand how swapping htonl with ntohl made any difference,
they are the same function. If you're on a big-endian system they both
do nothing, if you're on a little-endian system they both swap byte
order, you'd have to be on some insane "middle-endian" system where one
rotates left and t
Hey,
funny story... I was actually debugging my code of the messenger
service and encountered a weird bug which was caused by an assert in
one of my latest changes (the signing via EGO keys).
It turned out the assert failed because of a wrongly used htonl()
instead of ntohl() to check the signatu
