Re: mg(1) compatibility patches
> Sent: Sunday, November 16, 2014 at 1:09 AM > From: "Philip Guenther" > To: "Kamil Rytarowski" > Cc: "Theo de Raadt" , tech-openbsd > , "Ted Unangst" > Subject: Re: mg(1) compatibility patches > > On Fri, Nov 14, 2014 at 3:16 PM, Kamil Rytarowski wrote: > ... > > Feel free to evaluate the rest of the patches (0002-0005), > > as they are meant to be generic. > > With a couple, I've committed those. Thanks! > > > Philip Guenther > > Thank you!
Re: mg(1) compatibility patches
On Fri, Nov 14, 2014 at 3:16 PM, Kamil Rytarowski wrote: ... > Feel free to evaluate the rest of the patches (0002-0005), > as they are meant to be generic. With a couple, I've committed those. Thanks! Philip Guenther
Re: mg(1) compatibility patches
On Fri, Nov 14, 2014 at 11:51:14PM +0100, Kamil Rytarowski wrote: > In downstream (except FreeBSD and libbsd consumers) there is missing > strtonum(3). To enhance mg(1) and catch its bugs in general I need to > start with improvement of its portability to other unsupported systems > (as I'm a consumer of few pkgsrc platforms). > > Please point appropriate way to do it, preferably without floating > patches around. > > Best regards, As you said, mg(1) is maintained in OpenBSD's tree. It has been for 15+ years, it makes use of fuctionality provided by the system. In this case an OpenBSD invention, strtonum(3). If you want to port it to systems without that API, you can copy OpenBSD's implementation, or if you consider this a burden.. try convincing systems like NetBSD? to support strtonum(3). :-) -Bryan.
Re: mg(1) compatibility patches
> Sent: Friday, November 14, 2014 at 11:00 PM > From: "Theo de Raadt" > To: dera...@cvs.openbsd.org, n...@gmx.com > Cc: tech@openbsd.org, t...@tedunangst.com > Subject: Re: mg(1) compatibility patches > > The problem you are trying to define is that we (OpenBSD) are supposed > to have a sense of responsibility to make a portable version of mg. > > Sorry, but I cannot find any file or email where that intent was > declared in the past. > > > I think you are on your own. > > Okay. Feel free to evaluate the rest of the patches (0002-0005), as they are meant to be generic. With regards,
Re: mg(1) compatibility patches
"Kamil Rytarowski" writes: >> Sent: Friday, November 14, 2014 at 9:10 PM >> From: "Ted Unangst" >> To: "Kamil Rytarowski" >> Cc: tech@openbsd.org >> Subject: Re: mg(1) comaptibility patches >> >> On Fri, Nov 14, 2014 at 20:29, Kamil Rytarowski wrote: >> > 0001-Define-strtonum-3-for-the-NetBSD-target.patch >> >> I don't like this at all. The reason we put strtonum in libc is >> precisely not to have multiple copies of it floating around the tree. >> Uncompiled copies are still clutter. >> >> This may be odd for a BSD system, but perhaps the pkgsrc version could >> link against libbsd? >> > > Actually not as libbsd is in reality GNU/Linux-oriented. > > Other solution is to go backward for strtol(3)-like functions, > what do you think? There's a portable mg distribution maintained by Han Boetes. It's used by at least twb for the Debian mg package. IIUC your use case is pkgsrc, therefore adding compat for just NetBSD is not sufficient. Cheers, -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: mg(1) compatibility patches
>> Sent: Friday, November 14, 2014 at 9:59 PM >> From: "Theo de Raadt" >> To: n...@gmx.com, t...@tedunangst.com >> Cc: tech@openbsd.org >> Subject: Re: mg(1) compatibility patches >> >> >> Sent: Friday, November 14, 2014 at 9:10 PM >> >> From: "Ted Unangst" >> >> To: "Kamil Rytarowski" >> >> Cc: tech@openbsd.org >> >> Subject: Re: mg(1) comaptibility patches >> >> >> >> On Fri, Nov 14, 2014 at 20:29, Kamil Rytarowski wrote: >> >> > 0001-Define-strtonum-3-for-the-NetBSD-target.patch >> >> >> >> I don't like this at all. The reason we put strtonum in libc is >> >> precisely not to have multiple copies of it floating around the tree. >> >> Uncompiled copies are still clutter. >> >> >> >> This may be odd for a BSD system, but perhaps the pkgsrc version could >> >> link against libbsd? >> >> >> > >> >Actually not as libbsd is in reality GNU/Linux-oriented. >> > >> >Other solution is to go backward for strtol(3)-like functions, >> >what do you think? >> >> >> Solution to what problem? >> >> > >Hello Theo, > >mg(1) is maintained in OpenBSD's CVS tree, therefore OpenBSD is upstream. > >In downstream (except FreeBSD and libbsd consumers) there is missing >strtonum(3). To enhance mg(1) and catch its bugs in general I need to >start with improvement of its portability to other unsupported systems >(as I'm a consumer of few pkgsrc platforms). > >Please point appropriate way to do it, preferably without floating >patches around. The problem you are trying to define is that we (OpenBSD) are supposed to have a sense of responsibility to make a portable version of mg. Sorry, but I cannot find any file or email where that intent was declared in the past. I think you are on your own.
Re: mg(1) compatibility patches
> Sent: Friday, November 14, 2014 at 9:59 PM > From: "Theo de Raadt" > To: n...@gmx.com, t...@tedunangst.com > Cc: tech@openbsd.org > Subject: Re: mg(1) compatibility patches > > >> Sent: Friday, November 14, 2014 at 9:10 PM > >> From: "Ted Unangst" > >> To: "Kamil Rytarowski" > >> Cc: tech@openbsd.org > >> Subject: Re: mg(1) comaptibility patches > >> > >> On Fri, Nov 14, 2014 at 20:29, Kamil Rytarowski wrote: > >> > 0001-Define-strtonum-3-for-the-NetBSD-target.patch > >> > >> I don't like this at all. The reason we put strtonum in libc is > >> precisely not to have multiple copies of it floating around the tree. > >> Uncompiled copies are still clutter. > >> > >> This may be odd for a BSD system, but perhaps the pkgsrc version could > >> link against libbsd? > >> > > > >Actually not as libbsd is in reality GNU/Linux-oriented. > > > >Other solution is to go backward for strtol(3)-like functions, > >what do you think? > > > Solution to what problem? > > Hello Theo, mg(1) is maintained in OpenBSD's CVS tree, therefore OpenBSD is upstream. In downstream (except FreeBSD and libbsd consumers) there is missing strtonum(3). To enhance mg(1) and catch its bugs in general I need to start with improvement of its portability to other unsupported systems (as I'm a consumer of few pkgsrc platforms). Please point appropriate way to do it, preferably without floating patches around. Best regards,
Re: mg(1) compatibility patches
>> Sent: Friday, November 14, 2014 at 9:10 PM >> From: "Ted Unangst" >> To: "Kamil Rytarowski" >> Cc: tech@openbsd.org >> Subject: Re: mg(1) comaptibility patches >> >> On Fri, Nov 14, 2014 at 20:29, Kamil Rytarowski wrote: >> > 0001-Define-strtonum-3-for-the-NetBSD-target.patch >> >> I don't like this at all. The reason we put strtonum in libc is >> precisely not to have multiple copies of it floating around the tree. >> Uncompiled copies are still clutter. >> >> This may be odd for a BSD system, but perhaps the pkgsrc version could >> link against libbsd? >> > >Actually not as libbsd is in reality GNU/Linux-oriented. > >Other solution is to go backward for strtol(3)-like functions, >what do you think? Solution to what problem?
Re: mg(1) compatibility patches
> Sent: Friday, November 14, 2014 at 9:10 PM > From: "Ted Unangst" > To: "Kamil Rytarowski" > Cc: tech@openbsd.org > Subject: Re: mg(1) comaptibility patches > > On Fri, Nov 14, 2014 at 20:29, Kamil Rytarowski wrote: > > 0001-Define-strtonum-3-for-the-NetBSD-target.patch > > I don't like this at all. The reason we put strtonum in libc is > precisely not to have multiple copies of it floating around the tree. > Uncompiled copies are still clutter. > > This may be odd for a BSD system, but perhaps the pkgsrc version could > link against libbsd? > Actually not as libbsd is in reality GNU/Linux-oriented. Other solution is to go backward for strtol(3)-like functions, what do you think?
Re: mg(1) compatibility patches
Hello,
Thank you for your comments. Please see my comments below.
With regards,
> Sent: Friday, November 14, 2014 at 8:48 PM
> From: "Philip Guenther"
> To: "Kamil Rytarowski"
> Cc: tech-openbsd
> Subject: Re: mg(1) comaptibility patches
>
> On Fri, Nov 14, 2014 at 11:29 AM, Kamil Rytarowski wrote:
> > As maintaining local patches or forking mg(1) for plain compatibility
> > is doubtful, I'm going to send you a set of patches.
> >
> > I don't want to make noise with a mail per patch, so I'm attaching all
> > patches to this mail.
> > Please review (if needed adapt) and merge.
> >
> > List of files:
> ...
> > 0002-Add-missing-include-for-struct-timespec-NetBSD.patch
>
> sysdef.h should include for struct timespec; is
> not required to provide it.
Fixed. I changed it to be pulled on all platforms.
>
> ...
> > 0006-Enhance-type-correctness-cast-parameter-of-isspace-3.patch
>
> This diff is wrong, sorry. The code where a ctype function is being
> called on a char from a char * pointer should be casting to (unsigned
> char); the code where 'c' is set from lgetc() should declare c as an
> int, as lgetc() does the necessary cast.
>
Hopefully fixed.
>
> Philip Guenther
> >From 4a1225c6c64fc857c6442b0135642a109f1d045d Mon Sep 17 00:00:00 2001
From: Kamil Rytarowski
Date: Fri, 14 Nov 2014 17:55:36 +
Subject: [PATCH 2/6] Add missing include for struct timespec
---
sysdef.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/sysdef.h b/sysdef.h
index 3fde496..2f5078e 100644
--- a/sysdef.h
+++ b/sysdef.h
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#define KBLOCK 8192 /* Kill grow. */
#define GOOD 0 /* Good exit status. */
--
2.1.0
>From 4df46840b96e4de796e822f6636ea0e59b55697a Mon Sep 17 00:00:00 2001
From: Kamil Rytarowski
Date: Fri, 14 Nov 2014 18:34:44 +
Subject: [PATCH 6/6] Enhance parameter type correctness of ctype functions
---
cscope.c | 2 +-
extend.c | 2 +-
grep.c | 3 ++-
tags.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/cscope.c b/cscope.c
index 0deada3..b334e6b 100644
--- a/cscope.c
+++ b/cscope.c
@@ -557,7 +557,7 @@ prettyprint(struct buffer *bp, struct cstokens *t)
const char *
ltrim(const char *s)
{
- while (isblank(*s))
+ while (isblank((unsigned char)*s))
s++;
return s;
}
diff --git a/extend.c b/extend.c
index ef59d5f..6196691 100644
--- a/extend.c
+++ b/extend.c
@@ -446,7 +446,7 @@ dobindkey(KEYMAP *map, const char *func, const char *str)
for (i = 0; *str && i < MAXKEY; i++) {
/* XXX - convert numbers w/ strol()? */
if (*str == '^' && *(str + 1) != '\0') {
- key.k_chars[i] = CCHR(toupper(*++str));
+ key.k_chars[i] = CCHR(toupper((unsigned char)*++str));
} else if (*str == '\\' && *(str + 1) != '\0') {
switch (*++str) {
case '^':
diff --git a/grep.c b/grep.c
index 6a4c1c4..55f7ae1 100644
--- a/grep.c
+++ b/grep.c
@@ -113,7 +113,8 @@ static int
gid(int f, int n)
{
char command[NFILEN];
- char cprompt[NFILEN], c, *bufp;
+ char cprompt[NFILEN], *bufp;
+ int c;
struct buffer *bp;
struct mgwin *wp;
int i, j, len;
diff --git a/tags.c b/tags.c
index e847b9e..b75f703 100644
--- a/tags.c
+++ b/tags.c
@@ -482,7 +482,7 @@ curtoken(int f, int n, char *token)
/* strip away leading whitespace if any like emacs. */
while (ltext(curwp->w_dotp) &&
- isspace(curwp->w_dotp->l_text[tdoto]))
+ isspace((unsigned char)curwp->w_dotp->l_text[tdoto]))
tdoto++;
size = curwp->w_doto - tdoto;
--
2.1.0
