Add option to have more control over the precision with which reals are placed in JSON with dump calls

[wqboth]

Is this an acceptable approach for solving/getting control over the way floats/reals are formatted?
We would really appreciate if this patch could be admitted to the master.

[akheron]

I'm leaning to not including this support. Controlling the precision of real numbers was originally introduced to work around the non-optimality of encoding (which will be fixed by #680), and I would rather remove the whole support than to extend it any further.

Also, it should be possible to control the precision to some extent by your own code. You could do something like round(v * 1000.0) / 1000.0 to get a value down to 3 decimals.

[wqboth]

This would greatly dissapoint me.
You are right that one could work around the problem if you can convince the party receiving the data to implement some kind of locale rounding. Mostly this is not possible. Certainly not with the parties with which we communicate.
And the rounding you suggest wouldn't solve the problem. One would still end up with an unpresentable float in binary.
In the end a function like printf() would be implemented or the party receiving the data works e.g. with cents if the float represents a monetary value.
And you haven't convinced me that rounding with one general setting is acceptable and rounding on a per field basis is not.

[wqboth]

I looked again at your suggestion of implementing dtoa()

I can see,now what you mean that this could solve the problem.
But what was not clear to me: are you going to replace the printf() in jansson for printing floats with the function dtoa()?
And with what precision is that done? I got the impression dtoa() will be using the general precision already present in jansson.

This might then almost completely solve the issues i encounter.
The only thing is i don't have control over the precision on a per fielld basis