freebsd/usr.bin/dc/tests/Makefile


PACKAGE=	tests

ATF_TESTS_SH=	inout
ATF_TESTS_SH+=	bcode

.include <bsd.test.mk>
dc(1): fix input of non-decimal fractional numbers Inputting fractional non-decimal numbers has never worked correctly in our OpenBSD-derived dc(1). It truncates the input to a number of decimal places equal to the number of hexadecimal (or whatever base) places given on the input. That's unacceptable, because many numbers require more precision to represent in base 10 than in their original bases. Fix this bug by using as many decimal places as needed to represent the input, up to the maximum of the global scale factor. This has one mildly surprising side effect: the scale of a number entered in non-decimal mode will no longer necessarily equal the number of hexadecimal (or whatever base) places given on the input. I think that's an acceptable behavior change, given that inputting fractional non-decimal numbers never worked in the first place, and the man page doesn't specify whether trailing zeros on the input should affect a number's scale. PR: 206230 Reported by: nibbana@gmx.us Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D13336 2017-12-05 04:22:35 +00:00
			`PACKAGE= tests`

			`ATF_TESTS_SH= inout`
dc(1): fix modulo operations with fractional inputs Our dc(1) has never correctly calculated remainders with fractional inputs. Both bmod and bdivmod seem to have copy/pasted code from bdiv, which results in the remainder having the wrong output scale. PR: 162495 Reported by: anonymous Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D13390 2017-12-07 02:08:55 +00:00			`ATF_TESTS_SH+= bcode`
dc(1): fix input of non-decimal fractional numbers Inputting fractional non-decimal numbers has never worked correctly in our OpenBSD-derived dc(1). It truncates the input to a number of decimal places equal to the number of hexadecimal (or whatever base) places given on the input. That's unacceptable, because many numbers require more precision to represent in base 10 than in their original bases. Fix this bug by using as many decimal places as needed to represent the input, up to the maximum of the global scale factor. This has one mildly surprising side effect: the scale of a number entered in non-decimal mode will no longer necessarily equal the number of hexadecimal (or whatever base) places given on the input. I think that's an acceptable behavior change, given that inputting fractional non-decimal numbers never worked in the first place, and the man page doesn't specify whether trailing zeros on the input should affect a number's scale. PR: 206230 Reported by: nibbana@gmx.us Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D13336 2017-12-05 04:22:35 +00:00
			`.include <bsd.test.mk>`