This was reported in clamav via a "coverity report" #11125/#11126. I can't
get the coverity report and I've been told that
|< linnatic> bigeasy: unfortunately, I can't get you the coverity report
|< linnatic> bigeasy: but it does seem that the patch is not
|required as the possible coverity issue is unlikely to occur
so if you thing that this patch is not required (which is what I assume) then
please drop that patch, I just added since it was in the clamav tree…
[sebastian@breakpoint: patch description]
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
If maxlen is too small then we get FP_OKAY as return value but not
everything is part of the string. This patch changes it so that the
caller learns about this short comming.
While at it, drop the doxygen style comment. It is the only of his kind
and does no longer match the code.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Previous patch modified constraints from =m to =g. Turns out this also
allows registers which doesn't work with the inline assembly
instructions.
If we change back to =m GCC 5.0 warns that constraints do not allow a
register.
In order to work around these issues we now pass the arguments in
registers and let GCC handle the loading & storing.
It is not implemened yet, just added to the headerfile. Therefore I don't
think it is a ABI breakage if I change maxlen from int to unsigned int.
The function releases fp_toradix() for the work which in turn now calls
fp_toradix_n() with a largest possible maxlen parameter.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
shared makefile now uses libtool
update gitignore according
remove 'timing' target in shared makefile
add dependency of HEADERS to OBJECTS for both makefiles
When we ask to generate a prime whose size is a multiple of 8,
the code wrongly computes the mask as 0x00 instead of 0xFF, so the
generated prime always has the MSB set to 0x80 (the highest bit is OR'ed
later in the code).
