beware of DC version differences

yeti

rvp The problem with hex is that you can read it without DC. That's why I prefer base 15... mean... isn't it?

I've even a more meaner path that could spice up base 15 to look like base 16. But my proof of concept notes about that and the example are about making decimal look like hex: https://yeti.tilde.institute/brain/just-for-fun.html#noisy-decimal

The advantage of making base 10 look hex is that it works without switching the base at all.

dc -e 47FBFE71026C816CDD99EDC9237F65023488025022006E79F92017CBA906P

rvp

yeti The problem with hex is that you can read it without DC

You can. I have to reach for ascii(7).

yeti The advantage of making base 10 look hex is that it works without switching the base at all.

That's very clever, but, also very implementation-dependent. Eg, on FreeBSD's dc which is not the GNU one:

$ dc -e 47FBFE71026C816CDD99EDC9237F65023488025022006E79F92017CBA906P
<binary-junk>
$

which is why I chose straight base-16 (its portable).

JuvenalUrbino

Yeti, or as I like to think about him, the one true nerd.

yeti

JuvenalUrbino I just want to play... nothing else.

yeti

It is not a GNU vs BSD thing.

NetBSD:

~$ which dc
/usr/bin/dc
~$ dc -e 47FBFE71026C816CDD99EDC9237F65023488025022006E79F92017CBA906P
Mwhuaaahahahahahhaaaa...

OpenBSD:

~$ which dc
/usr/bin/dc
~$ dc -e 47FBFE71026C816CDD99EDC9237F65023488025022006E79F92017CBA906P
Mwhuaaahahahahahhaaaa...

I see it fail on FreeBSD and on 9front too.
All these are not using GNU DC.

FreeBSD:

~$ echo A p | dc
10
~$ echo A0 p | dc
90
~$ echo AA p | dc
99

No Idea what I shall think about that.
That's the one of the 3 major BSDs I come in touch with the least often. I'd be stumbled over this already if I'd use it more. :-/

9front:

echo Ap | dc
10
echo A0p | dc
100
echo AAp | dc
110

That looks plausible.
9front's problem is P:

cpu% echo 16i 41 PAP | dc
A
cpu% echo 16i 4142 PAP | dc
C
cpu% echo 16i 414243 PAP | dc
D

That all needs more ॐmmmmmm...

rvp

yeti This works on both FreeBSD (non-GNU) and NetBSD (GNU dc), at least: represent the entire string as a number, then pick the digits out:

$ dc -e 23974667923806900305172439306P
Mwahahahaa!
$ cat str2dig.sh
cat $1				|
od -An -tx1 -v			|
tr -d '[:blank:]\n'		|
tr '[:lower:]' '[:upper:]'	|
(echo ibase=16; cat)		|
bc -L
$ echo 'Mwahahahaa!' | ./str2dig.sh
23974667923806900305172439306
$

Obscure enough?

yeti

yeti The 9front DC drama continues...

<update>
(2022-07-03 Sun 20:40): Update…

I really have a problem to find the pattern of the feature in this:

cpu% echo 97 PAP | dc
a
cpu% echo 98 PAP | dc
b
cpu% echo 99 PAP | dc
c
cpu% echo 100 PAP | dc
<linefeed only>

And if it were a feature, I would expect it being documented somewhere.
</update>

With that boiled down example I at least could convince one(!) other 9front user now to accept this behavior as bug. Maybe it's time to dare asking about this in the lion's den now.

Ok, I might smell a pattern there, but haven't looked deep enough into the 9ish dc source. The oldest DC I looked at as source stores the bignums in a list of base 100 "digits" and P glitching at d (ASCII 100) might be a hint. Their version still may be in that oldtimer's family tree and just prints the base 100 chunks as chars?

cpu% echo 979899 PAP | dc
cba

This at least doesn't spit out garbage, but triggers other questions...

yeti

rvp

$ python2 -c 'print reduce(lambda x,y:x*256+y,map(ord,"`reduce` now hides in a lib.\n"))'
2600202191717411811743525770105493671405003432197090434073084213472778

yeti

rvp FreeBSD's DC seems to treat A-F right only for bases above 10. There is even a hint about that in man 1 dc.

Until I get a very good explanation for this I'll consider it as wrong by design.

yeti

yeti https://github.com/aflat/heirloom-toolchest/blob/master/dc/dc.c looks like a very close relative of 9front's DC, and unsurprisingly shows the the same problem(s).

They calculate arbitrary precision numbers as string of base 100 "digits" (e.g. see 'add()') and when printing the memory representation of such a number as string, it's obvious why this flavour of DC cannot print ASCII 100 ('d') and upwards and why it does the printing in reverse order.

This might have been good enough in KSR33 days with only uppercase characters.

Maybe in those time it even was known and accepted that '656667' would print as 'CBA'?

Maybe most users did not care as in most cases the single digit to letter conversion was all they wanted? E.g. the prime numbers example in the man page only uses '48+' to turn a digit into it's ASCII value. That never exceeds 99.

Conclusion: This DC never has printed strings like today's DCs and bending it to today's expected behaviour will turn printing big numbers as strings into a very expensive operation of lots of bigint divmod operations.

Case closed?

The status quo just should be reflected in the man page.

Case closed.

yeti

No feedback so far from the 9crowd. :-(

I played a bit with ancient *nixens and the oldest DC that behaves similar to 9front's DC I found so far is the one on 'PDP11 UNIX v6'.

# dc
97P AP
a
98P AP
b
99P AP
c
100P AP

979899P AP
cba

Come on, 9front, you really want to confuse your users by keeping a DC from ±1975?

Edit: Maybe my KSR33 association wasn't even that far off... ;-)

pstef

From what I can see in my copy of the FreeBSD stable/13 branch, you can toggle WITHOUT_GH_BC between "the traditional FreeBSD bc(1)" and "the enhanced version".
man /usr/src/usr.bin/bc/bc.1 shows:

HISTORY
The bc command first appeared in Version 6 AT&T UNIX. A complete rewrite of the bc command first appeared in OpenBSD 3.5.
AUTHORS
The original version of the bc command was written by Robert Morris and Lorinda Cherry. The current version of the bc utility was written by Otto Moerbeek.

and this is the "traditional FreeBSD bc". As per /usr/src/contrib/bc/manuals/bc/N.1 the newer one is:

AUTHORS
Gavin D. Howard <gavin yzena.com> and contributors.

The "traditional" bc seems to have been imported to FreeBSD from OpenBSD in 2010, replacing GNU bc.

yeti

pstef I know where FreeBSD's DC comes from and having looked into the source, I think FreeBSD's DC can easily be modified to behave like OpenBSD DC, GNU DC and the oldest ones. I think it is not a good move to deviate from established behaviour without a reason. Or is there a reason?

gavinhoward

yeti I'm the author of FreeBSD's new dc.

I agree with you that deviations from established behavior are not good and should not be done without a reason. I created an account to tell you the reason.

The reason is that GNU bc treated numbers that way, and I did not check the behavior of GNU dc, which has the behavior you want (it prints "Mwhuaaahahahahahhaaaa..." on my machine at least).

This is a bad reason and an oversight on my part, so this is a bug in my dc. Full stop. This will be fixed in the next release, which I am going to work on getting out soon because of this bug.

I think you can expect the FreeBSD port to be updated within 2 weeks.

gavinhoward

yeti I want to say, though, that the behavior of the GNU and OpenBSD dc is not the best once ibase has been explicitly set.

For example:

3i
Ap

That prints 10, which is correct because single-digit numbers have to be treated specially, for setting ibase and obase. However:

3i
AAp

That prints 40. This means that the GNU dc and OpenBSD dc are treating every single digit but the last one as being in base 3, but the last one is always put into base 16. I can't imagine what caused them to do this.

The GNU bc does not have that behavior; why the GNU dc is different is anyone's guess.

Regardless, my dc will have that behavior, but it will be documented properly, so that people who use it can know of that footgun.

yeti

gavinhoward Wow!

I'm kind of speechless...

Thanks a lot!

gavinhoward

yeti Oh, and you're welcome. My pleasure.

yeti

A₃ = 3⁰ · 10 = 10
A0₃ = 3¹ · 10 = 30
A00₃ = 3² · 10 = 90

AT&T-ish DC (e.g. on 9front):

cpu% echo 3i Ap | dc
10
cpu% echo 3i A0p | dc
30
cpu% echo 3i A00p | dc
90

GNU DC:

$ echo 3i Ap | dc
10
$ echo 3i A0p | dc
30
$ echo 3i A00p | dc
90

OpenBSD DC:

$ echo 3i Ap | dc
10
$ echo 3i A0p | dc
30
$ echo 3i A00p | dc
90

I don't see the the As being treated different depending on the position. For me it always looks like ibase^position * digit.

gavinhoward

After checking, I stand corrected. That does seem to be what it is doing.

Well, that makes it easier to implement. In fact, it will make it easier for me to provide a way for people to get the current behavior back, if they wish.

Thank you for your help. I'll get this out as soon as I can.

yeti

gavinhoward Well, that makes it easier to implement. In fact, it will make it easier for me to provide a way for people to get the current behavior back, if they wish.

Nice idea!