Re: fdinsert(), take 2
On Mon, May 28, 2018 at 01:10:29PM +0200, Martin Pieuchot wrote:
> This diff has been tested as part of the big "unlocking" diff I sent
> last week, so I'm confident, but reviews & tests are more than welcome!
>
> Ok?
Passes all regress tests.
OK bluhm@
> Index: kern/kern_exec.c
> ===
> RCS file: /cvs/src/sys/kern/kern_exec.c,v
> retrieving revision 1.195
> diff -u -p -r1.195 kern_exec.c
> --- kern/kern_exec.c 28 Apr 2018 03:13:04 - 1.195
> +++ kern/kern_exec.c 28 May 2018 09:41:15 -
> @@ -584,7 +584,7 @@ sys_execve(struct proc *p, void *v, regi
> struct vnode *vp;
> int indx;
>
> - if ((error = falloc(p, 0, , )) != 0)
> + if ((error = falloc(p, , )) != 0)
> break;
> #ifdef DIAGNOSTIC
> if (indx != i)
> @@ -607,10 +607,9 @@ sys_execve(struct proc *p, void *v, regi
> fp->f_type = DTYPE_VNODE;
> fp->f_ops =
> fp->f_data = (caddr_t)vp;
> - FILE_SET_MATURE(fp, p);
> - } else {
> - FRELE(fp, p);
> + fdinsert(p->p_fd, indx, 0, fp);
> }
> + FRELE(fp, p);
> }
> fdpunlock(p->p_fd);
> if (error)
> Index: kern/exec_script.c
> ===
> RCS file: /cvs/src/sys/kern/exec_script.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 exec_script.c
> --- kern/exec_script.c2 May 2018 02:24:56 - 1.44
> +++ kern/exec_script.c28 May 2018 09:41:15 -
> @@ -170,17 +170,20 @@ check_shell:
> #endif
>
> fdplock(p->p_fd);
> - error = falloc(p, 0, , >ep_fd);
> - fdpunlock(p->p_fd);
> - if (error)
> + error = falloc(p, , >ep_fd);
> + if (error) {
> + fdpunlock(p->p_fd);
> goto fail;
> + }
>
> epp->ep_flags |= EXEC_HASFD;
> fp->f_type = DTYPE_VNODE;
> fp->f_ops =
> fp->f_data = (caddr_t) scriptvp;
> fp->f_flag = FREAD;
> - FILE_SET_MATURE(fp, p);
> + fdinsert(p->p_fd, epp->ep_fd, 0, fp);
> + fdpunlock(p->p_fd);
> + FRELE(fp, p);
> }
>
> /* set up the parameters for the recursive check_exec() call */
> Index: kern/kern_descrip.c
> ===
> RCS file: /cvs/src/sys/kern/kern_descrip.c,v
> retrieving revision 1.159
> diff -u -p -r1.159 kern_descrip.c
> --- kern/kern_descrip.c 28 May 2018 08:55:11 - 1.159
> +++ kern/kern_descrip.c 28 May 2018 09:41:16 -
> @@ -144,6 +144,17 @@ find_last_set(struct filedesc *fd, int l
> return i;
> }
>
> +static __inline int
> +fd_inuse(struct filedesc *fdp, int fd)
> +{
> + u_int off = fd >> NDENTRYSHIFT;
> +
> + if (fdp->fd_lomap[off] & (1 << (fd & NDENTRYMASK)))
> + return 1;
> +
> + return 0;
> +}
> +
> static __inline void
> fd_used(struct filedesc *fdp, int fd)
> {
> @@ -190,7 +201,7 @@ fd_iterfile(struct file *fp, struct proc
> nfp = LIST_NEXT(fp, f_list);
>
> /* don't FREF when f_count == 0 to avoid race in fdrop() */
> - while (nfp != NULL && (nfp->f_count == 0 || !FILE_IS_USABLE(nfp)))
> + while (nfp != NULL && nfp->f_count == 0)
> nfp = LIST_NEXT(nfp, f_list);
> if (nfp != NULL)
> FREF(nfp);
> @@ -209,9 +220,6 @@ fd_getfile(struct filedesc *fdp, int fd)
> if ((u_int)fd >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL)
> return (NULL);
>
> - if (!FILE_IS_USABLE(fp))
> - return (NULL);
> -
> FREF(fp);
> return (fp);
> }
> @@ -634,19 +642,17 @@ finishdup(struct proc *p, struct file *f
> return (EDEADLK);
> }
>
> - oldfp = fdp->fd_ofiles[new];
> - if (oldfp != NULL) {
> - if (!FILE_IS_USABLE(oldfp)) {
> - FRELE(fp, p);
> - return (EBUSY);
> - }
> - FREF(oldfp);
> - }
> + oldfp = fd_getfile(fdp, new);
> + if (dup2 && oldfp == NULL) {
> + if (fd_inuse(fdp, new)) {
> + FRELE(fp, p);
> + return (EBUSY);
> + }
> + fd_used(fdp, new);
> + }
>
> fdp->fd_ofiles[new] = fp;
> fdp->fd_ofileflags[new] = fdp->fd_ofileflags[old] & ~UF_EXCLOSE;
> - if (dup2 && oldfp == NULL)
> - fd_used(fdp, new);
> *retval = new;
>
> if (oldfp != NULL) {
> @@ -659,6 +665,23
Re: Libressl question
> libtls is tied to libressl as a matter of convenience and happenstance, > but it doesn't need to be that way. If I recall, libtls requires the ability to pass certs as memory rather than directly loading it from a file. And OpenSSL native lacks any way of doing this, and their team rejected the API which loads the file into memory, for handling later. Which is pretty foundational for use in privsep programs which should not have a view on /etc.
Re: Libressl question
Brent Cook wrote: > On Mon, Feb 12, 2018 at 09:27:16AM -0600, ed...@pettijohn-web.com wrote: > > Has there been any discussion of packaging libtls separately from libressl > > for portable use? With my limited skills I was able to write a program to > > talk to smtpd and starttls using nothing but the manuals. I seriously doubt > > I could have done so with the gnu tls library. This really shows how well > > it is written as far as the code involved, but also the quality of the > > manuals. I only had one hickup and if I can think of a way to word it > > better I'll send a patch for that manual. I missed this question. My answer is about the same as Brent's regarding what needs to be done. I do think it's worthwhile (somebody should totally do this for values of somebody that may not be me :)). I'll add that I think the API we developed was an important contribution and I'd like to see more people use it. libtls is tied to libressl as a matter of convenience and happenstance, but it doesn't need to be that way. The API should (i hope so) be independent of implementation. One of the goals was to help solve the monoculture problem by allowing differing implementations to be more easily swapped. There have been a few experiments over time to prove the viability of this approach, but nothing supported. And the API was in flux for a long time, but I think it's settled down now. We still add new stuff (sessions), but one could start with a core. To sum up, go forth and good luck. :) > I had a working version a couple of years ago against OpenSSL. There > were a few challenges even with a closely-related library: > > 1. libtls can and does reply on LibreSSL-specific features in the >core library, e.g. for privilege separation. These would either >need to be ported into OpenSSL or a compatibility interface >provided in addition to the libtls interface. > > 2. Which version of the OpenSSL API / ABI to support? Now that >OpenSSL is incompatible between 1.1 and 1.0, even more >workarounds may be needed. > > 3. The libtls API is usually defined in terms of the LibreSSL >version it ships with, and changed somewhat quickly. >Would libtls-standalone be shipped as part of the target library? >How would we sync API / ABI changes between them. > > You could probably port libtls to have a gnutls backend, though you may > have to implement more lower-level changes in gnutls as well to support > some of the features. The longer-term support, release, and > fragmentation issues also remain. >
Re: [Patch] mg(1): Experimental UTF-8 support
On 2018-05-30T09:17:22-0600, Theo de Raadt wrote: > This approach seems misguided. Let me tell a story. > > More than two decades ago, I made a fork of mg which was 100% byte > clean. Unfortunately I lost the source code of that change. mg's data > buffers are a linked list of lines, with a \n implied by the end of each > string. 0 bytes are unsupported. Supporting multibyte risks a string > merger getting confused by these problems and creating junk. My fork > changed mg to embed \n and \0 in the strings, and have the display code > understand that. All buffer-search functionalities also learned of this > change. The change had to be made quite incrementally and carefully, > but I recall the end result deleted far more code than it added. mg became > 100% 8-bit clean, I could edit binaries with it. > > I think trying to shoehorn utf8 in before mg is 8-bit clean is a recipe > for disaster. There are too many functions (imagine search-replace) > which already have nasty special cases for \n, and now will need nasty > special cases for utf8 and I don't think this will work out nice. Fair enough. I am decidely not up for reworking all of mg. It seems better that this patch, as it is, remain off to the side in case someone wants to use it themselves. -- S. Gilles
Re: [Patch] mg(1): Experimental UTF-8 support
On 2018-05-30T11:50:37+0200, Stefan Sperling wrote:
> Comments inline. I think this still needs a lot of work...
Thanks for the review; replies inline (and omitted where the reply
is the same as one above). By the time you read this, I'll have
pushed the changes I mention to my branch in hboetes' repo.
> I've done one pass over this to weed out some obvious problems.
> There might be many I've missed.
>
> Not going to do any run-time testing because emacs/mg break my fingers ;)
Understood :). A couple of your suggestions are actually already
handled by mg's behavior, though.
> On Mon, May 28, 2018 at 09:32:10PM +0300, Leonid Bobrov wrote:
> > Index: basic.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/basic.c,v
> > retrieving revision 1.47
> > diff -u -p -u -p -r1.47 basic.c
> > --- basic.c 10 Oct 2015 09:13:14 - 1.47
> > +++ basic.c 28 May 2018 18:08:10 -
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "def.h"
> >
> > @@ -269,12 +270,25 @@ setgoal(void)
> > int
> > getgoal(struct line *dlp)
> > {
> > - int c, i, col = 0;
> > - char tmp[5];
> > + return getbyteofcol(dlp, 0, curgoal);
> > +}
> >
> > +/*
> > + * Return the byte offset within lp that is targetcol columns beyond
> > + * startbyte
> > + */
> > +size_t
> > +getbyteofcol(const struct line *lp, const size_t startbyte,
> > + const size_t targetcol)
> > +{
> > + int c;
> > + size_t i, col = 0;
> > + char tmp[5];
> > + size_t advance_by = 1;
> >
> > - for (i = 0; i < llength(dlp); i++) {
> > - c = lgetc(dlp, i);
> > + for (i = startbyte; i < llength(lp); i += advance_by) {
> > + advance_by = 1;
> > + c = lgetc(lp, i);
> > if (c == '\t'
> > #ifdef NOTAB
> > && !(curbp->b_flag & BFNOTAB)
> > @@ -284,16 +298,84 @@ getgoal(struct line *dlp)
> > col++;
> > } else if (ISCTRL(c) != FALSE) {
> > col += 2;
> > - } else if (isprint(c))
> > + } else if (isprint(c)) {
> > col++;
> > - else {
> > + } else if (!(curbp->b_flag & BFSHOWRAW)) {
> > + mbstate_t mbs = { 0 };
> > + wchar_t wc = 0;
> > + size_t consumed = mbrtowc(, >l_text[i],
> > + llength(lp) - i, );
> > + int width = -1;
> > + if (consumed < (size_t) -2) {
>
> I think this should say: consumed > 0
If size_t is unsigned, using "consumed > 0" would be a rather large
semantic difference, but I believe I understand your meaning: compare
explicitly with -1 and -2, then handle normal path in else.
> Since both (size_t)-1 and (size_t)-2 indicate special error conditions
> they should only be compared the with == operator, in my opinion.
>
> Please read the mbrtowc man page if you haven't already.
> It covers error conditions extensively.
I have, many times. mg makes no distinction (that I know of) between
an incomplete sequence and a decoding error. Either error should
cause mg to throw up its hands and display an octal sequence for
the offending byte.
That said, I see your point about comparing errors only with ==. I
don't personally agree with it, but neither do I disagree. In the
interest of line length, I'll wrap "not equal to -2 or -1" into a
MBRTOWC_SUCCESSFUL macro, and use that in place of < -2.
> A good idiom would be something like:
>
> size_t ret = mbrtowc(...)
> if (ret == (size_t)-1) {
> /* handle decoding error */
> } else if (ret == (size_t)-2) {
> /* handle incomplete sequence */
> } else if (ret == 0) {
> /* handle end of line */
As I read the manual, ret = 0 corresponds to returning L'\0'. The
"end of line" condition is actually handled above, with the llength(lp)
comparision. For the L'\0' case, mg currently deals with NUL bytes
via the control check (also above), so consumed should never be 0.
That said, it's pretty trivial to add another layer ensuring
advance_by is never 0, so I'll add that.
> } else {
> /* handle character which was parsed */
> }
That idiom handles four separate cases. Of those, mg sees no
distinction between the -1 and -2 case, and the special handling
for the L'\0' case makes more sense elsewhere (where advance_by is
set), folded into the else case.
> > + width = wcwidth(wc);
> > + }
> > + if (width >= 0) {
>
> You should explicitly deal with width == -1 here as well.
> A negative width means this line contains a non-printable character.
> But that doesn't mean this character won't have any effect when printed.
> You might want to narrow down the truth about such a character
> with iswcntrl() and friends and take some
Re: bgpd ignore aspath with to large attributes
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.05.30 15:18:45 +0200:
> Hi,
>
> This adds a protection to handle aspaths overly large attributes in bgpd.
> The main idea is to protect other bgp routes downstream for hitting the
> limit with is often not well catched.
> The limit is currently a bit arbitarily set to 4096 - 1024 which is afaik
> the same limit that bird uses.
the rfc says
If, due to the limits on the maximum size of an UPDATE message (see
Section 4), a single route doesn't fit into the message, the BGP speaker
MUST not advertise the route to its peers and MAY choose to log an error
locally.
so this is correct.
> While the default free zone should be fine with this it may be to strict
> from some strange internal use, where a large amount of e.g. communities
> are attached for extra information. I don't want to make this a knob
> fest and making this configurable. So happy for input from BGP users.
i for one dont see a problem with it.
code reads and runs ok too.
> Cheers
> --
> :wq Claudio
>
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.379
> diff -u -p -r1.379 rde.c
> --- rde.c 10 Feb 2018 05:54:31 - 1.379
> +++ rde.c 24 Feb 2018 13:16:09 -
> @@ -997,6 +997,13 @@ rde_update_dispatch(struct imsg *imsg)
> if (attrpath_len != 0) { /* 0 = no NLRI information in this message */
> /* parse path attributes */
> asp = path_get();
> + /* protect from oversized messages */
> + if (attrpath_len > 4096 - 1024) {
> + asp->flags |= F_ATTR_PARSE_ERR;
> + log_peer_warnx(>conf, "update too big (%i), "
> + "path invalidated and prefix withdrawn",
> + attrpath_len);
> + }
> while (len > 0) {
> if ((pos = rde_attr_parse(p, len, peer, asp,
> )) < 0)
>
Enable bwfm(4) on Loongson for USB devices
Hi tech@, Here is a diff to enable bwfm(4) on Loongson for USB devices. Tested on a Lemote Yeeloong 8101B. Comments? OK? Index: sys/arch/loongson/conf/GENERIC === RCS file: /cvs/src/sys/arch/loongson/conf/GENERIC,v retrieving revision 1.57 diff -u -p -r1.57 GENERIC --- sys/arch/loongson/conf/GENERIC 24 Apr 2018 03:17:36 - 1.57 +++ sys/arch/loongson/conf/GENERIC 30 May 2018 15:45:25 - @@ -164,6 +164,7 @@ atu*at uhub?# Atmel AT76c50x based 80 aue* at uhub?# ADMtek AN986 Pegasus Ethernet axe* at uhub?# ASIX Electronics AX88172 USB Ethernet axen* at uhub?# ASIX Electronics AX88179 USB Ethernet +bwfm* at uhub?# Broadcom FullMAC cdce* at uhub?# CDC Ethernet urndis*at uhub?# Remote NDIS Ethernet cue* at uhub?# CATC USB-EL1201A based Ethernet
Re: Remove comcnspeed and comcnmode on armv7
On Wed, May 30, 2018 at 03:27:22PM +0200, Mark Kettenis wrote:
> Remove unused infrastructure. After this we arm64 and armv7 com_fdt.c
> are identical and I can move it into dev/fdt.
>
> ok?
ok, there is also
dev/fdt/imxuart.c:extern int comcnspeed;
dev/fdt/imxuart.c:extern int comcnmode;
>
>
> Index: armv7/armv7_machdep.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/armv7/armv7_machdep.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 armv7_machdep.c
> --- armv7/armv7_machdep.c 15 May 2018 11:11:35 - 1.53
> +++ armv7/armv7_machdep.c 30 May 2018 13:23:36 -
> @@ -207,16 +207,6 @@ void consinit(void);
>
> bs_protos(bs_notimpl);
>
> -#ifndef CONSPEED
> -#define CONSPEED B115200 /* What u-boot */
> -#endif
> -#ifndef CONMODE
> -#define CONMODE ((TTYDEF_CFLAG & ~(CSIZE | CSTOPB | PARENB)) | CS8) /* 8N1 */
> -#endif
> -
> -int comcnspeed = CONSPEED;
> -int comcnmode = CONMODE;
> -
> int stdout_node;
> int stdout_speed;
>
> Index: dev/com_fdt.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/dev/com_fdt.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 com_fdt.c
> --- dev/com_fdt.c 14 May 2018 19:25:54 - 1.13
> +++ dev/com_fdt.c 30 May 2018 13:23:36 -
> @@ -39,9 +39,6 @@ int com_fdt_match(struct device *, void
> void com_fdt_attach(struct device *, struct device *, void *);
> int com_fdt_intr_designware(void *);
>
> -extern int comcnspeed;
> -extern int comcnmode;
> -
> struct cfattach com_fdt_ca = {
> sizeof (struct com_softc), com_fdt_match, com_fdt_attach
> };
> @@ -135,8 +132,7 @@ com_fdt_attach(struct device *parent, st
> SET(sc->sc_hwflags, COM_HW_CONSOLE);
> SET(sc->sc_swflags, COM_SW_SOFTCAR);
> comconsfreq = sc->sc_frequency;
> - comconsrate = stdout_speed ? stdout_speed : comcnspeed;
> - comconscflag = comcnmode;
> + comconsrate = stdout_speed ? stdout_speed : B115200;
> }
>
> if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr,
> Index: dev/pluart.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/dev/pluart.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 pluart.c
> --- dev/pluart.c 19 Feb 2018 08:59:52 - 1.7
> +++ dev/pluart.c 30 May 2018 13:23:36 -
> @@ -182,9 +182,6 @@ struct pluart_softc *pluart_sc(dev_t dev
>
> int pluart_intr(void *);
>
> -extern int comcnspeed;
> -extern int comcnmode;
> -
> /* XXX - we imitate 'com' serial ports and take over their entry points */
> /* XXX: These belong elsewhere */
> cdev_decl(pluart);
> @@ -214,7 +211,7 @@ pluart_init_cons(void)
> if (fdt_get_reg(node, 0, ))
> return;
>
> - pluartcnattach(_bs_tag, reg.addr, comcnspeed, comcnmode);
> + pluartcnattach(_bs_tag, reg.addr, B115200, TTYDEF_CFLAG);
> }
>
> int
> Index: exynos/exuart.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/exynos/exuart.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 exuart.c
> --- exynos/exuart.c 19 Feb 2018 08:59:52 - 1.14
> +++ exynos/exuart.c 30 May 2018 13:23:36 -
> @@ -108,9 +108,6 @@ struct exuart_softc *exuart_sc(dev_t dev
>
> int exuart_intr(void *);
>
> -extern int comcnspeed;
> -extern int comcnmode;
> -
> /* XXX - we imitate 'com' serial ports and take over their entry points */
> /* XXX: These belong elsewhere */
> cdev_decl(exuart);
> @@ -152,7 +149,7 @@ exuart_init_cons(void)
> if (fdt_get_reg(node, 0, ))
> return;
>
> - exuartcnattach(_bs_tag, reg.addr, comcnspeed, comcnmode);
> + exuartcnattach(_bs_tag, reg.addr, B115200, TTYDEF_CFLAG);
> }
>
> int
>
Use IPL_MPFLOOR for 'f_mtx'
Hello,
Now that IPL_MPFLOOR is available on all platforms we can use it. The
first user is the f_mtx mutex in kern_descrip. Rev 1.160 initialized it
using IPL_VM, we can now use the more appropriate IPL_MPFLOOR value as
already done in the MI mutex implementation for the exact same reason.
diff --git kern/kern_descrip.c kern/kern_descrip.c
index 746626bb5f0..591c85a866e 100644
--- kern/kern_descrip.c
+++ kern/kern_descrip.c
@@ -962,7 +962,7 @@ restart:
* We need to block interrupts as long as `f_mtx' is being taken
* with and without the KERNEL_LOCK().
*/
- mtx_init(>f_mtx, IPL_VM);
+ mtx_init(>f_mtx, IPL_MPFLOOR);
fp->f_iflags = FIF_LARVAL;
if ((fq = p->p_fd->fd_ofiles[0]) != NULL) {
LIST_INSERT_AFTER(fq, fp, f_list);
Re: [Patch] mg(1): Experimental UTF-8 support
This approach seems misguided. Let me tell a story. More than two decades ago, I made a fork of mg which was 100% byte clean. Unfortunately I lost the source code of that change. mg's data buffers are a linked list of lines, with a \n implied by the end of each string. 0 bytes are unsupported. Supporting multibyte risks a string merger getting confused by these problems and creating junk. My fork changed mg to embed \n and \0 in the strings, and have the display code understand that. All buffer-search functionalities also learned of this change. The change had to be made quite incrementally and carefully, but I recall the end result deleted far more code than it added. mg became 100% 8-bit clean, I could edit binaries with it. I think trying to shoehorn utf8 in before mg is 8-bit clean is a recipe for disaster. There are too many functions (imagine search-replace) which already have nasty special cases for \n, and now will need nasty special cases for utf8 and I don't think this will work out nice.
Re: Adding IPL_MPFLOOR to sh/armv7
On 30/05/18(Wed) 10:54, Mathieu - wrote: > The following patch adds IPL_MPFLOOR to the two last archs missing it, > namely landisk and armv7. The goal is to be able to use the define in MI > code (note that it's already used but hidden behind a #ifdef > MULTIPROCESSOR). Committed thanks, please continue your work of simplification / unification. Martin
Re: [Patch] mg(1): Experimental UTF-8 support
I'm updating a diff, but it is just a fix for cursor movement,
it is still experimental and obvious problems are not fixed yet,
this is just a diff taken from latest commit at github:
Index: basic.c
===
RCS file: /cvs/src/usr.bin/mg/basic.c,v
retrieving revision 1.47
diff -u -p -u -p -r1.47 basic.c
--- basic.c 10 Oct 2015 09:13:14 - 1.47
+++ basic.c 30 May 2018 13:34:00 -
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "def.h"
@@ -64,6 +65,33 @@ backchar(int f, int n)
curwp->w_dotline--;
} else
curwp->w_doto--;
+
+ /*
+* If we're on a multibyte character, and not in
+* raw mode, we should move all the way through it.
+*/
+ if (!(curbp->b_flag & BFSHOWRAW)) {
+ mbstate_t mbs = { 0 };
+ wchar_t wc = 0;
+ size_t offset = 0;
+ size_t consumed = 0;
+ struct line *clp = curwp->w_dotp;
+ while (offset <= curwp->w_doto) {
+ size_t s = curwp->w_doto - offset;
+ size_t len = llength(clp) - s;
+ consumed = mbrtowc(, >l_text[s],
+ len, );
+ if (consumed < (size_t) -2) {
+ curwp->w_doto -= offset;
+ break;
+ }
+ mbs = (mbstate_t) { 0 };
+ offset++;
+ if (offset > MB_LEN_MAX) {
+ break;
+ }
+ }
+ }
}
return (TRUE);
}
@@ -108,8 +136,27 @@ forwchar(int f, int n)
curwp->w_doto = 0;
curwp->w_dotline++;
curwp->w_rflag |= WFMOVE;
- } else
+ } else if (!(curbp->b_flag & BFSHOWRAW)) {
+ /*
+* If we're on a multibyte character, and
+* not in raw mode, we should move all the
+* way through it.
+*/
+ mbstate_t mbs = { 0 };
+ wchar_t wc = 0;
+ size_t s = curwp->w_doto;
+ struct line *clp = curwp->w_dotp;
+ size_t len = llength(clp) - s;
+ size_t consumed = mbrtowc(, >l_text[s],
+ len, );
+ if (consumed && consumed < (size_t) -2) {
+ curwp->w_doto += consumed;
+ } else {
+ curwp->w_doto++;
+ }
+ } else {
curwp->w_doto++;
+ }
}
return (TRUE);
}
@@ -269,12 +316,25 @@ setgoal(void)
int
getgoal(struct line *dlp)
{
- int c, i, col = 0;
- char tmp[5];
+ return getbyteofcol(dlp, 0, curgoal);
+}
+/*
+ * Return the byte offset within lp that is targetcol columns beyond
+ * startbyte
+ */
+size_t
+getbyteofcol(const struct line *lp, const size_t startbyte,
+ const size_t targetcol)
+{
+ int c;
+ size_t i, col = 0;
+ char tmp[5];
+ size_t advance_by = 1;
- for (i = 0; i < llength(dlp); i++) {
- c = lgetc(dlp, i);
+ for (i = startbyte; i < llength(lp); i += advance_by) {
+ advance_by = 1;
+ c = lgetc(lp, i);
if (c == '\t'
#ifdef NOTAB
&& !(curbp->b_flag & BFNOTAB)
@@ -282,18 +342,86 @@ getgoal(struct line *dlp)
) {
col |= 0x07;
col++;
- } else if (ISCTRL(c) != FALSE) {
+ } else if (iscntrl(c)) {
col += 2;
- } else if (isprint(c))
+ } else if (isprint(c)) {
col++;
- else {
+ } else if (!(curbp->b_flag & BFSHOWRAW)) {
+ mbstate_t mbs = { 0 };
+ wchar_t wc = 0;
+ size_t consumed = mbrtowc(, >l_text[i],
+ llength(lp) - i, );
+ int width = -1;
+ if (consumed < (size_t) -2) {
+ width = wcwidth(wc);
+ }
+ if (width >= 0) {
+ col += width;
+ advance_by = consumed;
+
Remove comcnspeed and comcnmode on armv7
Remove unused infrastructure. After this we arm64 and armv7 com_fdt.c
are identical and I can move it into dev/fdt.
ok?
Index: armv7/armv7_machdep.c
===
RCS file: /cvs/src/sys/arch/armv7/armv7/armv7_machdep.c,v
retrieving revision 1.53
diff -u -p -r1.53 armv7_machdep.c
--- armv7/armv7_machdep.c 15 May 2018 11:11:35 - 1.53
+++ armv7/armv7_machdep.c 30 May 2018 13:23:36 -
@@ -207,16 +207,6 @@ void consinit(void);
bs_protos(bs_notimpl);
-#ifndef CONSPEED
-#define CONSPEED B115200 /* What u-boot */
-#endif
-#ifndef CONMODE
-#define CONMODE ((TTYDEF_CFLAG & ~(CSIZE | CSTOPB | PARENB)) | CS8) /* 8N1 */
-#endif
-
-int comcnspeed = CONSPEED;
-int comcnmode = CONMODE;
-
int stdout_node;
int stdout_speed;
Index: dev/com_fdt.c
===
RCS file: /cvs/src/sys/arch/armv7/dev/com_fdt.c,v
retrieving revision 1.13
diff -u -p -r1.13 com_fdt.c
--- dev/com_fdt.c 14 May 2018 19:25:54 - 1.13
+++ dev/com_fdt.c 30 May 2018 13:23:36 -
@@ -39,9 +39,6 @@ int com_fdt_match(struct device *, void
void com_fdt_attach(struct device *, struct device *, void *);
intcom_fdt_intr_designware(void *);
-extern int comcnspeed;
-extern int comcnmode;
-
struct cfattach com_fdt_ca = {
sizeof (struct com_softc), com_fdt_match, com_fdt_attach
};
@@ -135,8 +132,7 @@ com_fdt_attach(struct device *parent, st
SET(sc->sc_hwflags, COM_HW_CONSOLE);
SET(sc->sc_swflags, COM_SW_SOFTCAR);
comconsfreq = sc->sc_frequency;
- comconsrate = stdout_speed ? stdout_speed : comcnspeed;
- comconscflag = comcnmode;
+ comconsrate = stdout_speed ? stdout_speed : B115200;
}
if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr,
Index: dev/pluart.c
===
RCS file: /cvs/src/sys/arch/armv7/dev/pluart.c,v
retrieving revision 1.7
diff -u -p -r1.7 pluart.c
--- dev/pluart.c19 Feb 2018 08:59:52 - 1.7
+++ dev/pluart.c30 May 2018 13:23:36 -
@@ -182,9 +182,6 @@ struct pluart_softc *pluart_sc(dev_t dev
int pluart_intr(void *);
-extern int comcnspeed;
-extern int comcnmode;
-
/* XXX - we imitate 'com' serial ports and take over their entry points */
/* XXX: These belong elsewhere */
cdev_decl(pluart);
@@ -214,7 +211,7 @@ pluart_init_cons(void)
if (fdt_get_reg(node, 0, ))
return;
- pluartcnattach(_bs_tag, reg.addr, comcnspeed, comcnmode);
+ pluartcnattach(_bs_tag, reg.addr, B115200, TTYDEF_CFLAG);
}
int
Index: exynos/exuart.c
===
RCS file: /cvs/src/sys/arch/armv7/exynos/exuart.c,v
retrieving revision 1.14
diff -u -p -r1.14 exuart.c
--- exynos/exuart.c 19 Feb 2018 08:59:52 - 1.14
+++ exynos/exuart.c 30 May 2018 13:23:36 -
@@ -108,9 +108,6 @@ struct exuart_softc *exuart_sc(dev_t dev
int exuart_intr(void *);
-extern int comcnspeed;
-extern int comcnmode;
-
/* XXX - we imitate 'com' serial ports and take over their entry points */
/* XXX: These belong elsewhere */
cdev_decl(exuart);
@@ -152,7 +149,7 @@ exuart_init_cons(void)
if (fdt_get_reg(node, 0, ))
return;
- exuartcnattach(_bs_tag, reg.addr, comcnspeed, comcnmode);
+ exuartcnattach(_bs_tag, reg.addr, B115200, TTYDEF_CFLAG);
}
int
bgpd ignore aspath with to large attributes
Hi,
This adds a protection to handle aspaths overly large attributes in bgpd.
The main idea is to protect other bgp routes downstream for hitting the
limit with is often not well catched.
The limit is currently a bit arbitarily set to 4096 - 1024 which is afaik
the same limit that bird uses.
While the default free zone should be fine with this it may be to strict
from some strange internal use, where a large amount of e.g. communities
are attached for extra information. I don't want to make this a knob
fest and making this configurable. So happy for input from BGP users.
Cheers
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.379
diff -u -p -r1.379 rde.c
--- rde.c 10 Feb 2018 05:54:31 - 1.379
+++ rde.c 24 Feb 2018 13:16:09 -
@@ -997,6 +997,13 @@ rde_update_dispatch(struct imsg *imsg)
if (attrpath_len != 0) { /* 0 = no NLRI information in this message */
/* parse path attributes */
asp = path_get();
+ /* protect from oversized messages */
+ if (attrpath_len > 4096 - 1024) {
+ asp->flags |= F_ATTR_PARSE_ERR;
+ log_peer_warnx(>conf, "update too big (%i), "
+ "path invalidated and prefix withdrawn",
+ attrpath_len);
+ }
while (len > 0) {
if ((pos = rde_attr_parse(p, len, peer, asp,
)) < 0)
Re: [Patch] mg(1): Experimental UTF-8 support
Hi Stefan! I'm sorry, fileio.c was out of sync that day, that's my bad, I forgot to remove its diff. Sorry for not reading diffs before sending them (I read your comments), that's why I call it experimental: I blindly applied diffs and tested mg in runtime. I'll send your comments to S. Gilles, after all he made all that huge work :)
Re: [Patch] mg(1): Experimental UTF-8 support
Comments inline. I think this still needs a lot of work...
I've done one pass over this to weed out some obvious problems.
There might be many I've missed.
Not going to do any run-time testing because emacs/mg break my fingers ;)
On Mon, May 28, 2018 at 09:32:10PM +0300, Leonid Bobrov wrote:
> Index: basic.c
> ===
> RCS file: /cvs/src/usr.bin/mg/basic.c,v
> retrieving revision 1.47
> diff -u -p -u -p -r1.47 basic.c
> --- basic.c 10 Oct 2015 09:13:14 - 1.47
> +++ basic.c 28 May 2018 18:08:10 -
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include "def.h"
>
> @@ -269,12 +270,25 @@ setgoal(void)
> int
> getgoal(struct line *dlp)
> {
> - int c, i, col = 0;
> - char tmp[5];
> + return getbyteofcol(dlp, 0, curgoal);
> +}
>
> +/*
> + * Return the byte offset within lp that is targetcol columns beyond
> + * startbyte
> + */
> +size_t
> +getbyteofcol(const struct line *lp, const size_t startbyte,
> + const size_t targetcol)
> +{
> + int c;
> + size_t i, col = 0;
> + char tmp[5];
> + size_t advance_by = 1;
>
> - for (i = 0; i < llength(dlp); i++) {
> - c = lgetc(dlp, i);
> + for (i = startbyte; i < llength(lp); i += advance_by) {
> + advance_by = 1;
> + c = lgetc(lp, i);
> if (c == '\t'
> #ifdef NOTAB
> && !(curbp->b_flag & BFNOTAB)
> @@ -284,16 +298,84 @@ getgoal(struct line *dlp)
> col++;
> } else if (ISCTRL(c) != FALSE) {
> col += 2;
> - } else if (isprint(c))
> + } else if (isprint(c)) {
> col++;
> - else {
> + } else if (!(curbp->b_flag & BFSHOWRAW)) {
> + mbstate_t mbs = { 0 };
> + wchar_t wc = 0;
> + size_t consumed = mbrtowc(, >l_text[i],
> + llength(lp) - i, );
> + int width = -1;
> + if (consumed < (size_t) -2) {
I think this should say: consumed > 0
Since both (size_t)-1 and (size_t)-2 indicate special error conditions
they should only be compared the with == operator, in my opinion.
Please read the mbrtowc man page if you haven't already.
It covers error conditions extensively.
A good idiom would be something like:
size_t ret = mbrtowc(...)
if (ret == (size_t)-1) {
/* handle decoding error */
} else if (ret == (size_t)-2) {
/* handle incomplete sequence */
} else if (ret == 0) {
/* handle end of line */
} else {
/* handle character which was parsed */
}
> + width = wcwidth(wc);
> + }
> + if (width >= 0) {
You should explicitly deal with width == -1 here as well.
A negative width means this line contains a non-printable character.
But that doesn't mean this character won't have any effect when printed.
You might want to narrow down the truth about such a character
with iswcntrl() and friends and take some appropriate action.
> + col += width;
> + advance_by = consumed;
What if consumed == (size_t)-1 or (size_t)-2 here?
In particular, you need to decide what to do with illegal byte sequences.
An editor should probably display them in some escaped form and continue
processing valid text beyond. UTF-8 is self-synchronizing so this should
not be too difficult. Printing such bytes in an escaped form might
require more columns than a valid byte sequence would.
Can it happen at any step during editing with mg that a valid multi-byte
character gets split by a newline? That would cause (size_t)-2 here since
this function is processing only one line. An editor should avoid introducing
this problem, but should be able to cope with files which already have this
problem when they are opened.
A good design would process a file such that any existing invalid multi-byte
characters will at least remain as they were when the file was opened, or
at best can be repaired by the user (do not get tempted to try to magically
"fix" the data).
> + } else {
> + col += snprintf(tmp, sizeof(tmp), "\\%o", c);
What if snprintf returns -1 here?
> + }
> + } else {
> col += snprintf(tmp, sizeof(tmp), "\\%o", c);
What if snprintf returns -1 here?
> }
> - if (col > curgoal)
> + if (col > targetcol)
> break;
> }
> return (i);
> }
> +
> +/*
> + * Return the column at which specified offset byte would appear, if
> + * this were part of a longer string printed by vtputs, starting at
> + * intial_col
> + */
>
Adding IPL_MPFLOOR to sh/armv7
Hi, The following patch adds IPL_MPFLOOR to the two last archs missing it, namely landisk and armv7. The goal is to be able to use the define in MI code (note that it's already used but hidden behind a #ifdef MULTIPROCESSOR). I define it to IPL_NONE because those two archs are only UNIPROCESSOR as far as I can tell, as such they don't have any mp lock to protect against. This has been cross build tested after a long battle with the cross build system (thanks to drahn@ and bmercer@ for the helpful tips btw!), but not run tested as I do not own those archs. I do not expect any fallout for the define is not used on those platforms (sys/mutex.h conditionnalize on MULTIPROCESSOR as noted above). Mathieu. diff --git arch/armv7/include/intr.h arch/armv7/include/intr.h index 5b3f320009d..0607ee462e2 100644 --- arch/armv7/include/intr.h +++ arch/armv7/include/intr.h @@ -61,6 +61,7 @@ /* Interrupt priority "flags". */ #defineIPL_MPSAFE 0 /* no "mpsafe" interrupts */ +#defineIPL_MPFLOOR IPL_NONE/* no MP on armv7 */ /* Interrupt sharing types. */ #defineIST_NONE0 /* none */ diff --git arch/landisk/include/intr.h arch/landisk/include/intr.h index d87b2be5dd0..50d4e488359 100644 --- arch/landisk/include/intr.h +++ arch/landisk/include/intr.h @@ -46,6 +46,7 @@ #defineIPL_HIGH15 /* everything */ #defineIPL_MPSAFE 0 /* no "mpsafe" interrupts */ +#defineIPL_MPFLOOR IPL_NONE/* no MP on landisk */ #definesplraise(_ipl) _cpu_intr_raise((_ipl) << 4) #definesplsoftclock() splraise(IPL_SOFTCLOCK)
Re: [patch] Add kvm_close in mib_hrsystemprocs function
On Wed, 30 May 2018 16:25:55 +0800 Nan Xiao wrote:
> Hi tech@,
>
> Maybe kvm_close is needed if kvm_getprocs returns NULL here? Sorry if I
> am wrong, thanks!
>
> Index: mib.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 mib.c
> --- mib.c 25 May 2018 08:23:15 - 1.87
> +++ mib.c 30 May 2018 08:15:19 -
> @@ -516,8 +516,10 @@ mib_hrsystemprocs(struct oid *oid, struc
> return (-1);
>
> if (kvm_getprocs(kd, KERN_PROC_ALL, 0,
> - sizeof(struct kinfo_proc), ) == NULL)
> + sizeof(struct kinfo_proc), ) == NULL) {
> + kvm_close(kd);
> return (-1);
> + }
>
> *elm = ber_add_integer(*elm, val);
> ber_set_header(*elm, BER_CLASS_APPLICATION, SNMP_T_GAUGE32);
>
Looks reasonable.
const for X509_certificate_type()
Here's one that is not entirely trivial. This needs my previous diff
because of EVP_PKEY_size().
Instead of using the refcounting in X509_get_pubkey() and
EVP_PKEY_free(), use X509_get0_pubkey() and check its return value in
the proper place. Zap an ugly comment that lived for 20 years and
simplify a bit.
Index: lib/libcrypto/x509/x509.h
===
RCS file: /var/cvs/src/lib/libcrypto/x509/x509.h,v
retrieving revision 1.67
diff -u -p -r1.67 x509.h
--- lib/libcrypto/x509/x509.h 19 May 2018 10:58:08 - 1.67
+++ lib/libcrypto/x509/x509.h 30 May 2018 08:16:13 -
@@ -1002,7 +1002,7 @@ int X509_set_pubkey(X509 *x, EVP_PKEY
EVP_PKEY * X509_get_pubkey(X509 *x);
EVP_PKEY * X509_get0_pubkey(const X509 *x);
ASN1_BIT_STRING *X509_get0_pubkey_bitstr(const X509 *x);
-intX509_certificate_type(X509 *x,EVP_PKEY *pubkey /* optional */);
+intX509_certificate_type(const X509 *x, const EVP_PKEY *pubkey);
intX509_REQ_set_version(X509_REQ *x,long version);
intX509_REQ_set_subject_name(X509_REQ *req,X509_NAME *name);
Index: lib/libcrypto/x509/x509type.c
===
RCS file: /var/cvs/src/lib/libcrypto/x509/x509type.c,v
retrieving revision 1.12
diff -u -p -r1.12 x509type.c
--- lib/libcrypto/x509/x509type.c 13 Jun 2015 08:38:10 - 1.12
+++ lib/libcrypto/x509/x509type.c 30 May 2018 08:16:13 -
@@ -63,27 +63,23 @@
#include
int
-X509_certificate_type(X509 *x, EVP_PKEY *pkey)
+X509_certificate_type(const X509 *x, const EVP_PKEY *pkey)
{
- EVP_PKEY *pk;
+ const EVP_PKEY *pk;
int ret = 0, i;
if (x == NULL)
return (0);
- if (pkey == NULL)
- pk = X509_get_pubkey(x);
- else
+ if (pkey == NULL) {
+ if ((pk = X509_get0_pubkey(x)) == NULL)
+ return (0);
+ } else
pk = pkey;
- if (pk == NULL)
- return (0);
-
switch (pk->type) {
case EVP_PKEY_RSA:
- ret = EVP_PK_RSA|EVP_PKT_SIGN;
-/* if (!sign only extension) */
- ret |= EVP_PKT_ENC;
+ ret = EVP_PK_RSA|EVP_PKT_SIGN|EVP_PKT_ENC;
break;
case EVP_PKEY_DSA:
ret = EVP_PK_DSA|EVP_PKT_SIGN;
@@ -124,7 +120,5 @@ X509_certificate_type(X509 *x, EVP_PKEY
/* /8 because it's 1024 bits we look for, not bytes */
if (EVP_PKEY_size(pk) <= 1024 / 8)
ret |= EVP_PKT_EXP;
- if (pkey == NULL)
- EVP_PKEY_free(pk);
return (ret);
}
[patch] Add kvm_close in mib_hrsystemprocs function
Hi tech@,
Maybe kvm_close is needed if kvm_getprocs returns NULL here? Sorry if I
am wrong, thanks!
Index: mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.87
diff -u -p -r1.87 mib.c
--- mib.c 25 May 2018 08:23:15 - 1.87
+++ mib.c 30 May 2018 08:15:19 -
@@ -516,8 +516,10 @@ mib_hrsystemprocs(struct oid *oid, struc
return (-1);
if (kvm_getprocs(kd, KERN_PROC_ALL, 0,
- sizeof(struct kinfo_proc), ) == NULL)
+ sizeof(struct kinfo_proc), ) == NULL) {
+ kvm_close(kd);
return (-1);
+ }
*elm = ber_add_integer(*elm, val);
ber_set_header(*elm, BER_CLASS_APPLICATION, SNMP_T_GAUGE32);
--
Best Regards
Nan Xiao
Re: [Patch] mg(1): Experimental UTF-8 support
> Am 30.05.2018 um 10:10 schrieb Leonid Bobrov : > >> On Wed, May 30, 2018 at 09:05:12AM +0200, Hiltjo Posthuma wrote: >>> On Tue, May 29, 2018 at 05:22:43PM +0300, Leonid Bobrov wrote: On Tue, May 29, 2018 at 03:33:08PM +0200, Henning Brauer wrote: Hi, very welcome! I have applied the diff and don't notice immediate breakage. Pls poke >>> >>> You didn't notice cursor movement bugs? o_O >>> Well, I'm giving example: авыавыавы >>> To move from start to end of that word, you have to press M-f 3 times. >>> >>> Also you might notice you have to press C-f twice to move one character >>> forward. >>> >>> https://github.com/hboetes/mg/commits/display-wide-characters >>> >> >> The viewing looks good, but I can confirm to also notice the "character" >> movement bug. >> >> locale is all set to "en_US.UTF-8". >> >> A good test file is I think: >> https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt >> >> Thanks for the work so far. UTF-8 support would be really nice! :) >> > > Thanks goes to S. Gilles , he made it :) > > Recent commits fixed cursor movement bugs, my work is to send fresh > patches to this list to make sure mg merges UTF-8 support <3 > I‘m in favor of this, mg is my number one productivity tool and UTF-8 support would be really really great. I will test it as well. Reyk >>> There are new commits, I'll test them later and send a new diff, >>> so I hope mg is ready to support UTF-8, yeah <3 >>> me in a few days to give an ok (and hope same brave soul takes committing on his plate) assuming I don't run into trouble. ciao Henning >>> >> >> -- >> Kind regards, >> Hiltjo >> >
Re: httpd request rewrite
> Am 30.05.2018 um 10:12 schrieb Sebastian Benoit :
>
> Sebastian Benoit(be...@openbsd.org) on 2018.05.30 10:10:51 +0200:
>> Reyk Floeter(r...@openbsd.org) on 2018.05.29 18:48:31 +0200:
>>> Hi,
>>>
>>> it's about time.
>>>
>>>server "default" {
>>>listen on * port 80
>>>location match "/de/(.*)" {
>>>request rewrite "/ch/%1"
>>>}
>>>}
>>>
>>> You can also you the macros as in the "block return" external
>>> redirects. So maybe something like:
>>>
>>>server "default" {
>>>listen on * port 80
>>>location match "/(.*)" {
>>>request rewrite "/$HTTP_HOST/%1"
>>>}
>>>}
>>>
>>> Tests? OK?
>>
>> nice,
>>
>> but why use %1 instead of $1 as all other mechanisms of this kind do (that i
>> knwo of)?
>
> to answer myself: patterns(7)
Right ;-) I’m going to stick with it.
Reyk
Re: httpd request rewrite
Sebastian Benoit(be...@openbsd.org) on 2018.05.30 10:10:51 +0200:
> Reyk Floeter(r...@openbsd.org) on 2018.05.29 18:48:31 +0200:
> > Hi,
> >
> > it's about time.
> >
> > server "default" {
> > listen on * port 80
> > location match "/de/(.*)" {
> > request rewrite "/ch/%1"
> > }
> > }
> >
> > You can also you the macros as in the "block return" external
> > redirects. So maybe something like:
> >
> > server "default" {
> > listen on * port 80
> > location match "/(.*)" {
> > request rewrite "/$HTTP_HOST/%1"
> > }
> > }
> >
> > Tests? OK?
>
> nice,
>
> but why use %1 instead of $1 as all other mechanisms of this kind do (that i
> knwo of)?
to answer myself: patterns(7)
Re: httpd request rewrite
Reyk Floeter(r...@openbsd.org) on 2018.05.29 18:48:31 +0200:
> Hi,
>
> it's about time.
>
> server "default" {
> listen on * port 80
> location match "/de/(.*)" {
> request rewrite "/ch/%1"
> }
> }
>
> You can also you the macros as in the "block return" external
> redirects. So maybe something like:
>
> server "default" {
> listen on * port 80
> location match "/(.*)" {
> request rewrite "/$HTTP_HOST/%1"
> }
> }
>
> Tests? OK?
nice,
but why use %1 instead of $1 as all other mechanisms of this kind do (that i
knwo of)?
Re: [Patch] mg(1): Experimental UTF-8 support
On Wed, May 30, 2018 at 09:05:12AM +0200, Hiltjo Posthuma wrote: > On Tue, May 29, 2018 at 05:22:43PM +0300, Leonid Bobrov wrote: > > On Tue, May 29, 2018 at 03:33:08PM +0200, Henning Brauer wrote: > > > Hi, > > > > > > very welcome! > > > > > > I have applied the diff and don't notice immediate breakage. Pls poke > > > > You didn't notice cursor movement bugs? o_O > > Well, I'm giving example: авыавыавы > > To move from start to end of that word, you have to press M-f 3 times. > > > > Also you might notice you have to press C-f twice to move one character > > forward. > > > > https://github.com/hboetes/mg/commits/display-wide-characters > > > > The viewing looks good, but I can confirm to also notice the "character" > movement bug. > > locale is all set to "en_US.UTF-8". > > A good test file is I think: > https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt > > Thanks for the work so far. UTF-8 support would be really nice! :) > Thanks goes to S. Gilles , he made it :) Recent commits fixed cursor movement bugs, my work is to send fresh patches to this list to make sure mg merges UTF-8 support <3 > > There are new commits, I'll test them later and send a new diff, > > so I hope mg is ready to support UTF-8, yeah <3 > > > > > me in a few days to give an ok (and hope same brave soul takes > > > committing on his plate) assuming I don't run into trouble. > > > > > > ciao > > > > > > Henning > > > > > > > -- > Kind regards, > Hiltjo >
Re: [Patch] mg(1): Experimental UTF-8 support
On Tue, May 29, 2018 at 05:22:43PM +0300, Leonid Bobrov wrote: > On Tue, May 29, 2018 at 03:33:08PM +0200, Henning Brauer wrote: > > Hi, > > > > very welcome! > > > > I have applied the diff and don't notice immediate breakage. Pls poke > > You didn't notice cursor movement bugs? o_O > Well, I'm giving example: авыавыавы > To move from start to end of that word, you have to press M-f 3 times. > > Also you might notice you have to press C-f twice to move one character > forward. > > https://github.com/hboetes/mg/commits/display-wide-characters > The viewing looks good, but I can confirm to also notice the "character" movement bug. locale is all set to "en_US.UTF-8". A good test file is I think: https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt Thanks for the work so far. UTF-8 support would be really nice! :) > There are new commits, I'll test them later and send a new diff, > so I hope mg is ready to support UTF-8, yeah <3 > > > me in a few days to give an ok (and hope same brave soul takes > > committing on his plate) assuming I don't run into trouble. > > > > ciao > > > > Henning > > > -- Kind regards, Hiltjo
