Home
last modified time | relevance | path

Searched hist:"95639 a80efb8d691feabe83428703dea89b873a4" (Results 1 – 9 of 9) sorted by relevance

/freebsd/usr.bin/dc/tests/
H A DMakefile95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
H A Dinout.sh95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
/freebsd/usr.bin/dc/
H A Dextern.hdiff 95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
H A Dmem.cdiff 95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
H A Dbcode.hdiff 95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
H A DMakefilediff 95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
H A Dinout.cdiff 95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
H A Dbcode.cdiff 95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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
/freebsd/etc/mtree/
H A DBSD.tests.distdiff 95639a80efb8d691feabe83428703dea89b873a4 Tue Dec 05 05:22:35 CET 2017 Alan Somers <asomers@FreeBSD.org> 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