We tend to not use floating-point, yes.

This is a long lived public API I believe, so change is difficult. I also don't feel that much would be saved by converting this to fixed point unless other uses of reals are eliminated.

From memory, crypto/bio/b_print.c also uses floating point and might benefit from this attribute.

This is a long lived public API I believe, so change is difficult.

As it stands now, it's pure formatting fix that reverts addition of empty line in last modification to rand.h. No empty line means that corresponding #ifdef is part of RAND_add declaration. Removal attribute would be problematic, not re-formatting. As for RAND_poll_ex, it was recently added and there was no release with it, so it's still possible to change.

I also don't feel that much would be saved by converting this to fixed point unless other uses of reals are eliminated.

This is not about converting to fixed point, but about how floating point arguments are passed. Attribute in question makes compiler pass them through pair of integer registers, but it's still floating-point value that is passed. In practical terms it means that it would be callee's responsibility to transfer value to floating-point register, but it's done verbatim, no conversion is involved. [Well, provided that there is floating-point register. If there is none, it will just call "emulator" library, but the latter will still treat value as if it's floating-point.]

only that one function needs this attribute? ok...

Request message explicitly says "not to approval [yet]." And it also says that one should do similar thing to RAND_poll_ex...

one should do similar thing to RAND_poll_ex.

Well, not to RAND_poll_ex itself, but to RAND_poll_fn... Original formulation was "in RAND_poll_ex context".

I'd like to suggest it as a rule, no approvals till WIP is actually removed. Does it make sense?

yes that makes a great deal of sense.

BTW, RAND_poll_ex and the callback function are new; we can remove the floating-point if you want.

RAND_poll_ex and the callback function are new; we can remove the floating-point if you want.

That would be sensible. So shall be convert to bits, i.e. scale by factor of 8? Or some other factor would be appropriate, like 100?

How about just a number, 0-100, which indicates the percentage of how "random" the input is?

Percentage of len then? I.e. if you pass 3 bytes and say 50 it would correspond to 12 bits? As fair as anything else. Anybody >else< has any other suggestion?

Yes. Overall I think that most people are not qualified to give an estimate, and certainly nothing with floating point accuracy :) In fact, I think the existing API should be the "legacy" one and the new one that is integer-based should be the real implementation.

I'd like to see fractional bits in the estimate. Estimates end up a bit coarse without. Still, an argument can be made for integer bits since bits are what are being passed in. If integer bits are used, there is no need for a scale factor.

I lean towards an absolute number of bits times a scale factor for the randomness argument, rather than a percentage. A percentage guarantees a multiply or divide in the code path, an absolute argument doesn't -- not a big issue on desktop or server CPUs but it can be on embedded ones.

A scale factor of 256, e.g., comfortably provides enough precision and is an easy shift.

As can be seen I prefer bits to bytes for the count.

I defer to @paulidale

I'd like to see fractional bits in the estimate.

And it's suggested to break every bit to 100 fractions :-) But on serious note I for one would argue against scales like 256. It would make it less readable, because humans are more accustomed to decimals. Binary code with such scale would surely be more efficient, but computers are meant to be makeing human life easier, not vice versa. I think that percent precision is enough, but all right, shall we settle for permille? ppm?

I changed my mind again, and I'm back to a simple number between 0 and 100. Anybody who needs more precision is (a) wrong; or (b) should write their own RNG code.

@dot-asm a percentage doesn't break each bit into 100 parts, it breaks the totality into 100 parts. With a source that pushes 1kb of data in results in a granularity of 10 bytes. This will happen to a greater or lesser extent for any proportional estimate. The scale factor will need to be large to compensate. An absolute estimate doesn't suffer from this issue.

I'm not fussed about the specific scale value, 100 is as good as 256 and if it enhances comprehension, all the better. Making the scale too large or too small could be problematic but neither seems to be a risk at the moment.

Since this is going to be a public interface, let make sure we get it as right as we can.

a percentage doesn't break each bit into 100 parts

And that's why there was smiley and next sentence started with "on serious note".

It just depends on the API specification ... it could just as well be an integer value representing the number of bits of randomness, measured in hundredths of a bit.

Hundredths of a bit. You left off the smiley.

I'm not sure this needs the 'ready' label if Andy is not moving it out of WIP yet.

So @dot-asm are you going to move on this for 1.1.1? Or wait until later?

Ping?

This is a ping @dot-asm specifically, right?

Yes. Quite frankly, I like the idea in the original description better:

#ifndef __NDK_FPABI__
# define __NDK_FPABI__
#endif

__NDK_FPABI__ void RAND_add(const void *buf, int num, double randomness);

This is against the 1.1.1 milestone - is that still correct? What is the status of this @dot-asm?

What is the status of this?

In my view patch as it stand here is 110% appropriate, because it denotes the specific and special relation of the function and modifier. Now, there is remaining question about what to do about RAND_poll_cb. Suggestion was to get rid of double, but we couldn't agree on what would be appropriate granularity. One can also choose to give same treatment to RAND_poll_cb as to RAND_add, i.e. declare it as __NDK_FPABI__. Why is it interesting to do so? Because without modified declaration it would be tricky for application and library to interoperate if there are compiled separately. Multiple people would have to get small details right. HOWEVER! Now when I look at it I don't see that RAND_poll_cb is used anywhere. So it looks like it can be removed. And if it can, then it definitely should...

Re-based and removed the intermediate typedef, and WIP...

Should RAND_poll_cb also get removed from util/private.num?

Yes, thanks! Update pushed, please re-review...