go requires runes to be 21 bit now, and 9front uses ushort for Rune and 0xFFFF for Runemax.

below is my diff that allowed go to build after recompiling the libraries and compiler (8c).

what programs, if any, might be affected by this change?

chi% hg diff /sys/include/libc.h /386/include/u.h diff -r be94add9755a 386/include/u.h --- a/386/include/u.h Mon Jun 10 01:13:56 2013 +0200 +++ b/386/include/u.h Wed Jun 12 09:24:08 2013 +0000 @@ -8,7 +8,7 @@ typedef unsigned long long uvlong; typedef unsigned long uintptr; typedef unsigned long usize; -typedef ushort Rune; +typedef uint Rune; typedef union FPdbleword FPdbleword; typedef long jmp_buf[2]; #define JMPBUFSP 0 diff -r be94add9755a sys/include/libc.h --- a/sys/include/libc.h Mon Jun 10 01:13:56 2013 +0200 +++ b/sys/include/libc.h Wed Jun 12 09:24:08 2013 +0000 @@ -41,12 +41,12 @@

enum { - UTFmax = 3, /* maximum bytes per rune / + UTFmax = 4, / maximum bytes per rune / Runesync = 0x80, / cannot represent part of a UTF sequence (<) / Runeself = 0x80, / rune and UTF sequences are the same (<) / Runeerror = 0xFFFD, / decoding error in UTF / - Runemax = 0xFFFF, / 16 bit rune / - Runemask = 0xFFFF, / bits used by runes (see grep) / + Runemax = 0x10FFFF, / 16 bit rune / + Runemask = 0x1FFFF, / bits used by runes (see grep) */ };

/*

/386/include/u.h is not the right place. also, wont switch to 32bit runes just yet.

This should definitely be fixed, but I agree with Cinap that it shouldn't be fixed in u.h.

reopening issue, so we have a place to report 32 bit rune issues that need to be resolved for doing the switch.

the diff above contains a bug:

this:

• Runemask = 0x1FFFF, /* bits used by runes (see grep)

should'v been:

• Runemask = 0x1FFFFF, /* bits used by runes (see grep)

http://okturing.com/src/1837/body

is my current patch for 9front 21-bit runes. i have been running this for a little over a week now, and am using go tip with the following patch. http://okturing.com/src/1838/body

only bug in the system found so far was that sam stack sizes were too small, so some rune arrays were blowing up the stack. that fix was comitted in https://code.google.com/p/plan9front/source/detail?r=14b8e3b4fa98c81239583756c230f22044e68a0c

forgot /sys/include/ape/u.h before.

latest 21-bit rune patch for 9front: http://okturing.com/src/1840/body

applied in r66e10a2cb1cf, needs testing.

seems to work fine so far, closing the issue

Comment deleted