LGTM

DEFAULT seems wrong to me as a language thing. Normally I would just 
write 0, but if it's the standard for hare then it's fine.

My apologies.

Signed-off-by: Joe Finney <me@spxtr.net>
---
Feel free to disregard this patch if it's not worth the bother.

 cmd/harec/context.ha            | 2 +-
 cmd/harec/qbe.ha                | 2 +-
 crypto/aes/cbc+test.ha          | 2 +-
 crypto/aes/ct64+test.ha         | 2 +-
 crypto/aes/rt+test.ha           | 2 +-
 crypto/aes/xts/xts.ha           | 2 +-
 crypto/bcrypt/+test.ha          | 2 +-
 crypto/bcrypt/bcrypt.ha         | 2 +-
[message trimmed]

LGTM. I just sent another patch that tests the result of this, and it 
all passes.

Signed-off-by: Joe Finney <me@spxtr.net>
---
This will only pass after ecs' patch goes in. I wasn't sure how to
make it send in reply to that message.

 strconv/+test/ftos_test.ha | 43 +++++++++++++++++++++++++-------------
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/strconv/+test/ftos_test.ha b/strconv/+test/ftos_test.ha
index 2adb55c6..5aa668ac 100644
--- a/strconv/+test/ftos_test.ha
+++ b/strconv/+test/ftos_test.ha
@@ -1,7 +1,9 @@
 // SPDX-License-Identifier: MPL-2.0
[message trimmed]

Signed-off-by: Joe Finney <me@spxtr.net>
---
 strconv/ftos.ha | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/strconv/ftos.ha b/strconv/ftos.ha
index accb470c..c4f5b90b 100644
--- a/strconv/ftos.ha
+++ b/strconv/ftos.ha
@@ -10,6 +10,7 @@ use memio;
 use strings;
 use types;
 
+// Format styles for the [[ftosf]] functions.
[message trimmed]

For void precision, uses Ryu algorithm. For uint precision, uses a
multiprecision implementation heavily based on golang's strconv.

The rounding and encoding functions are highly nontrivial, largely
because I decided to add a SHOW_POINT flag.

Signed-off-by: Joe Finney <me@spxtr.net>
---
v6: and also fix lint. this should be added to make check imo.
 makefiles/freebsd.aarch64.mk   |   4 +-
 makefiles/freebsd.riscv64.mk   |   4 +-
 makefiles/freebsd.x86_64.mk    |   4 +-
 makefiles/linux.aarch64.mk     |   4 +-
 makefiles/linux.riscv64.mk     |   4 +-
[message trimmed]

For void precision, uses Ryu algorithm. For uint precision, uses a
multiprecision implementation heavily based on golang's strconv.

The rounding and encoding functions are highly nontrivial, largely
because I decided to add a SHOW_POINT flag.

Signed-off-by: Joe Finney <me@spxtr.net>
---
v5: addressed Ember's comments. fftosf does make sense despite the
abundance of fs.

 makefiles/freebsd.aarch64.mk   |   4 +-
 makefiles/freebsd.riscv64.mk   |   4 +-
 makefiles/freebsd.x86_64.mk    |   4 +-
[message trimmed]

For void precision, uses Ryu algorithm. For uint precision, uses a
multiprecision implementation heavily based on golang's strconv.

The rounding and encoding functions are highly nontrivial, largely
because I decided to add a SHOW_POINT flag.

Signed-off-by: Joe Finney <me@spxtr.net>
---
This is roughly the same as v3, except I changed the interface to
one single ftosf and ftosfh function, rather than one for each type.
IMO this is better.

 stdlib.mk                      |   7 +-
 strconv/+test/ftos_test.ha     | 230 ++++++++
[message trimmed]

In main, you have

for(let i = 1; i < 10; i += 1) {
     let newlink: link = link{val:int = i, pnext = null};
     ins_link(cur, &newlink);
};

newlink is stored on the stack. from one loop iteration to the next the 
memory may be reused. it's the same issue as if you try to return a 
pointer to a local variable in a function. you need to alloc(link {...}) 
to get a pointer to a heap-allocated struct.

     let newlink: *link = alloc(link{val:int = i, pnext = null});
     ins_link(cur, newlink);

For void precision, uses Ryu algorithm. For uint precision, uses a
multiprecision implementation heavily based on golang's strconv.

The rounding and encoding functions are highly nontrivial, largely
because I decided to add a SHOW_POINT flag.

Signed-off-by: Joe Finney <me@spxtr.net>
---
1. Is this interface okay? I don't like that every function is
duplicated for f64 and f32, only to be recombined in the generic
function. It doesn't seem necessary. Why not just one ftosf (and
ftos) that takes a (f32 | f64), like floatingtos?
2. The code is significantly more complicated than I would prefer. I
think this is largely because of SHOW_POINT and G. I'll look for ways
[message trimmed]