ld.so: remove unused syscall stubs
_dl_gettimeofday() was used by the prebind code, which was recently removed. _dl_lstat() was only used by _dl_realpath(), which no longer needs it. ok? Index: alpha/ldasm.S === RCS file: /cvs/src/libexec/ld.so/alpha/ldasm.S,v retrieving revision 1.36 diff -u -p -r1.36 ldasm.S --- alpha/ldasm.S 7 Aug 2016 03:05:23 - 1.36 +++ alpha/ldasm.S 28 Aug 2016 04:12:17 - @@ -316,10 +316,8 @@ DL_SYSCALL(getdents) DL_SYSCALL(getentropy) DL_SYSCALL(sendsyslog) DL_SYSCALL(pledge) -DL_SYSCALL(gettimeofday) DL_SYSCALL_NOERR(issetugid) DL_SYSCALL_NOERR(getthrid) -DL_SYSCALL(lstat) DL_SYSCALL(mprotect) DL_SYSCALL(munmap) DL_SYSCALL(open) Index: alpha/syscall.h === RCS file: /cvs/src/libexec/ld.so/alpha/syscall.h,v retrieving revision 1.34 diff -u -p -r1.34 syscall.h --- alpha/syscall.h 4 Jul 2016 21:15:06 - 1.34 +++ alpha/syscall.h 28 Aug 2016 04:12:17 - @@ -51,10 +51,8 @@ int _dl_fstat(int, struct stat *); ssize_t_dl_getdents(int, char *, size_t); long _dl__syscall(quad_t, ...); int_dl_sysctl(const int *, u_int, void *, size_t *, void *, size_t); -int_dl_gettimeofday(struct timeval *, struct timezone *); ssize_t_dl_readlink(const char *, char *, size_t); int_dl_pledge(const char *, const char **); -int_dl_lstat(const char *, struct stat *); int_dl_getcwd(char *, size_t); int_dl_utrace(const char *, const void *, size_t); int_dl_getentropy(char *, size_t); Index: amd64/ldasm.S === RCS file: /cvs/src/libexec/ld.so/amd64/ldasm.S,v retrieving revision 1.24 diff -u -p -r1.24 ldasm.S --- amd64/ldasm.S 7 May 2016 19:05:23 - 1.24 +++ amd64/ldasm.S 28 Aug 2016 04:12:17 - @@ -91,10 +91,8 @@ DL_SYSCALL(getthrid) DL_SYSCALL(getdents) DL_SYSCALL(mprotect) DL_SYSCALL(munmap) -DL_SYSCALL(gettimeofday) DL_SYSCALL(exit) DL_SYSCALL(readlink) -DL_SYSCALL(lstat) DL_SYSCALL(utrace) DL_SYSCALL(getentropy) DL_SYSCALL(sendsyslog) Index: amd64/syscall.h === RCS file: /cvs/src/libexec/ld.so/amd64/syscall.h,v retrieving revision 1.22 diff -u -p -r1.22 syscall.h --- amd64/syscall.h 4 Jul 2016 21:15:06 - 1.22 +++ amd64/syscall.h 28 Aug 2016 04:12:18 - @@ -51,10 +51,8 @@ ssize_t _dl_read(int, const char *, size int_dl_fstat(int, struct stat *); ssize_t_dl_getdents(int, char *, size_t); int_dl_sysctl(const int *, u_int, void *, size_t *, void *, size_t); -int_dl_gettimeofday(struct timeval *, struct timezone *); ssize_t_dl_readlink(const char *, char *, size_t); int_dl_pledge(const char *, const char **); -int_dl_lstat(const char *, struct stat *); int_dl_getcwd(char *, size_t); int_dl_utrace(const char *, const void *, size_t); int_dl_getentropy(char *, size_t); Index: arm/ldasm.S === RCS file: /cvs/src/libexec/ld.so/arm/ldasm.S,v retrieving revision 1.23 diff -u -p -r1.23 ldasm.S --- arm/ldasm.S 9 Aug 2016 03:58:35 - 1.23 +++ arm/ldasm.S 28 Aug 2016 04:12:18 - @@ -126,9 +126,7 @@ DL_SYSCALL(open) DL_SYSCALL(read) DL_SYSCALL(write) DL_SYSCALL(fstat) -DL_SYSCALL(gettimeofday) DL_SYSCALL(readlink) -DL_SYSCALL(lstat) DL_SYSCALL(utrace) DL_SYSCALL(getentropy) DL_SYSCALL(sendsyslog) Index: arm/syscall.h === RCS file: /cvs/src/libexec/ld.so/arm/syscall.h,v retrieving revision 1.22 diff -u -p -r1.22 syscall.h --- arm/syscall.h 4 Jul 2016 21:15:06 - 1.22 +++ arm/syscall.h 28 Aug 2016 04:12:18 - @@ -51,10 +51,8 @@ ssize_t _dl_read(int, const char *, size int_dl_fstat(int, struct stat *); ssize_t_dl_getdents(int, char *, size_t); int_dl_sysctl(const int *, u_int, void *, size_t *, void *, size_t); -int_dl_gettimeofday(struct timeval *, struct timezone *); ssize_t_dl_readlink(const char *, char *, size_t); int_dl_pledge(const char *, const char **); -int_dl_lstat(const char *, struct stat *); int_dl_getcwd(char *, size_t); int_dl_utrace(const char *, const void *, size_t); int_dl_getentropy(char *, size_t); Index: hppa/ldasm.S === RCS file: /cvs/src/libexec/ld.so/hppa/ldasm.S,v retrieving revision 1.21 diff -u -p -r1.21 ldasm.S --- hppa/ldasm.S7 May 2016 19:05:23 - 1.21 +++ hppa/ldasm.S28 Aug 2016 04:12:18 - @@ -242,23 +242,11 @@ ENTRY(_dl_getdents,0) nop EXIT(_dl_getdents) -ENTRY(_dl_gettimeofday,0) - SYSCALL(gettimeofday) - bv r0(rp) - nop -EXIT(_dl_gettimeofday) - ENTRY(_dl_readlink,0) SYSCALL(readlink) bv
Re: replace struct vattr with struct stat in fusebuf
Sigh, stupid control-enter keybinding in gmail What I meant to say was: BTW, this chunk in fusefs_setattr(): On Sat, Aug 27, 2016 at 8:50 PM, Philip Guenther wrote: > if (io->fi_flags & FUSE_FATTR_SIZE && vp->v_type == VDIR) { > error = EISDIR; > goto out; > } can be deleted, as it's already covered by the code that set FUSE_FATTR_SIZE Philip
Re: replace struct vattr with struct stat in fusebuf
if (io->fi_flags & FUSE_FATTR_SIZE && vp->v_type == VDIR) { error = EISDIR; goto out; }
Re: replace struct vattr with struct stat in fusebuf
On Sat, Aug 27, 2016 at 4:42 AM, Martin Natano wrote: > In struct fusebuf the attributes (used for getattr/setattr and to return > the ino/mode of a newly created file) are stored in a struct vattr. The > problem with this is, that using struct vattr in userspace is suboptimal > as some related helpers are not available, e.g. VATTR_NULL() and IFTOVT(). > > What happens on getattr is this: fusefs requests the attributes for a > file from the userland process. libfuse calls the getattr fuse > operation, which fills in a struct stat. This struct is than converted > to a partial struct vattr, which is passed back to the kernel where > "fixup" takes place. > > Following diff simplifies that process by replacing the struct vattr in > fusebuf with a struct stat. The conversion is moved to the kernel where > it belongs. As a side effect the include can be removed > from libfuse. > > Ok? Objections? ok guenther@ Please delete the #include I added to fuse_private.h while you're there, as it was only needed for vnode.h Philip Guenther
Re: cwm(1): Enable numpad Enter on menus
I have no objections.. If I hear none by monday I can commit it for you On Sat, Aug 27, 2016 at 11:53:14PM -0300, Henrique N. Lengler wrote: > > Hi, > > > > This is a tiny patch to enable the use of numpad Enter key on cwm menus. > > > > Regards, > > > > Henrique N. Lengler > > No intention to apply this? > > Numpad enter key is is recognized by every program on openbsd base and > xenocara, > so this would keep consistency. Anyway it is only one line. > Index: menu.c > === > RCS file: /cvs/xenocara/app/cwm/menu.c,v > retrieving revision 1.90 > diff -u -p -r1.90 menu.c > --- menu.c28 Apr 2016 16:28:38 - 1.90 > +++ menu.c17 Aug 2016 19:14:06 - > @@ -523,6 +523,7 @@ menu_keycode(XKeyEvent *ev, enum ctltype > case XK_BackSpace: > *ctl = CTL_ERASEONE; > break; > + case XK_KP_Enter: > case XK_Return: > *ctl = CTL_RETURN; > break;
Re: cwm(1): Enable numpad Enter on menus
> Hi, > > This is a tiny patch to enable the use of numpad Enter key on cwm menus. > > Regards, > > Henrique N. Lengler No intention to apply this? Numpad enter key is is recognized by every program on openbsd base and xenocara, so this would keep consistency. Anyway it is only one line. Index: menu.c === RCS file: /cvs/xenocara/app/cwm/menu.c,v retrieving revision 1.90 diff -u -p -r1.90 menu.c --- menu.c 28 Apr 2016 16:28:38 - 1.90 +++ menu.c 17 Aug 2016 19:14:06 - @@ -523,6 +523,7 @@ menu_keycode(XKeyEvent *ev, enum ctltype case XK_BackSpace: *ctl = CTL_ERASEONE; break; + case XK_KP_Enter: case XK_Return: *ctl = CTL_RETURN; break;
Re: pf.conf X11 rule.
Well you've failed to justify removing it. Does it hurt anyone to leave it? > Xserver no longer listen on tcp 6000:6010 by default. I wonder if that pf > rule is still necessary. > > > Index: pf.conf > === > RCS file: /cvs/src/etc/pf.conf,v > retrieving revision 1.54 > diff -u -p -r1.54 pf.conf > --- pf.conf 23 Aug 2014 05:49:42 - 1.54 > +++ pf.conf 28 Aug 2016 01:22:26 - > @@ -6,6 +6,3 @@ set skip on lo > > block return # block stateless traffic > pass # establish keep-state > - > -# By default, do not permit remote connections to X11 > -block return in on ! lo0 proto tcp to port 6000:6010 >
pf.conf X11 rule.
Xserver no longer listen on tcp 6000:6010 by default. I wonder if that pf rule is still necessary. Index: pf.conf === RCS file: /cvs/src/etc/pf.conf,v retrieving revision 1.54 diff -u -p -r1.54 pf.conf --- pf.conf 23 Aug 2014 05:49:42 - 1.54 +++ pf.conf 28 Aug 2016 01:22:26 - @@ -6,6 +6,3 @@ set skip on lo block return # block stateless traffic pass # establish keep-state - -# By default, do not permit remote connections to X11 -block return in on ! lo0 proto tcp to port 6000:6010
simplify realpath(3) slightly
Currently, realpath() calls lstat() on each component and -- if it's a symlink -- then call readlink() on it. All it uses the lstat() for is "is this a symlink". Umm, readlink() will tell you that, more cheaply! Just call readlink() directly and if it returns EINVAL then its not a symlink. Diff below makes this change for both libc and dl_realpath inside ld.so ok? Philip Guenther Index: lib/libc/stdlib/realpath.c === RCS file: /data/src/openbsd/src/lib/libc/stdlib/realpath.c,v retrieving revision 1.20 diff -u -p -r1.20 realpath.c --- lib/libc/stdlib/realpath.c 13 Oct 2015 20:55:37 - 1.20 +++ lib/libc/stdlib/realpath.c 28 Aug 2016 00:08:20 - @@ -27,8 +27,6 @@ * SUCH DAMAGE. */ -#include - #include #include #include @@ -47,7 +45,6 @@ char * realpath(const char *path, char *resolved) { - struct stat sb; char *p, *q, *s; size_t left_len, resolved_len; unsigned symlinks; @@ -148,21 +145,27 @@ realpath(const char *path, char *resolve errno = ENAMETOOLONG; goto err; } - if (lstat(resolved, &sb) != 0) { - if (errno == ENOENT && p == NULL) { - errno = serrno; - return (resolved); + slen = readlink(resolved, symlink, sizeof(symlink) - 1); + if (slen < 0) { + switch (errno) { + case EINVAL: + /* not a symlink, continue to next component */ + continue; + case ENOENT: + if (p == NULL) { + errno = serrno; + return (resolved); + } + /* FALLTHROUGH */ + default: + goto err; } - goto err; - } - if (S_ISLNK(sb.st_mode)) { + } else { if (symlinks++ > SYMLOOP_MAX) { errno = ELOOP; goto err; } - slen = readlink(resolved, symlink, sizeof(symlink) - 1); - if (slen < 0) - goto err; + symlink[slen] = '\0'; if (symlink[0] == '/') { resolved[1] = 0; Index: libexec/ld.so/dl_realpath.c === RCS file: /data/src/openbsd/src/libexec/ld.so/dl_realpath.c,v retrieving revision 1.3 diff -u -p -r1.3 dl_realpath.c --- libexec/ld.so/dl_realpath.c 19 Oct 2014 03:56:28 - 1.3 +++ libexec/ld.so/dl_realpath.c 28 Aug 2016 00:37:22 - @@ -28,11 +28,10 @@ */ #include +#include #include #include "archdep.h" -#define ENOENT -2 - /* * This file was copied from libc/stdlib/realpath.c and modified for ld.so's * syscall method which returns -errno. @@ -48,12 +47,11 @@ char * _dl_realpath(const char *path, char *resolved) { - struct stat sb; const char *p, *s; char *q; size_t left_len, resolved_len; unsigned symlinks; - int slen, mem_allocated, ret; + int slen, mem_allocated; char left[PATH_MAX], next_token[PATH_MAX], symlink[PATH_MAX]; if (path[0] == '\0') { @@ -135,27 +133,33 @@ _dl_realpath(const char *path, char *res } /* -* Append the next path component and lstat() it. If -* lstat() fails we still can return successfully if -* there are no more path components left. +* Append the next path component and readlink() it. If +* readlink() fails we still can return successfully if +* it wasn't a exists but isn't a symlink, or if there +* are no more path components left. */ resolved_len = _dl_strlcat(resolved, next_token, PATH_MAX); if (resolved_len >= PATH_MAX) { goto err; } - if ((ret = _dl_lstat(resolved, &sb)) != 0) { - if (ret == ENOENT && p == NULL) { - return (resolved); + slen = _dl_readlink(resolved, symlink, sizeof(symlink) - 1); + if (slen < 0) { + switch (slen) { + case -EINVAL: + /* not a symlink, continue to next component */ + continue; + case -ENOENT: + if (p == NULL) +
Re: Licensing into base using multiple languages, C and Perl
On Sat, Aug 27, 2016 at 08:31:02PM +0200, Ingo Schwarze wrote: > Hi Chris, > > i'm not sure that i understand all your questions, but i'm trying > to answer as best i can. > > Chris Bennett wrote on Sat, Aug 27, 2016 at 12:00:29PM -0500: > > > I'd like some help understanding how the policy works with actually > > having something acceptable to being included into base vs. needing to > > be a port. > > Some code essentially has only one way to write it and I see it all over > > the place. Calling a variable with another name doesn't seem at all like > > original code to me. > > Copyright doesn't apply to single lines, even less to single words. > It applies to "works". > > https://en.wikipedia.org/wiki/Copyright#Eligible_works > > So, if you somehow get to look at some proprietary software and > like some variable name, you are free to use the same name in your > own software from the Copyright point of view (of course, if the > code belongs to your employer, your working contract might forbid > that you use information obtained at work privately, but that has > nothing to do with Copyright). > > > There is code in base written in Perl that is new code. > > Base Perl changes adds and removes modules over time, like CGI being > > removed. > > For example, using a base Perl module might be a problem if it is > > updated and removed to CPAN with a license change. Bang! Problem. > > OpenBSD base includes many modules that are from CPAN and not > from Perl base. When these are updated, we check that the license > is still OK. In practice, that's hardly ever a problem because > most stuff in CPAN is published under the Perl Artistic license, > which allows inclusion into OpenBSD. > > > Also, there is existing code that I never ever look at, but I write > > essentially the same code myself independently. How does that effect > > things? > > Doesn't matter: > > https://en.wikipedia.org/wiki/Copyright#Originality > > "Two authors may own copyright on two substantially identical >works, if it is determined that the duplication was coincidental, >and neither was copied from the other." > > In practice, that's rare, because Copyright applies to works, not > to lines or words, and chances that a complete work (e.g. software > program) is identically written by two people independent of each > other are very low. There is a famous story, though, where in early > UNIX development, even though Ken Thompson and Dennis Richie usually > knew where each other was working and kept their areas of work > separate, both did write exactly the same program. It was such a > rare event that people still marvel at it. > > > There are also many modules on CPAN that use the same license as Perl > > itself. Can I bring the code itself only into the project, not the > > module so that only that version is used? > > Yes. The Perl Artistic license allows creation of derivative works. > So you can take parts from programs and modules and create and > distribute modified versions, as long as you keep the original > Copyright notice and license, make it clear what you changed, > and distribute the changed files as free software - for details, > see the file "Artistic". > > > There are also bits of code that are very restrictively licensed. > > Do I even dare look at it for ideas? > > Doesn't matter at all. Ideas are never subject to Copyright, > only the *expression* of an idea in a particular form is. > So there is no problem if you carefully study the source code > of a program, then write your own program doing exactly the same, > as long as you don't copy code in the process. > > Of course, the Copyright holder of the program might sue you, > claiming that you *did* copy stuff, and if that person or company > is rich, such a lawsuit might be very inconvenient. For that > reason, people who are exceptionally prudent sometimes use > > https://en.wikipedia.org/wiki/Clean_room_design > > in particular when dealing with commercial code coming from > corporations who are notorious for sueing. > Thanks, this is very helpful. Having a third party write a specification to work toward is not a step I was aware of as being helpful legally. Suing seems to be very popular these days. I don't want either myself or OpenBSD to have any problems of this kind. Despite having seen it mentioned with the big companies suing over patents, I didn't even think of that pitfall. I have so far made sure to not look at any code (except in some books about programming) which did not have a suitable license for derivative use. > I'm not a lawyer, this is merely how i understand that stuff. > I won't pay you damages if you rely on this and something goes > wrong, the responsibility for what you do is yours. When in > doubt, ask a lawyer. Yes, sounds almost like writing anything that could be construed as copying could be problematical. Sounds like so far distancing myself from actual code examination has been the right
Re: Licensing into base using multiple languages, C and Perl
Hi Chris, i'm not sure that i understand all your questions, but i'm trying to answer as best i can. Chris Bennett wrote on Sat, Aug 27, 2016 at 12:00:29PM -0500: > I'd like some help understanding how the policy works with actually > having something acceptable to being included into base vs. needing to > be a port. > Some code essentially has only one way to write it and I see it all over > the place. Calling a variable with another name doesn't seem at all like > original code to me. Copyright doesn't apply to single lines, even less to single words. It applies to "works". https://en.wikipedia.org/wiki/Copyright#Eligible_works So, if you somehow get to look at some proprietary software and like some variable name, you are free to use the same name in your own software from the Copyright point of view (of course, if the code belongs to your employer, your working contract might forbid that you use information obtained at work privately, but that has nothing to do with Copyright). > There is code in base written in Perl that is new code. > Base Perl changes adds and removes modules over time, like CGI being > removed. > For example, using a base Perl module might be a problem if it is > updated and removed to CPAN with a license change. Bang! Problem. OpenBSD base includes many modules that are from CPAN and not from Perl base. When these are updated, we check that the license is still OK. In practice, that's hardly ever a problem because most stuff in CPAN is published under the Perl Artistic license, which allows inclusion into OpenBSD. > Also, there is existing code that I never ever look at, but I write > essentially the same code myself independently. How does that effect > things? Doesn't matter: https://en.wikipedia.org/wiki/Copyright#Originality "Two authors may own copyright on two substantially identical works, if it is determined that the duplication was coincidental, and neither was copied from the other." In practice, that's rare, because Copyright applies to works, not to lines or words, and chances that a complete work (e.g. software program) is identically written by two people independent of each other are very low. There is a famous story, though, where in early UNIX development, even though Ken Thompson and Dennis Richie usually knew where each other was working and kept their areas of work separate, both did write exactly the same program. It was such a rare event that people still marvel at it. > There are also many modules on CPAN that use the same license as Perl > itself. Can I bring the code itself only into the project, not the > module so that only that version is used? Yes. The Perl Artistic license allows creation of derivative works. So you can take parts from programs and modules and create and distribute modified versions, as long as you keep the original Copyright notice and license, make it clear what you changed, and distribute the changed files as free software - for details, see the file "Artistic". > There are also bits of code that are very restrictively licensed. > Do I even dare look at it for ideas? Doesn't matter at all. Ideas are never subject to Copyright, only the *expression* of an idea in a particular form is. So there is no problem if you carefully study the source code of a program, then write your own program doing exactly the same, as long as you don't copy code in the process. Of course, the Copyright holder of the program might sue you, claiming that you *did* copy stuff, and if that person or company is rich, such a lawsuit might be very inconvenient. For that reason, people who are exceptionally prudent sometimes use https://en.wikipedia.org/wiki/Clean_room_design in particular when dealing with commercial code coming from corporations who are notorious for sueing. I'm not a lawyer, this is merely how i understand that stuff. I won't pay you damages if you rely on this and something goes wrong, the responsibility for what you do is yours. When in doubt, ask a lawyer. Yours, Ingo
Re: use strnlen() in vfprintf.c
On Sat, Aug 27, 2016 at 07:34:53PM +0200, Ingo Schwarze wrote: > Hi Todd, > > Todd C. Miller wrote on Sat, Aug 27, 2016 at 10:28:14AM -0600: > > > Now that we have a handy size_t scratch variable, > > we can use it to store the return value of mbrtowc() > > instead of storing it in an int. Worth it or overkill? > > Some interfaces are specifically designed to trap the unwary. > That includes mb[r]towc(3), in multiple respects. When dealing with > such trapful interfaces, paying extra attention to careful idiomatics > helps auditing and ultimately catching and avoiding some of the > unavoidable errors. Hence, worth it. > > OK schwarze@ > Ingo I agree. OK by me as well. > > Index: lib/libc/stdio/vfprintf.c > > === > > RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v > > retrieving revision 1.76 > > diff -u -p -u -r1.76 vfprintf.c > > --- lib/libc/stdio/vfprintf.c 27 Aug 2016 16:10:40 - 1.76 > > +++ lib/libc/stdio/vfprintf.c 27 Aug 2016 16:26:04 - > > @@ -489,17 +489,17 @@ __vfprintf(FILE *fp, const char *fmt0, _ > > size_t len; > > > > cp = fmt; > > - while ((n = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) > 0) { > > - fmt += n; > > + while ((len = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) != 0) { > > + if (len == (size_t)-1 || len == (size_t)-2) { > > + ret = -1; > > + goto error; > > + } > > + fmt += len; > > if (wc == '%') { > > fmt--; > > break; > > } > > } > > - if (n < 0) { > > - ret = -1; > > - goto error; > > - } > > if (fmt != cp) { > > ptrdiff_t m = fmt - cp; > > if (m < 0 || m > INT_MAX - ret) > > @@ -507,7 +507,7 @@ __vfprintf(FILE *fp, const char *fmt0, _ > > PRINT(cp, m); > > ret += m; > > } > > - if (n == 0) > > + if (len == 0) > > goto done; > > fmt++; /* skip over '%' */ > > > > @@ -1217,17 +1217,19 @@ __find_arguments(const char *fmt0, va_li > > * Scan the format for conversions (`%' character). > > */ > > for (;;) { > > + size_t len; > > + > > cp = fmt; > > - while ((n = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) > 0) { > > - fmt += n; > > + while ((len = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) != 0) { > > + if (len == (size_t)-1 || len == (size_t)-2) > > + return (-1); > > + fmt += len; > > if (wc == '%') { > > fmt--; > > break; > > } > > } > > - if (n < 0) > > - return (-1); > > - if (n == 0) > > + if (len == 0) > > goto done; > > fmt++; /* skip over '%' */ > > >
Re: use strnlen() in vfprintf.c
Hi Todd, Todd C. Miller wrote on Sat, Aug 27, 2016 at 10:28:14AM -0600: > Now that we have a handy size_t scratch variable, > we can use it to store the return value of mbrtowc() > instead of storing it in an int. Worth it or overkill? Some interfaces are specifically designed to trap the unwary. That includes mb[r]towc(3), in multiple respects. When dealing with such trapful interfaces, paying extra attention to careful idiomatics helps auditing and ultimately catching and avoiding some of the unavoidable errors. Hence, worth it. OK schwarze@ Ingo > Index: lib/libc/stdio/vfprintf.c > === > RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v > retrieving revision 1.76 > diff -u -p -u -r1.76 vfprintf.c > --- lib/libc/stdio/vfprintf.c 27 Aug 2016 16:10:40 - 1.76 > +++ lib/libc/stdio/vfprintf.c 27 Aug 2016 16:26:04 - > @@ -489,17 +489,17 @@ __vfprintf(FILE *fp, const char *fmt0, _ > size_t len; > > cp = fmt; > - while ((n = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) > 0) { > - fmt += n; > + while ((len = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) != 0) { > + if (len == (size_t)-1 || len == (size_t)-2) { > + ret = -1; > + goto error; > + } > + fmt += len; > if (wc == '%') { > fmt--; > break; > } > } > - if (n < 0) { > - ret = -1; > - goto error; > - } > if (fmt != cp) { > ptrdiff_t m = fmt - cp; > if (m < 0 || m > INT_MAX - ret) > @@ -507,7 +507,7 @@ __vfprintf(FILE *fp, const char *fmt0, _ > PRINT(cp, m); > ret += m; > } > - if (n == 0) > + if (len == 0) > goto done; > fmt++; /* skip over '%' */ > > @@ -1217,17 +1217,19 @@ __find_arguments(const char *fmt0, va_li >* Scan the format for conversions (`%' character). >*/ > for (;;) { > + size_t len; > + > cp = fmt; > - while ((n = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) > 0) { > - fmt += n; > + while ((len = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) != 0) { > + if (len == (size_t)-1 || len == (size_t)-2) > + return (-1); > + fmt += len; > if (wc == '%') { > fmt--; > break; > } > } > - if (n < 0) > - return (-1); > - if (n == 0) > + if (len == 0) > goto done; > fmt++; /* skip over '%' */ >
Licensing into base using multiple languages, C and Perl
I'd like some help understanding how the policy works with actually having something acceptable to being included into base vs. needing to be a port. Some code essentially has only one way to write it and I see it all over the place. Calling a variable with another name doesn't seem at all like original code to me. There is code in base written in Perl that is new code. Base Perl changes adds and removes modules over time, like CGI being removed. For example, using a base Perl module might be a problem if it is updated and removed to CPAN with a license change. Bang! Problem. Also, there is existing code that I never ever look at, but I write essentially the same code myself independently. How does that effect things? There are also many modules on CPAN that use the same license as Perl itself. Can I bring the code itself only into the project, not the module so that only that version is used? There are also bits of code that are very restrictively licensed. Do I even dare look at it for ideas? Thanks, Chris Bennett
Re: use strnlen() in vfprintf.c
On Sat, 27 Aug 2016 12:12:02 +0200, Ingo Schwarze wrote: > However, in the case at hand, it really helps readability > in a function (unavoidably) already longer than comfortable > for reading it. Now that we have a handy size_t scratch variable, we can use it to store the return value of mbrtowc() instead of storing it in an int. Worth it or overkill? - todd Index: lib/libc/stdio/vfprintf.c === RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v retrieving revision 1.76 diff -u -p -u -r1.76 vfprintf.c --- lib/libc/stdio/vfprintf.c 27 Aug 2016 16:10:40 - 1.76 +++ lib/libc/stdio/vfprintf.c 27 Aug 2016 16:26:04 - @@ -489,17 +489,17 @@ __vfprintf(FILE *fp, const char *fmt0, _ size_t len; cp = fmt; - while ((n = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) > 0) { - fmt += n; + while ((len = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) != 0) { + if (len == (size_t)-1 || len == (size_t)-2) { + ret = -1; + goto error; + } + fmt += len; if (wc == '%') { fmt--; break; } } - if (n < 0) { - ret = -1; - goto error; - } if (fmt != cp) { ptrdiff_t m = fmt - cp; if (m < 0 || m > INT_MAX - ret) @@ -507,7 +507,7 @@ __vfprintf(FILE *fp, const char *fmt0, _ PRINT(cp, m); ret += m; } - if (n == 0) + if (len == 0) goto done; fmt++; /* skip over '%' */ @@ -1217,17 +1217,19 @@ __find_arguments(const char *fmt0, va_li * Scan the format for conversions (`%' character). */ for (;;) { + size_t len; + cp = fmt; - while ((n = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) > 0) { - fmt += n; + while ((len = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) != 0) { + if (len == (size_t)-1 || len == (size_t)-2) + return (-1); + fmt += len; if (wc == '%') { fmt--; break; } } - if (n < 0) - return (-1); - if (n == 0) + if (len == 0) goto done; fmt++; /* skip over '%' */
Re: use strnlen() in vfprintf.c
> in 2014, Theo scolded me when i tried to use strnlen(3) at some > place in mandoc where it wasn't really important, pointing out that > some systems still didn't have it, and saying: "Let me say simply: > Yuck." And indeed, i promptly got reports about compile failures > on Solaris. Right. > However, in the case at hand, it really helps readability > in a function (unavoidably) already longer than comfortable > for reading it. And it is internal use.
disklabel,fsck_ffs: division by zero on invalid frag sizes
Illegal fragmentation block sizes can trigger division by zero in the disklabel and fsck_ffs tools. See this sequence of commands to reproduce: # dd if=/dev/zero of=nofrag.iso bs=1M count=1 # vnconfig vnd0 nofrag.iso # disklabel -e vnd0 # create 'a' and set fsize = bsize = 1 # fsck_ffs vnd0a ** /dev/vnd0a (vnd0a) BAD SUPER BLOCK: MAGIC NUMBER WRONG Floating point exception (core dumped) # disklabel -E vnd0 Label editor (enter '?' for help at any prompt) > m a offset: [0] size: [2048] FS type: [4.2BSD] Floating point exception (core dumped) # vnconfig -u vnd0 A fragmentation (block) size smaller than a sector size is not valid while using "disklabel -E", and really doesn't make sense. While using "disklabel -e", not all validation checks are performed, which makes it possible to enter invalid values. If "disklabel -E" is used without the expert mode, fragmentation sizes cannot be changed and will be just accepted from the parsed disklabel, resulting in a division by zero if they are too small. And the same happens in fsck_ffs. Instead of coming up with a guessed value in fsck_ffs, I think it's better to simply fail and let the user fix the disklabel. After all, it shouldn't be fsck_ffs's duty to fix faulty values outside the filesystem. Index: sbin/disklabel/disklabel.c === RCS file: /cvs/src/sbin/disklabel/disklabel.c,v retrieving revision 1.222 diff -u -p -u -p -r1.222 disklabel.c --- sbin/disklabel/disklabel.c 19 Jun 2016 13:42:56 - 1.222 +++ sbin/disklabel/disklabel.c 27 Aug 2016 13:30:38 - @@ -1096,9 +1096,24 @@ getasciilabel(FILE *f, struct disklabel case FS_BSDFFS: NXTNUM(fsize, fsize, &errstr); - if (fsize == 0) + if (fsize < lp->d_secsize || + (fsize % lp->d_secsize) != 0) { + warnx("line %d: " + "bad fragmentation size: %s", + lineno, cp); + errors++; break; + } NXTNUM(v, v, &errstr); + if (v < fsize || (fsize != v && + fsize * 2 != v && fsize * 4 != v && + fsize * 8 != v)) { + warnx("line %d: " + "bad block size: %s", + lineno, cp); + errors++; + break; + } pp->p_fragblock = DISKLABELV1_FFS_FRAGBLOCK(fsize, v / fsize); NXTNUM(pp->p_cpg, pp->p_cpg, &errstr); Index: sbin/disklabel/editor.c === RCS file: /cvs/src/sbin/disklabel/editor.c,v retrieving revision 1.301 diff -u -p -u -p -r1.301 editor.c --- sbin/disklabel/editor.c 19 Aug 2016 08:06:25 - 1.301 +++ sbin/disklabel/editor.c 27 Aug 2016 13:30:39 - @@ -2024,16 +2024,16 @@ get_bsize(struct disklabel *lp, int part if (pp->p_fstype != FS_BSDFFS) return (0); + frag = DISKLABELV1_FFS_FRAG(pp->p_fragblock); + fsize = DISKLABELV1_FFS_FSIZE(pp->p_fragblock); + /* Avoid dividing by zero... */ - if (pp->p_fragblock == 0) - return(1); + if (frag * fsize < lp->d_secsize) + return (1); if (!expert) goto align; - fsize = DISKLABELV1_FFS_FSIZE(pp->p_fragblock); - frag = DISKLABELV1_FFS_FRAG(pp->p_fragblock); - for (;;) { ui = getuint64(lp, "block size", "Size of ffs blocks. 1, 2, 4 or 8 times ffs fragment size.", @@ -2074,8 +2074,7 @@ align: orig_size = DL_GETPSIZE(pp); orig_offset = DL_GETPOFFSET(pp); - bsize = (DISKLABELV1_FFS_FRAG(pp->p_fragblock) * - DISKLABELV1_FFS_FSIZE(pp->p_fragblock)) / lp->d_secsize; + bsize = (frag * fsize) / lp->d_secsize; if (DL_GETPOFFSET(pp) != starting_sector) { /* Can't change offset of first partition. */ adj = bsize - (DL_GETPOFFSET(pp) % bsize); Index: sbin/fsck_ffs/setup.c === RCS file: /cvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.61 diff -u -p -u -p -r1.61 setup.c --- sbin/fsck_ffs/setup.c 20 Aug 2016 15:04:21 - 1.61 +++ sbin/fsck_ffs/setup.c 27 Aug 2016 13:30:39 - @@ -625,6 +625,10 @@ calcsb(char *dev, int devfd, struct fs * fs->fs_fsize = DISKLABELV1_FFS_FSIZE(pp->p
Re: Amend history & authors info in bin/expr/expr.1
Hi Sevan, Sevan Janiyan Solaris wrote on Wed, Aug 24, 2016 at 01:35:38AM +0100: > Index: bin/expr/expr.1 > === > RCS file: /cvs/src/bin/expr/expr.1,v > retrieving revision 1.23 > diff -u -p -u -r1.23 expr.1 > --- bin/expr/expr.1 16 Jan 2015 15:30:10 - 1.23 > +++ bin/expr/expr.1 24 Aug 2016 00:29:29 - > @@ -142,15 +142,15 @@ The > utility first appeared in the Programmer's Workbench (PWB/UNIX) > and has supported regular expressions since > .At v7 . > -It was rewritten from scratch for > +A public domain version was rewritten from scratch for > .Bx 386 0.1 We don't usually explain the history of licensing unless it is exceptionally important or unusual. It goes without saying that something that appeared in PWB was usually proprietary, while stuff that made it into 4.4BSD-Lite2 and/or NetBSD was almost certainly free software. The distinction of BSD vs. PD doesn't matter enough to encumber HISTORY with it. > -and again for > -.Nx 1.1 . > +and largely again for > +.Nx 1.0 . While both are true, i don't think it is important enough to mention the earlier one of these two rewrites in OpenBSD given that it lived less than a year before being superseded again. > .Sh AUTHORS > .An -nosplit > -The first free version was written by > +The public domain version was written by > .An Pace Willisson > in 1992. Again, not important enough to change it. > -This version was written by > +It was largely rewritten by > .An John T. Conklin > -in 1994. > +in 1993. That's outright misleading. OpenBSD uses Conklin's NetBSD 1.1 version (written in C in 1994). NetBSD uses jdolecek@'s NetBSD 1.6 version (written in yacc(1) in 2000). Neither uses Conklin's NetBSD 1.0 version (written in yacc(1) in 1993). http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/expr/Attic/expr.c Yours, Ingo
Re: Enable Camellia ciphers with SHA-2 family HMAC
On 08/27/16 12:32, Guenther Niess wrote: ... Or do you think we should change + .algo_strength = SSL_HIGH, to + .algo_strength = SSL_MEDIUM, this matter seems to be highly subjective. I personally don't like and don't make use of the LOW/MEDIUM/HIGH keywords for configuring TLS cipher suites in web servers. RFC 7525 might be a reasonably good baseline - however, it essentially provides minimum recommendations which are not necessarily the recommended choice for HIGH in my opinion. Due to its blocklength of 64 bits, 3DES should probably be removed from HIGH due Sweet32 attack (see https://sweet32.info/ ). I personally would not list any CBC-based cipher suites as HIGH since TLS uses them in mac-then-encrypt fashion which is generally considered to be less robust by most cryptographers. Encrypt-then-mac is only available via TLS extension (RFC 7366). However, in case a TLS library actually supports this extension, it typically already provides support for AEAD cipher suites. CBC-based cipher suites are mostly required for interoperability with oder TLS client but should HIGH be tailored for interoperability? Slightly unrelated: OpenSSL 1.1.0 has added support for ecdh_x25519 and seems to have made it its new default over NIST P-256 (https://www.openssl.org/news/changelog.html#x0). This might also be a nice addition to LibreSSL.
replace struct vattr with struct stat in fusebuf
In struct fusebuf the attributes (used for getattr/setattr and to return the ino/mode of a newly created file) are stored in a struct vattr. The problem with this is, that using struct vattr in userspace is suboptimal as some related helpers are not available, e.g. VATTR_NULL() and IFTOVT(). What happens on getattr is this: fusefs requests the attributes for a file from the userland process. libfuse calls the getattr fuse operation, which fills in a struct stat. This struct is than converted to a partial struct vattr, which is passed back to the kernel where "fixup" takes place. Following diff simplifies that process by replacing the struct vattr in fusebuf with a struct stat. The conversion is moved to the kernel where it belongs. As a side effect the include can be removed from libfuse. Ok? Objections? natano Index: lib/libfuse/fuse_ops.c === RCS file: /cvs/src/lib/libfuse/fuse_ops.c,v retrieving revision 1.24 diff -u -p -r1.24 fuse_ops.c --- lib/libfuse/fuse_ops.c 5 Feb 2014 20:13:58 - 1.24 +++ lib/libfuse/fuse_ops.c 22 Aug 2016 20:53:46 - @@ -30,53 +30,30 @@ return (0); \ } -static void -stat2attr(struct vattr *v, struct stat *st) -{ - v->va_fileid = st->st_ino; - v->va_bytes = st->st_blocks; - v->va_mode = st->st_mode; - v->va_nlink = st->st_nlink; - v->va_uid = st->st_uid; - v->va_gid = st->st_gid; - v->va_rdev = st->st_rdev; - v->va_size = st->st_size; - v->va_blocksize = st->st_blksize; - v->va_atime.tv_sec = st->st_atime; - v->va_atime.tv_nsec = st->st_atimensec; - v->va_mtime.tv_sec = st->st_mtime; - v->va_mtime.tv_nsec = st->st_mtimensec; - v->va_ctime.tv_sec = st->st_ctime; - v->va_ctime.tv_nsec = st->st_ctimensec; -} - static int -update_vattr(struct fuse *f, struct vattr *attr, const char *realname, +update_attr(struct fuse *f, struct stat *attr, const char *realname, struct fuse_vnode *vn) { - struct stat st; int ret; - bzero(&st, sizeof(st)); - ret = f->op.getattr(realname, &st); + memset(attr, 0, sizeof(struct stat)); + ret = f->op.getattr(realname, attr); - if (st.st_blksize == 0) - st.st_blksize = 512; - if (st.st_blocks == 0) - st.st_blocks = 4; + if (attr->st_blksize == 0) + attr->st_blksize = 512; + if (attr->st_blocks == 0) + attr->st_blocks = 4; - st.st_ino = vn->ino; + attr->st_ino = vn->ino; if (f->conf.set_mode) - st.st_mode = (st.st_mode & S_IFMT) | (0777 & ~f->conf.umask); + attr->st_mode = (attr->st_mode & S_IFMT) | (0777 & ~f->conf.umask); if (f->conf.set_uid) - st.st_uid = f->conf.uid; + attr->st_uid = f->conf.uid; if (f->conf.set_gid) - st.st_gid = f->conf.gid; - - stat2attr(attr, &st); + attr->st_gid = f->conf.gid; return (ret); } @@ -107,7 +84,7 @@ ifuse_ops_getattr(struct fuse *f, struct DPRINTF("Opcode:\tgetattr\n"); DPRINTF("Inode:\t%llu\n", (unsigned long long)fbuf->fb_ino); - bzero(&fbuf->fb_vattr, sizeof(fbuf->fb_vattr)); + memset(&fbuf->fb_attr, 0, sizeof(struct stat)); vn = tree_get(&f->vnode_tree, fbuf->fb_ino); if (vn == NULL) { @@ -121,7 +98,7 @@ ifuse_ops_getattr(struct fuse *f, struct return (0); } - fbuf->fb_err = update_vattr(f, &fbuf->fb_vattr, realname, vn); + fbuf->fb_err = update_attr(f, &fbuf->fb_attr, realname, vn); free(realname); return (0); @@ -474,7 +451,7 @@ ifuse_ops_lookup(struct fuse *f, struct return (0); } - fbuf->fb_err = update_vattr(f, &fbuf->fb_vattr, realname, vn); + fbuf->fb_err = update_attr(f, &fbuf->fb_attr, realname, vn); free(fbuf->fb_dat); free(realname); @@ -614,9 +591,9 @@ ifuse_ops_create(struct fuse *f, struct fbuf->fb_err = -ENOSYS; if (!fbuf->fb_err) { - fbuf->fb_err = update_vattr(f, &fbuf->fb_vattr, realname, vn); - fbuf->fb_ino = fbuf->fb_vattr.va_fileid; - fbuf->fb_io_mode = fbuf->fb_vattr.va_mode; + fbuf->fb_err = update_attr(f, &fbuf->fb_attr, realname, vn); + fbuf->fb_ino = fbuf->fb_attr.st_ino; + fbuf->fb_io_mode = fbuf->fb_attr.st_mode; } free(realname); @@ -650,8 +627,8 @@ ifuse_ops_mkdir(struct fuse *f, struct f fbuf->fb_err = f->op.mkdir(realname, mode); if (!fbuf->fb_err) { - fbuf->fb_err = update_vattr(f, &fbuf->fb_vattr, realname, vn); - fbuf->fb_io_mode = fbuf->fb_vattr.va_mode; + fbuf->fb_err = update_attr(f, &fbuf->fb_a
Re: Enable Camellia ciphers with SHA-2 family HMAC
On 08/26/2016 12:44 AM, Bob Beck wrote: > On Thursday, 25 August 2016, Ted Unangst wrote: >> Andreas Bartelt wrote: >>> On 08/25/16 15:58, Brent Cook wrote: No objection here. Anyone else? >>> >>> in general, I personally would only add further cryptographic primitives >>> to a TLS configuration in case they provide sufficiently distinctive >>> advantages over the already available primitives. I don't see this for >>> Camellia since it doesn't seem to provide any better trade-offs than >>> AES. Or am I missing something here? >> >> Oh, I don't think we should add this to any default config. But the option >> should be available for users to configure. >> > > yes on both counts > Just for clarification this means the patch is ok? Or do you think we should change > + .algo_strength = SSL_HIGH, to + .algo_strength = SSL_MEDIUM, for the cipher suits to reflect that the implementation didn't have the same support like DES CBC3, GOST, AES or ChaCha20? I am now starting with Camellia GCM suits.
Re: Estonian keymap
Would this be ok for inclusion in the next release? On Sat, Aug 27, 2016 at 7:27 AM, Mart Tõnso wrote: > Updated Estonian keymap patch for current. Original from 2005 at > http://marc.info/?l=openbsd-tech&m=112873075504474 > > > Index: sys/dev/pckbc/wskbdmap_mfii.c > === > RCS file: /cvs/src/sys/dev/pckbc/wskbdmap_mfii.c,v > retrieving revision 1.43 > diff -u -p -u -r1.43 wskbdmap_mfii.c > --- sys/dev/pckbc/wskbdmap_mfii.c 14 Apr 2013 19:32:52 - 1.43 > +++ sys/dev/pckbc/wskbdmap_mfii.c 26 Aug 2016 19:32:22 - > @@ -1071,6 +1071,40 @@ static const keysym_t pckbd_keydesc_is_n > KC(40), KS_acute, KS_diaeresis, KS_asciicircum, > }; > > +static const keysym_t pckbd_keydesc_ee[] = { > +/* pos normal shifted altgr shift-altgr */ > +KC(3), KS_2, KS_quotedbl, KS_at, > +KC(4), KS_3, KS_numbersign, KS_sterling, > +KC(5), KS_4, KS_currency, KS_dollar, > +KC(7), KS_6, KS_ampersand, > +KC(8), KS_7, KS_slash, KS_braceleft, > +KC(9), KS_8, KS_parenleft, KS_bracketleft, > +KC(10), KS_9, KS_parenright, KS_bracketright, > +KC(11), KS_0, KS_equal, KS_braceright, > +KC(12), KS_plus, KS_question, KS_backslash, > +KC(13), KS_dead_acute, KS_dead_grave, > +KC(26), KS_udiaeresis, > +KC(27), KS_otilde, KS_Otilde, KS_section, > +KC(31), KS_s, KS_S, KS_L2_scaron, KS_L2_Scaron, > +KC(39), KS_odiaeresis, > +KC(40), KS_adiaeresis, KS_Adiaeresis, KS_dead_circumflex, > +KC(41), KS_dead_caron, KS_dead_tilde, > +KC(43), KS_apostrophe, KS_asterisk, KS_onehalf, > +KC(44), KS_z, KS_Z, KS_L2_zcaron, KS_L2_Zcaron, > +KC(51), KS_comma, KS_semicolon, > +KC(52), KS_period, KS_colon, > +KC(53), KS_minus, KS_underscore, > +KC(86), KS_less, KS_greater, KS_bar, KS_brokenbar, > +KC(184), KS_Mode_switch, KS_Multi_key, > +}; > + > +static const keysym_t pckbd_keydesc_ee_nodead[] = { > +/* pos normal shifted altgr shift-altgr */ > +KC(13), KS_apostrophe, KS_grave, > +KC(40), KS_adiaeresis, KS_Adiaeresis, KS_asciicircum, > +KC(41), KS_L2_caron, KS_asciitilde, > +}; > + > #endif /* WSKBD_NO_INTL_LAYOUTS */ > > #define KBD_MAP(name, base, map) \ > @@ -1130,6 +1164,8 @@ const struct wscons_keydesc pckbd_keydes > KBD_MAP(KB_NL | KB_NODEAD, KB_NL, pckbd_keydesc_nl_nodead), > KBD_MAP(KB_IS, KB_US, pckbd_keydesc_is), > KBD_MAP(KB_IS | KB_NODEAD, KB_IS, pckbd_keydesc_is_nodead), > + KBD_MAP(KB_EE, KB_US, pckbd_keydesc_ee), > + KBD_MAP(KB_EE | KB_NODEAD, KB_EE, pckbd_keydesc_ee_nodead), > #endif /* WSKBD_NO_INTL_LAYOUTS */ > {0, 0, 0, 0} > }; > Index: sys/dev/wscons/wskbdutil.c > === > RCS file: /cvs/src/sys/dev/wscons/wskbdutil.c,v > retrieving revision 1.14 > diff -u -p -u -r1.14 wskbdutil.c > --- sys/dev/wscons/wskbdutil.c 9 Dec 2014 07:05:06 - 1.14 > +++ sys/dev/wscons/wskbdutil.c 26 Aug 2016 19:32:22 - > @@ -170,7 +170,12 @@ static struct compose_tab_s { > { { KS_acute, KS_u }, KS_uacute }, > { { KS_asciicircum, KS_u }, KS_ucircumflex }, > { { KS_grave, KS_u }, KS_ugrave }, > - { { KS_acute, KS_y }, KS_yacute } > + { { KS_acute, KS_y }, KS_yacute }, > + { { KS_dead_caron, KS_space }, KS_L2_caron }, > + { { KS_dead_caron, KS_S }, KS_L2_Scaron }, > + { { KS_dead_caron, KS_Z }, KS_L2_Zcaron }, > + { { KS_dead_caron, KS_s }, KS_L2_scaron }, > + { { KS_dead_caron, KS_z }, KS_L2_zcaron } > }; > > #define COMPOSE_SIZE nitems(compose_tab) > Index: sys/dev/wscons/wsksymdef.h > === > RCS file: /cvs/src/sys/dev/wscons/wsksymdef.h,v > retrieving revision 1.36 > diff -u -p -u -r1.36 wsksymdef.h > --- sys/dev/wscons/wsksymdef.h 26 Jan 2014 17:48:08 - 1.36 > +++ sys/dev/wscons/wsksymdef.h 26 Aug 2016 19:32:22 - > @@ -266,6 +266,7 @@ > #define KS_dead_diaeresis 0x0308 > #define KS_dead_abovering 0x030a > #define KS_dead_cedilla 0x0327 > +#define KS_dead_caron 0x0328 > > /* > * Group Cyrillic > @@ -734,6 +735,7 @@ > #define KB_CF 0x1a00 > #define KB_LV 0x1b00 > #define KB_IS 0x1c00 > +#define KB_EE 0x1d00 > > #define KB_NODEAD 0x0001 /* disable dead accents */ > #define KB_DECLK 0x0002 /* DEC LKnnn layout */ > @@ -774,7 +776,8 @@ > { KB_SI, "si" }, \ > { KB_CF, "cf" }, \ > { KB_LV, "lv" }, \ > - { KB_IS, "is" } > + { KB_IS, "is" }, \ > + { KB_EE, "ee" } > > #define KB_VARTAB \ > { KB_NODEAD, "nodead" }, \
Re: use strnlen() in vfprintf.c
Hi Todd, in 2014, Theo scolded me when i tried to use strnlen(3) at some place in mandoc where it wasn't really important, pointing out that some systems still didn't have it, and saying: "Let me say simply: Yuck." And indeed, i promptly got reports about compile failures on Solaris. However, in the case at hand, it really helps readability in a function (unavoidably) already longer than comfortable for reading it. So, OK schwarze@ Ingo Todd C. Miller wrote on Thu, Aug 25, 2016 at 03:43:31PM -0600: > Index: lib/libc/stdio/vfprintf.c > === > RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v > retrieving revision 1.75 > diff -u -p -u -r1.75 vfprintf.c > --- lib/libc/stdio/vfprintf.c 17 Aug 2016 22:15:08 - 1.75 > +++ lib/libc/stdio/vfprintf.c 25 Aug 2016 21:39:16 - > @@ -486,6 +486,8 @@ __vfprintf(FILE *fp, const char *fmt0, _ >* Scan the format for conversions (`%' character). >*/ > for (;;) { > + size_t len; > + > cp = fmt; > while ((n = mbrtowc(&wc, fmt, MB_CUR_MAX, &ps)) > 0) { > fmt += n; > @@ -886,22 +888,10 @@ fp_common: > > cp = "(null)"; > } > - if (prec >= 0) { > - /* > - * can't use strlen; can only look for the > - * NUL in the first `prec' characters, and > - * strlen() will go further. > - */ > - char *p = memchr(cp, 0, prec); > - > - size = p ? (p - cp) : prec; > - } else { > - size_t len; > - > - if ((len = strlen(cp)) > INT_MAX) > - goto overflow; > - size = (int)len; > - } > + len = prec >= 0 ? strnlen(cp, prec) : strlen(cp); > + if (len > INT_MAX) > + goto overflow; > + size = (int)len; > sign = '\0'; > break; > case 'U': >
Re: Add NVIDIA GTX 960M to pcidevs please
Ok, thank you so much Raf, I'll take note for the next devices. Cheers, Guille 2016-08-27 10:28 GMT+02:00 Raf Czlonka : > On Sat, Aug 27, 2016 at 08:53:57AM BST, Guillermo Bernaldo de Quiros > Maraver wrote: > > Hi, good morning, > > > > Please, could anyone add this patch? > > > > Thanks anyway > > > > Index: pcidevs > > === > > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > > retrieving revision 1.1802 > > diff -u -p -r1.1802 pcidevs > > --- pcidevs 31 Jul 2016 07:36:16 - 1.1802 > > +++ pcidevs 27 Aug 2016 07:23:17 - > > @@ -6130,6 +6130,7 @@ product NVIDIA GEFORCE940MX 0x134d GeFor > > product NVIDIA GEFORCEGTX750TI 0x1380 GeForce GTX 750 Ti > > product NVIDIA GEFORCEGTX750 0x1381 GeForce GTX 750 > > product NVIDIA GEFORCEGTX745 0x1382 GeForce GTX 745 > > +product NVIDIA GEFORCEGTX960M 0x139b GeForce GTX 960M > > > > /* Oak Technologies products */ > > product OAKTECH OTI1007 0x0107 OTI107 > > Index: pcidevs.h > > === > > RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v > > retrieving revision 1.1796 > > diff -u -p -r1.1796 pcidevs.h > > --- pcidevs.h 31 Jul 2016 07:37:04 - 1.1796 > > +++ pcidevs.h 27 Aug 2016 07:23:22 - > > @@ -6135,6 +6135,7 @@ > > #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750TI 0x1380 /* GeForce GTX 750 > Ti */ > > #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750 0x1381 /* GeForce GTX 750 */ > > #define PCI_PRODUCT_NVIDIA_GEFORCEGTX745 0x1382 /* GeForce GTX 745 */ > > +#define PCI_PRODUCT_NVIDIA_GEFORCEGTX960M 0x139B /* GeForce GTX 960M */ > ^ > Hi Guillermo, > > pcidevs.h and pcidevs_data.h files are automatically generated and > (not that it matters now), by convention, lower case is used in hex > values. > > Cheers, > > Raf > > > /* Oak Technologies products */ > > #define PCI_PRODUCT_OAKTECH_OTI1007 0x0107 /* OTI107 */ > > Index: pcidevs_data.h > > === > > RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v > > retrieving revision 1.1791 > > diff -u -p -r1.1791 pcidevs_data.h > > --- pcidevs_data.h 31 Jul 2016 07:37:04 - 1.1791 > > +++ pcidevs_data.h 27 Aug 2016 07:23:27 - > > @@ -21504,6 +21504,10 @@ static const struct pci_known_product pc > > "GeForce GTX 745", > > }, > > { > > +PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_GEFORCEGTX960M, > > +"GeForce GTX 960M", > > + }, > > + { > > PCI_VENDOR_OAKTECH, PCI_PRODUCT_OAKTECH_OTI1007, > > "OTI107", > > }, >
Re: Add NVIDIA GTX 960M to pcidevs please
On Sat, Aug 27, 2016 at 08:53:57AM BST, Guillermo Bernaldo de Quiros Maraver wrote: > Hi, good morning, > > Please, could anyone add this patch? > > Thanks anyway > > Index: pcidevs > === > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > retrieving revision 1.1802 > diff -u -p -r1.1802 pcidevs > --- pcidevs 31 Jul 2016 07:36:16 - 1.1802 > +++ pcidevs 27 Aug 2016 07:23:17 - > @@ -6130,6 +6130,7 @@ product NVIDIA GEFORCE940MX 0x134d GeFor > product NVIDIA GEFORCEGTX750TI 0x1380 GeForce GTX 750 Ti > product NVIDIA GEFORCEGTX750 0x1381 GeForce GTX 750 > product NVIDIA GEFORCEGTX745 0x1382 GeForce GTX 745 > +product NVIDIA GEFORCEGTX960M 0x139b GeForce GTX 960M > > /* Oak Technologies products */ > product OAKTECH OTI1007 0x0107 OTI107 > Index: pcidevs.h > === > RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v > retrieving revision 1.1796 > diff -u -p -r1.1796 pcidevs.h > --- pcidevs.h 31 Jul 2016 07:37:04 - 1.1796 > +++ pcidevs.h 27 Aug 2016 07:23:22 - > @@ -6135,6 +6135,7 @@ > #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750TI 0x1380 /* GeForce GTX 750 Ti */ > #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750 0x1381 /* GeForce GTX 750 */ > #define PCI_PRODUCT_NVIDIA_GEFORCEGTX745 0x1382 /* GeForce GTX 745 */ > +#define PCI_PRODUCT_NVIDIA_GEFORCEGTX960M 0x139B /* GeForce GTX 960M */ ^ Hi Guillermo, pcidevs.h and pcidevs_data.h files are automatically generated and (not that it matters now), by convention, lower case is used in hex values. Cheers, Raf > /* Oak Technologies products */ > #define PCI_PRODUCT_OAKTECH_OTI1007 0x0107 /* OTI107 */ > Index: pcidevs_data.h > === > RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v > retrieving revision 1.1791 > diff -u -p -r1.1791 pcidevs_data.h > --- pcidevs_data.h 31 Jul 2016 07:37:04 - 1.1791 > +++ pcidevs_data.h 27 Aug 2016 07:23:27 - > @@ -21504,6 +21504,10 @@ static const struct pci_known_product pc > "GeForce GTX 745", > }, > { > +PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_GEFORCEGTX960M, > +"GeForce GTX 960M", > + }, > + { > PCI_VENDOR_OAKTECH, PCI_PRODUCT_OAKTECH_OTI1007, > "OTI107", > },
Add NVIDIA GTX 960M to pcidevs please
Hi, good morning, Please, could anyone add this patch? Thanks anyway Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1802 diff -u -p -r1.1802 pcidevs --- pcidevs 31 Jul 2016 07:36:16 - 1.1802 +++ pcidevs 27 Aug 2016 07:23:17 - @@ -6130,6 +6130,7 @@ product NVIDIA GEFORCE940MX 0x134d GeFor product NVIDIA GEFORCEGTX750TI 0x1380 GeForce GTX 750 Ti product NVIDIA GEFORCEGTX750 0x1381 GeForce GTX 750 product NVIDIA GEFORCEGTX745 0x1382 GeForce GTX 745 +product NVIDIA GEFORCEGTX960M 0x139b GeForce GTX 960M /* Oak Technologies products */ product OAKTECH OTI1007 0x0107 OTI107 Index: pcidevs.h === RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v retrieving revision 1.1796 diff -u -p -r1.1796 pcidevs.h --- pcidevs.h 31 Jul 2016 07:37:04 - 1.1796 +++ pcidevs.h 27 Aug 2016 07:23:22 - @@ -6135,6 +6135,7 @@ #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750TI 0x1380 /* GeForce GTX 750 Ti */ #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750 0x1381 /* GeForce GTX 750 */ #define PCI_PRODUCT_NVIDIA_GEFORCEGTX745 0x1382 /* GeForce GTX 745 */ +#define PCI_PRODUCT_NVIDIA_GEFORCEGTX960M 0x139B /* GeForce GTX 960M */ /* Oak Technologies products */ #define PCI_PRODUCT_OAKTECH_OTI1007 0x0107 /* OTI107 */ Index: pcidevs_data.h === RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v retrieving revision 1.1791 diff -u -p -r1.1791 pcidevs_data.h --- pcidevs_data.h 31 Jul 2016 07:37:04 - 1.1791 +++ pcidevs_data.h 27 Aug 2016 07:23:27 - @@ -21504,6 +21504,10 @@ static const struct pci_known_product pc "GeForce GTX 745", }, { +PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_GEFORCEGTX960M, +"GeForce GTX 960M", + }, + { PCI_VENDOR_OAKTECH, PCI_PRODUCT_OAKTECH_OTI1007, "OTI107", },