Re: malloc in libssl/src/apps
On Sun, May 4, 2014 at 5:00 PM, Alexander Hall alexan...@beard.se wrote:
On 05/04/14 21:50, Jean-Philippe Ouellet wrote:
On Sun, May 04, 2014 at 12:17:16PM -0600, Theo de Raadt wrote:
We are going to completely ignore diffs which change multiple idioms
at once.
Okay.
That is how mistakes get made.
Yep, more true than I realized.
Here's a simpler one:
Index: apps.c
===
RCS file: /cvs/src/lib/libssl/src/apps/apps.c,v
retrieving revision 1.45
diff -u -p -r1.45 apps.c
--- apps.c 3 May 2014 16:03:54 - 1.45
+++ apps.c 4 May 2014 19:35:59 -
@@ -209,13 +209,10 @@ chopup_args(ARGS * arg, char *buf, int *
*argc = 0;
*argv = NULL;
- i = 0;
if (arg-count == 0) {
arg-count = 20;
- arg-data = (char **)malloc(sizeof(char *) * arg-count);
+ arg-data = calloc(arg-count, sizeof(char *));
}
- for (i = 0; i arg-count; i++)
- arg-data[i] = NULL;
General question; Given that NULL theoretically could be != 0, and that we
generally compare e.g. the malloc() result to NULL specifically, is this
approach acceptable?
The comparisons `NULL == 0` and `malloc() == 0` are *value* comparison.
After the statement `void **p = calloc(1, sizeof(void **));`, the
comparisons `p == NULL` and therefore `p == 0`, which are *identical*,
are not necessarily true.
Yes, to be correct you can't assume the representation is a string of
NULs, but the rest of your post is misleading.
/Alexander
Re: pppoe(4), add example for ipv6
[What I'm pointing out below looks like a mistake regardless of the
variables in scope.]
On Wed, Oct 22, 2014 at 1:40 AM, Henning Brauer
hb-openbsdt...@ml.bsws.de wrote:
* Chris Cappuccio ch...@nmedia.net [2014-10-22 01:11]:
Stuart Henderson [st...@openbsd.org] wrote:
Any comments on the diff in this?
+#ifdef INET6
+ sc-sc_sppp.pp_if.if_xflags = ~IFXF_NOINET6;
+#endif
Aside from what Stefan said, isn't this flag going to be removed
in favor of a flag that explicitly enables INET6 for interfaces?
remove yes, no need for a new one.
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.287
diff -u -p -r1.287 ifconfig.c
--- sbin/ifconfig/ifconfig.c12 Jul 2014 19:58:17 - 1.287
+++ sbin/ifconfig/ifconfig.c3 Oct 2014 12:58:22 -
@@ -148,6 +148,7 @@ voidsetiflladdr(const char *, int);
[...]
void
+addaf(const char *vname, int value)
+{
^ *v*name
+ struct if_afreq ifar;
+
+ strlcpy(ifar.ifar_name, name, sizeof(ifar.ifar_name));
^ name
+ ifar.ifar_af = value;
+ if (ioctl(s, SIOCIFAFATTACH, (caddr_t)ifar) 0)
+ warn(SIOCIFAFATTACH);
+}
+
+void
removeaf(const char *vname, int value)
{
^ *v*name
- switch (value) {
-#ifdef INET6
- case AF_INET6:
- setifxflags(vname, IFXF_NOINET6);
- setifxflags(vname, -IFXF_AUTOCONF6);
- break;
-#endif
- default:
- errx(1, removeaf not implemented for this AF);
- }
+ struct if_afreq ifar;
+
+ strlcpy(ifar.ifar_name, name, sizeof(ifar.ifar_name));
^ name
+ ifar.ifar_af = value;
+ if (ioctl(s, SIOCIFAFDETACH, (caddr_t)ifar) 0)
+ warn(SIOCIFAFDETACH);
}
Re: Mention -I option in cvs update synopsis
-l for cvs update is a boolean option that doesn't take an operand On Wed, Aug 21, 2013 at 5:38 PM, Vadim Zhukov persg...@gmail.com wrote: This adds a mention of -I name option for cvs update command in its synopsis. Okay? -- WBR, Vadim Zhukov Index: man/cvs.1 === RCS file: /cvs/src/gnu/usr.bin/cvs/man/cvs.1,v retrieving revision 1.12 diff -u -p -r1.12 cvs.1 --- man/cvs.1 3 Jun 2013 17:02:36 - 1.12 +++ man/cvs.1 21 Aug 2013 22:06:44 - @@ -1696,7 +1696,7 @@ executes recursively through subdirector using the standard \fB\-l\fP option, or specify the recursion explicitly by using \fB\-R\fP. .TP -\fBupdate\fP [\fB\-ACdf\|lPpQqR\fP] [\fB\-d\fP] [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP] \fIfiles\|.\|.\|.\fP +\fBupdate\fP [\fB\-ACdf\|lPpQqR\fP] [\fB\-d\fP] [\fB\-I\fP \fIname\fP] [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP] \fIfiles\|.\|.\|.\fP .I Requires: repository, working directory. .br
Re: Weird loop in ftp client
On Sun, Nov 24, 2013 at 12:11 PM, sven falempin sven.falem...@gmail.comwrote: On Sat, Nov 23, 2013 at 5:47 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: On 2013/11/23 14:39, sven falempin wrote: Hello, Another point of vue : Because curl is in base, what does ftp client add to the system ? ftp(1) is not without problems (bad ssl support, semi-broken proxy support, difficult code) but it has one major advantage: the small version used on ramdisks is quite small, something like 80k. cURL is not in base, but even if it was, it looks to be much too big for the ramdisks. As a note to anyone skilled... take the above issues as a challenge. If you can improve those problems in ftp(1), we'd love it. But it must remain a fairly small program. Proposed (incomplete) behavior : EBADF = fatal EFBIG, EIO, EPIPE = warn + quit this file ( but EPIPE = wait for someone to open the pipe ? or warn + quit this file ) $ cat /dev/zero | cat /dev/null [1] 15546 28664 $ kill -INT 28664 $ jobs [1] + Broken pipe cat /dev/zero | Interruptcat /dev/null here, 15546 exits because of EPIPE during write it does not warn about anything 28664 could've been signaled in any fashion, INT is used to highlight it might be interactive use why should a user interrupt end up as a warning? big friggen deal just exit the program ENOSPC, EDQUOT = warn + quit this file, or warn + sleep (hope someone rm some stuff) EINTR = info + retry ? how many retry ? or for how long ? EFAULT = call the martian + fatal EAGAIN = call poll and retry ? some fs can do that right ? Network related = ignore (fout is not a socket) But this one [EIO] The process is a member of a background process attempting to write to its controlling terminal, TOSTOP is set on the terminal, the process isn't ignoring the SIGTTOUT signal and the thread isn't blocking the SIGTTOUT signal, and either the process was created with vfork(2) http://www.openbsd.org/cgi-bin/man.cgi?query=vforksektion=2arch=i386apropos=0manpath=OpenBSD+Current and hasn't successfully executed one of the exec functions or the process group is orphaned. Yes this one would require skillz of fatal(I dont get it, can you please use your ftp client like anyone else :-)); -- - () ascii ribbon campaign - against html e-mail /\
Re: Weird loop in ftp client
On Sun, Nov 24, 2013 at 7:29 PM, sven falempin sven.falem...@gmail.com wrote: On Sun, Nov 24, 2013 at 5:57 PM, Andres Perera andre...@zoho.com wrote: On Sun, Nov 24, 2013 at 12:11 PM, sven falempin sven.falem...@gmail.com wrote: On Sat, Nov 23, 2013 at 5:47 PM, Theo de Raadt dera...@cvs.openbsd.orgwrote: On 2013/11/23 14:39, sven falempin wrote: Hello, Another point of vue : Because curl is in base, what does ftp client add to the system ? ftp(1) is not without problems (bad ssl support, semi-broken proxy support, difficult code) but it has one major advantage: the small version used on ramdisks is quite small, something like 80k. cURL is not in base, but even if it was, it looks to be much too big for the ramdisks. As a note to anyone skilled... take the above issues as a challenge. If you can improve those problems in ftp(1), we'd love it. But it must remain a fairly small program. Proposed (incomplete) behavior : EBADF = fatal EFBIG, EIO, EPIPE = warn + quit this file ( but EPIPE = wait for someone to open the pipe ? or warn + quit this file ) $ cat /dev/zero | cat /dev/null [1] 15546 28664 $ kill -INT 28664 $ jobs [1] + Broken pipe cat /dev/zero | Interruptcat /dev/null here, 15546 exits because of EPIPE during write it does not warn about anything 28664 could've been signaled in any fashion, INT is used to highlight it might be interactive use why should a user interrupt end up as a warning? big friggen deal just exit the program because the job is unfinished, moreover you just kill one of two programs I do not think your case is relevant. the process getting EPIPE doesn't know that the process reading was killed it doesn't know anything other than EPIPE why woud it spin infinately waiting for the fd to open again, as you suggested? or even print a warning? ENOSPC, EDQUOT = warn + quit this file, or warn + sleep (hope someone rm some stuff) EINTR = info + retry ? how many retry ? or for how long ? EFAULT = call the martian + fatal EAGAIN = call poll and retry ? some fs can do that right ? Network related = ignore (fout is not a socket) But this one [EIO] The process is a member of a background process attempting to write to its controlling terminal, TOSTOP is set on the terminal, the process isn't ignoring the SIGTTOUT signal and the thread isn't blocking the SIGTTOUT signal, and either the process was created with vfork(2)http://www.openbsd.org/cgi-bin/man.cgi?query=vforksektion=2arch=i386apropos=0manpath=OpenBSD+Currentand hasn't successfully executed one of the exec functions or the process group is orphaned. Yes this one would require skillz of fatal(I dont get it, can you please use your ftp client like anyone else :-)); -- - () ascii ribbon campaign - against html e-mail /\ -- - () ascii ribbon campaign - against html e-mail /\
Re: pax / tar exit code on truncated input
On Fri, Apr 4, 2014 at 2:12 PM, Philip Guenther guent...@gmail.com wrote:
On Fri, Apr 4, 2014 at 11:27 AM, Marco Pfatschbacher m...@mailq.de wrote:
On Thu, Apr 03, 2014 at 05:19:45PM -0600, Theo de Raadt wrote:
Interesting. Can we take bath approaches?
I don't see why we should not.
Is there a reason to not expose either error?
I thought it might break some legacy stuff regarding
tapes and such. But since no one spoke up...
OK?
pax does not exit with an error if the processed
archive is truncated:
# (cd / tar zcf - bsd | dd count=128 2/dev/null | tar tzf -)
bsd
gzip: stdin: Input/output error
tar: End of archive volume 1 reached
gzip: stdout: Broken pipe
tar: Failed write to archive volume: 1: Broken pipe
# echo $?
0
There's two ways to fix this.
1) take the exit code of gzip into account:
Index: ar_io.c
===
RCS file: /cvs/src/bin/pax/ar_io.c,v
retrieving revision 1.44
diff -u -p -p -u -r1.44 ar_io.c
--- ar_io.c 11 Jan 2014 05:36:26 - 1.44
+++ ar_io.c 28 Mar 2014 14:09:37 -
@@ -337,8 +337,11 @@ ar_close(void)
(void)close(arfd);
/* Do not exit before child to ensure data integrity */
- if (zpid 0)
+ if (zpid 0) {
waitpid(zpid, status, 0);
+ if (WIFEXITED(status) WEXITSTATUS(status))
+ exit_val = 1;
+ }
Hmm, should that be
if (!WIFEXITED(status) || WEXITSTATUS(status))
This is incorrect because a process can conclude its work before
terminating because of a signal.
To demonstrate I can use the OP's pipeline:
for i in $(jot 100); do
{ cd /; tar czf - bsd p=$!; sleep 0.8; kill $p; } | tar tzf -
echo X
done 21 |
awk '/^X/ {a[FNR - c - 1]++; c = FNR} END {print complete write a[1]
print late signala[2]
print short writea[4]}'
complete write 8 # concluded work, terminated by signal
late signal34 # concluded work, beat the signal race
short write58 # terminated by signal before concluding work
This is only an example. Like other processes, gzip is subject to the race.
Re: rs, jot: missing headers
On Fri, Apr 11, 2014 at 7:02 PM, Ralph Siegler rsieg...@rsiegler.org wrote: On Thu, 10 Apr 2014 21:55:13 -0700, Philip Guenther wrote: On Thu, Apr 10, 2014 at 7:14 PM, Ralph Siegler rsieg...@rsiegler.org wrote: On Thu, 14 Nov 2013 23:17:24 -0500, Eitan Adler wrote: I was looking through some OpenBSD code and noticed that rs and jot are both missing #include unistd.h even though they use getopt. It seems that stdlib.h defines getopt on OpenBSD. However, this is not the correct header file, and it makes it not possible to compile OpenBSD's utilities on other platforms. I just looked on my linux box and found this in stdlib.h ... So I'm wondering about your assertion that this is not the correct header filelooking at links in your post, do you really mean FreeBSD doesn't define them there but everyone else on the planet might? He's perhaps referring to the POSIX standard, which specifies that that *in a conforming compilation environment* unistd.h MUST declare getopt() and stdlib.h MUST NOT declare getopt(). (Ya'll know that the current POSIX standard can be downloaded after a free registration, don'cha?) Philip Guenther Well Philip, had we mentioned any POSIX 2008.1 certified or compliant OS in this thread that would be an interesting point to bring up. But neither GNU/Linux, OpenBSD, nor FreeBSD is fully compliant. On the other hand, Mac OSX Mavericks is 100% compliant and certified, and per spec has, for example, sem_init and sem_destroy in the header files...but lo and behold doesn't actually implement them in the libraries. This and similar show-without-go has bummed out more than one code porter. Meanwhile, OpenBSD doesn't have the 100% 2008.1 beef stamp on its hind quarters but will compile and run code having those functions..which is better? Yes, de facto standards can be important. Now, does this issue in particular--namely, the decision of which header declares getopt()--merit reconsideration? Should OpenBSD or another OS depart from POSIX in this regard? If so, what is the motivation? Ralph
Re: rs, jot: missing headers
On Fri, Apr 11, 2014 at 10:27 PM, Ralph Siegler rsieg...@rsiegler.org wrote: On Fri, 11 Apr 2014 19:27:03 -0430, Andres Perera wrote: On Fri, Apr 11, 2014 at 7:02 PM, Ralph Siegler rsieg...@rsiegler.org wrote: On Thu, 10 Apr 2014 21:55:13 -0700, Philip Guenther wrote: On Thu, Apr 10, 2014 at 7:14 PM, Ralph Siegler rsieg...@rsiegler.org wrote: On Thu, 14 Nov 2013 23:17:24 -0500, Eitan Adler wrote: I was looking through some OpenBSD code and noticed that rs and jot are both missing #include unistd.h even though they use getopt. It seems that stdlib.h defines getopt on OpenBSD. However, this is not the correct header file, and it makes it not possible to compile OpenBSD's utilities on other platforms. I just looked on my linux box and found this in stdlib.h ... So I'm wondering about your assertion that this is not the correct header filelooking at links in your post, do you really mean FreeBSD doesn't define them there but everyone else on the planet might? He's perhaps referring to the POSIX standard, which specifies that that *in a conforming compilation environment* unistd.h MUST declare getopt() and stdlib.h MUST NOT declare getopt(). (Ya'll know that the current POSIX standard can be downloaded after a free registration, don'cha?) Philip Guenther Well Philip, had we mentioned any POSIX 2008.1 certified or compliant OS in this thread that would be an interesting point to bring up. But neither GNU/Linux, OpenBSD, nor FreeBSD is fully compliant. On the other hand, Mac OSX Mavericks is 100% compliant and certified, and per spec has, for example, sem_init and sem_destroy in the header files...but lo and behold doesn't actually implement them in the libraries. This and similar show-without-go has bummed out more than one code porter. Meanwhile, OpenBSD doesn't have the 100% 2008.1 beef stamp on its hind quarters but will compile and run code having those functions..which is better? Yes, de facto standards can be important. Now, does this issue in particular--namely, the decision of which header declares getopt()--merit reconsideration? Should OpenBSD or another OS depart from POSIX in this regard? If so, what is the motivation? OpenBSD uses the magic of #ifndef to get away with defining it in two places, so following POSIX (and the OpenBSD man page) and #include unistd.h gets the getopt(3) and so Eitan should be happy. But back in the pre-1992 POSIX.2 days, it was defined (as least in some Unix I know) to be in stdlib.h. And lo and behold OpenBSD will define it there if it hasn't been defined yet. Well, starting with r1.54 [0], stdlib.h never declares getopt(). However, I think the conversation could continue in spite of that. I would expect motivation to be aggregated cost in the form: * a significant amount of patched ports; * a significant amount of affected port prospects; or * a significant amount of patched user programs. You happen to mention the last item. Are there other users interested in this facet of source compatibility? Also, are there other possible costs? [0] http://www.openbsd.org/cgi-bin/cvsweb/src/include/stdlib.h.diff?r1=1.53;r2=1.54;f=h
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 7:01 PM, Philip Guenther guent...@gmail.com wrote:
On Mon, Feb 21, 2011 at 2:30 PM, Fred Crowson open...@crowsons.net wrote:
On 02/21/11 15:54, Alexander Schrijver wrote:
...
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
$ find . -name *.php -exec grep blah {} \; -print
Will print the file name after the line that grep matches.
The other classical solution is to always pass multiple filenames by
including a /dev/null argument:
B find . -name '*.c' -exec grep bla {} /dev/null \;
That works with the xargs case too:
B find . -name '*.c' -print0 | xargs -0 grep bla /dev/null
these two ugly hacks and the the redundant flag have been sought while
what's natural has been overlooked
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
why complicate grep?
Philip Guenther
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 12:51 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. then make the awk line a function or a script don't add more flags to grep that are hard to guess what they do -H for header? what does it mean? have you looked at how many flags ls(1) can have? it's a nightmare
printf(1) null escape
print_escape returns 1 even if it's on null, and the rest of the
prog just ignores null literals
$ env -i sh -c '/usr/bin/printf \\'
printf: unknown escape sequence `\'
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
diff -u -r1.17 printf.c
--- printf.c27 Oct 2009 23:59:41 - 1.17
+++ printf.c2 Apr 2011 18:44:36 -
@@ -351,6 +351,11 @@
putchar('\v');
break;
+ case '\0':
+ warnx(null escape sequence);
+ rval = 1;
+ return 0;
+
default:
putchar(*str);
warnx(unknown escape sequence `\\%c', *str);
Re: printf(1) null escape
#include unistd.h
#define CMD /usr/bin/printf
int
main(void)
{
execle(CMD, CMD, \\, NULL, (char *[]){BROKEN, NULL});
}
On Sat, Apr 2, 2011 at 4:48 AM, Andres Perera andre...@zoho.com wrote:
print_escape returns 1 even if it's on null, and the rest of the
prog just ignores null literals
$ env -i sh -c '/usr/bin/printf \\'
printf: unknown escape sequence `\'
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
just to be absolutely clear, printf(1) is the one overstepping into
environ[] because of how it badly handles escapes, not the shell
#include unistd.h
#define CMD /usr/bin/printf
int
main(void)
{
execle(CMD, CMD, \\, NULL, (char *[]){BROKEN});
}
here's the plain bug:
$ (./a.out; echo) | vis -l
printf: unknown escape sequence `\'
\^@BROKEN\$
diff -u -r1.17 printf.c
--- printf.c B B 27 Oct 2009 23:59:41 - B B B 1.17
+++ printf.c B B 2 Apr 2011 18:44:36 -
@@ -351,6 +351,11 @@
B B B B B B B B putchar('\v');
B B B B B B B B break;
+ B B B case '\0':
+ B B B B B B B warnx(null escape sequence);
+ B B B B B B B rval = 1;
+ B B B B B B B return 0;
+
B B B B default:
B B B B B B B B putchar(*str);
B B B B B B B B warnx(unknown escape sequence `\\%c', *str);
Re: horribly slow fsck_ffs pass1 performance
On Sun, Apr 3, 2011 at 4:21 AM, Janne Johansson icepic...@gmail.com wrote: 2011/4/2 Benny Lofgren bl-li...@lofgren.biz I've noticed that some (all?) linux systems do uncalled-for file system checks at boot if no check have been made recently, but I've never understood this practice. It must mean they don't trust their own file systems, I'm quite sure this comes from the fact that there are several ways for a ext file system to get errors (which in bash used to show up as input/output error when you try to reference the file) but the filesystem will not store the error condition anywhere, so if you make a clean shutdown, and reboot, the fsck will not know that a fsck in due, and skip over it, and for that whole session until the next reboot, the file is still as inaccessible as before. And since only root may write the magic file in the (broken) filesystem root, a normal user can not force the fsck either, unless he kills the power switch so the boot scripts know there was an unclean shutdown before, OR, reboot 147 times (or whatever the intervals may be) so the system does run the fsck at boot. I dont pretent to know the optimal solution for keeping track of hey, I just told the user his file is corrupt, I should ask for fsck on the next mount but even the early-80s amiga floppy file systems would have a global dirty flag so the OS would launch disk validator next time you inserted the disk and mounted the filesystem if you found out it had some kind of read/write error. Letting users run 1-146 reboot cycles without checking even when you know stuff is broke is horrid. And having a file inside the actual filesystem to indicate if this file isnt deleted it means something as an inverse flag really doesnt count (/fastboot or whatever) since if half your files disappear and that one went also, then its missing status would indicate everything is fine. /forcefsck and /fastboot have nothing to do with that they are not even administered by the fs -- B To our sweethearts and wives. B May they never meet. -- 19th century toast
Re: horribly slow fsck_ffs pass1 performance
On Tue, Apr 5, 2011 at 7:06 AM, Janne Johansson icepic...@gmail.com wrote: /forcefsck and /fastboot have nothing to do with that they are not even administered by the fs I wasn't trying to imply the filesystem is putting the files there, nor reading them. Rather, those two files show that since there is no way to mark known brokeness in a ext file system, we wrap it up in shell scripts that create and look for B those files in order to 'know' if the filesystems are broken or not and if fsck is in order sorry, but those files aren't for that purpose. they're just means of queuing fscks and never intended as a viable replacement for dirty flags conversely, openbsd has got /fastboot, yet aptly omits /forcefsck you could say the latter has been avoided because it's a chicken and egg problem, but keep in mind that it forces fsck on all filesystems with a fs_passno greater than zero, not just root, and that / is very unlikely to become corrupted because it's typically split and seldom written to
Re: no really, be quiet mode for ping{,6}
On Wed, Apr 6, 2011 at 6:30 AM, Peter Hessler phess...@openbsd.org wrote: On 2011 Apr 06 (Wed) at 12:47:40 +0200 (+0200), David Vasek wrote: :On Wed, 6 Apr 2011, Peter Hessler wrote: : :Sometimes I want ping to be quiet. B Not quiet in the only show me :headers way that the original author thought was cute, but in the :don't show me anything way, so cron doesn't spam me with useless :crap. : :So, in honor of that, here is a patch to add -Q to ping and ping6. : :What is the advantage of another button over redirecting stdout and :error to /dev/null? Is the completely quiet ping used so often? : :Regards, :David : I use silent ping very often (especially in scripts and cronjobs), and it pisses me off that I need to redirect to /dev/null. B I'm scratching an itch, here. -- It's the thought, if any, that counts! the shell was supposed to define the interface so that not every program had to recreate it and now ksh has a convenient short-hand: ping google.com - the homogeneous -q flags are as problematic as: tar xf - vs. tar xf /dev/stdin seems strange that it was decided to put the - alias inside every and each command that uses it instead of having distinct shorthand for stdout/in through the shell or fs
Re: sed behavior
that's not relevant to the example because $ matches the empty string at eol, not the character at eol (.$), which is openbsd sed's interpretation even in the case of certain regex standards that do not allow $ to be used as part of a | expression, the interpretation is faulty On Wed, Jun 15, 2011 at 5:54 PM, Stuart Henderson s...@spacehopper.org wrote: On 2011-06-15, Alexander Hall ha...@openbsd.org wrote: This dif fixes your problem here. Big question is of course: does it break other cases? It differs from perl like this: $ echo 'l1_1' | perl -pe 's/1|$/X/g' lX_XX $ echo 'l1_1' | sed -E 's/1|$/X/g' lX_X Meaning we don't hit that final '$' if the last match went to eol. perl regular expressions are expected to behave differently to posix REs.
Re: fdisk geom fixes
On Mon, Jul 4, 2011 at 11:32 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Mon, Jul 04, 2011 at 09:38:37PM -0430, Andres Perera wrote: On Mon, Jul 4, 2011 at 8:56 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: The use of CHS should be hard and attempted only by those who know all the rules already. which is made difficult by not being able to select a subset of cyls, since fdisk caps them at 1024 on amd64 note that geom was, and continues to be, only relevant for the duration of that fdisk instance all the changes are just to help with partitioning, e.g. by using a percentage based on the subset of cyls that i could select, or just globbing the entire cyl range at the moment it is not for people that know the intricacies, as you're implying. it doesn't allow for anything useful if geom is removed from fdisk, then the obsd install ideally has to account for geom changes before making mbr partitions MBR partitions are created based solely on lba info, with the chs info just faked in. Removing geom would have no impact on the install as far as I know. At least for 99.9% of situations. That would be an interesting experiment. Ken even though it's ultimately the same for people that don't change them, mbr partitions are not created from lba in fdisk. the data goes through this mangling: 1. lba (disklabel, which means that it's not necessarily lba) 2. boundless CHS 3. boundless CHS is influenced by geom (disk command) 4. 255/63 check (cylinders are ignored for the check and always written as 1024) 5. partitions are created based on boundless CHS, partition end is usually aligned with last cylinder 6. dishonest bounded CHS gets written to mbr from this point, it either writes 255 in all CHS fields except the 2 bit S field, or an almost honest representation of lba since you can change the boundless CHS through geom, then CHS values do influence, just not the ones in the MBR... it's important to make that distinction in order to get anywhere with this mess besides that, for people that want to partition mbr after *really* changing CHS values: during install they have to access the shell and change CHS with disklabel before fdisk. that's fine since it is an unusual need: disklabel (fill in boundstart and end, or don't partition yet) - fdisk - disklabel but two things need to be clarified: the order is assbackwards. disklabel influences fdisk, and fdisk influences disklabel (to set boundstart and boundend). this complexity is a problem no matter what happens to geom with fdisk the second thing is that the disk command is misleading since it does not expose the relationship between disklabel and fdisk, in fact, it actively confuses how the two relate. improving the disk command, like i suggested + writing to disklabel, would lead to less circling dependencies. but the better solution requires more drastic changes than the ones i proposed: disklabel should not handle geom + partitions, it's a mess. whatever handles geom comes before fdisk and disklabel
Re: etc/rc.d/spamlogd needs pflog
On Sat, Aug 6, 2011 at 7:11 AM, Stuart Henderson s...@spacehopper.org wrote:
Since pflog interface creation was moved to rc.d/pflogd, you can
no longer run spamlogd without also running pflogd. This diff copies
the interface creation code from pflogd (it doesn't hurt to create
pflog0 twice).
This doesn't handle the case with spamlogd -l where a non-default
interface is used (but neither does pflogd handle the case with -i),
but I think for non-default options it's reasonable to expect the
user to do a little more work (e.g. 'echo up /etc/hostname.pflog1').
Index: spamlogd
===
RCS file: /cvs/src/etc/rc.d/spamlogd,v
retrieving revision 1.1
diff -u -p -r1.1 spamlogd
--- spamlogd B B 8 Jul 2011 02:15:34 - B B B 1.1
+++ spamlogd B B 6 Aug 2011 11:32:39 -
@@ -10,6 +10,17 @@ rc_reload=NO
B rc_pre() {
B B B B [ B X${spamd_flags} != XNO -a X${spamd_black} = XNO ]
this check needs to return 1 if it fails
or you're assuming it's a set -e shell?
+
+ B B B if pfctl -si | grep -q Enabled; then
+ B B B B B B B ifconfig pflog0 create
+ B B B B B B B if ifconfig pflog0; then
+ B B B B B B B B B B B ifconfig pflog0 up
+ B B B B B B B else
+ B B B B B B B B B B B return 1
+ B B B B B B B fi
+ B B B else
+ B B B B B B B return 1
+ B B B fi
B }
B rc_cmd $1
Re: -not for find(1)
linux does worth pointing out that some tests in old firefox ports (maybe still there) failed because the lack of -not On Mon, Feb 27, 2012 at 3:01 PM, Ted Unangst t...@tedunangst.com wrote: On Mon, Feb 27, 2012, Steffen Daode Nurpmeso wrote: this patch adds the -not operator to find(1). I personally always found -not easier to use due to shell escaping, but today may laziness has bitten back. And it's just one more non-POSIX-compliant option. This makes a lot of sense to me, but it's good to research what other systems support the same option. B Linux, FreeBSD, and Solaris are worthy references.
Re: -not for find(1)
On Mon, Feb 27, 2012 at 3:36 PM, Landry Breuil lan...@rhaalovely.net wrote: On Mon, Feb 27, 2012 at 03:24:05PM -0430, Andres Perera wrote: linux does worth pointing out that some tests in old firefox ports (maybe still there) failed because the lack of -not Are you thinking about https://bugzilla.mozilla.org/show_bug.cgi?id=665040 ? yes well, don't let my talk of 8 month old resolved bug reports persuade you -not stands on its own merits. Anyway, i think that was the only occurence of -not, since grep -r -- ' \-not' B * in mozilla-central yields nothing. Landry On Mon, Feb 27, 2012 at 3:01 PM, Ted Unangst t...@tedunangst.com wrote: On Mon, Feb 27, 2012, Steffen Daode Nurpmeso wrote: this patch adds the -not operator to find(1). I personally always found -not easier to use due to shell escaping, but today may laziness has bitten back. And it's just one more non-POSIX-compliant option. This makes a lot of sense to me, but it's good to research what other systems support the same option. B Linux, FreeBSD, and Solaris are worthy references.
Re: tmux and login shells
i agree. also disliked loginShell in xresources, but that's very easy to alter would be nice to hear an explanation from the author(s) of tmux about always perusing a login shell
Re: Hibernate support
nice would it be feasible to also compress kernel dumps once the compression logic is in place for hibernation? On Wed, Jul 11, 2012 at 11:41 AM, Mike Larkin mlar...@azathoth.net wrote: Hibernate support (suspend-to-disk) will be shortly enabled for i386 + wd machines. Some FAQs, before I commit the change to turn it on: 1. If you have anything other than i386 + wd, it won't work. Don't report it. Other archs + disk types are being worked on now that i386 + wd is working. This means, *FOR NOW*, it works on combinations like this: wd0 at pciide0 channel 0 drive 0: INTEL SSDSA2MH160G1GC .. NOT this: ahci0 at pci0 dev 31 function 2 Intel 82801I AHCI rev 0x03: msi, AHCI 1.2 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, M4-CT512M4SSD2, 0009 SCSI3 0/direct 2. Hibernate writes to swap (at the end of your swap). If you have too small a swap, it won't work, or if there are swap pages in use at the end of your swap that overlap with what we want. You need at least size of mem + 64MB of swap at the end of swap, free, at the time of hibernate. 3. We do *not* do encryption of the hibernated image, even if you have turned on encrypted swap. 4. If you change your memory size/layout or change your kernel, we will detect this and abort any hibernate resumes. The resume will be a normal boot then. 5. It will be very slow for the time being - this is a known problem that I am working on fixing, but for now, we will wastefully write all memory, even pages that are not in use. This will be fixed, so please don't report that it's slow. On my machine with 1.5GB ram, it takes a few minutes to write everything out, and about 30s to read it back in on resume. 6. Hibernate can be triggered via 'ZZZ' in -current (capital 'Z's for hibernate, lowercase 'z' for suspend). 7. Right now, there is no unwind support for errors. This means that just about every failure case will result in a panic or reboot. This too is being worked on. If you have a supported (see #1) configuration and want to test it, let us know if it works (or doesn't). There won't be a diff posted here, it will just get enabled, probably sometime later tonight or tomorrow. -ml
Re: dc(1) exp improvements
On Tue, Nov 6, 2012 at 3:27 PM, Otto Moerbeek o...@drijf.net wrote:
Hi,
And here's a diff to repair ^, whcih now produces correct results for
things like
(dc)0.1 _1 ^p
or
(bc)0.1 ^ -1
The diff is against very current, so beware.
i've lightly tested it against gnu bc and it works
i do have 2 small comments below
Please test. I have some regress test updates for dc as well. t9 turns
out to be a wrong test (computation of 2.1 ^ 500). That is fixed with
this diff as well.
-Otto
Index: bcode.c
===
RCS file: /cvs/src/usr.bin/dc/bcode.c,v
retrieving revision 1.44
diff -u -p -r1.44 bcode.c
--- bcode.c 6 Nov 2012 16:00:05 - 1.44
+++ bcode.c 6 Nov 2012 19:42:07 -
@@ -257,6 +257,12 @@ init_bmachine(bool extended_registers)
(void)signal(SIGINT, sighandler);
}
+u_int
+bmachine_scale(void)
+{
+ return bmachine.scale;
+}
+
/* Reset the things needed before processing a (new) file */
void
reset_bmachine(struct source *src)
@@ -991,7 +997,7 @@ bsub(void)
}
void
-bmul_number(struct number *r, struct number *a, struct number *b)
+bmul_number(struct number *r, struct number *a, struct number *b, u_int
scale)
{
BN_CTX *ctx;
@@ -1007,7 +1013,7 @@ bmul_number(struct number *r, struct num
if (rscale bmachine.scale rscale ascale rscale bscale) {
r-scale = rscale;
- normalize(r, max(bmachine.scale, max(ascale, bscale)));
+ normalize(r, max(scale, max(ascale, bscale)));
} else
r-scale = rscale;
the function unconditionally sets r-scale to rscale, but the
operation is duplicated across `if' bodies. interpreting a diff for
the function is difficult because the intent is unclear
}
@@ -1029,7 +1035,7 @@ bmul(void)
}
r = new_number();
- bmul_number(r, a, b);
+ bmul_number(r, a, b, bmachine.scale);
push_number(r);
free_number(a);
@@ -1160,7 +1166,7 @@ bexp(void)
struct number *a, *p;
struct number *r;
boolneg;
- u_int scale;
+ u_int rscale;
p = pop_number();
if (p == NULL) {
@@ -1191,7 +1197,7 @@ bexp(void)
if (BN_is_negative(p-number)) {
neg = true;
negate(p);
- scale = bmachine.scale;
+ rscale = bmachine.scale;
} else {
/* Posix bc says min(a.scale * b, max(a.scale, scale) */
u_long b;
@@ -1199,30 +1205,35 @@ bexp(void)
b = BN_get_word(p-number);
m = max(a-scale, bmachine.scale);
- scale = a-scale * (u_int)b;
- if (scale m || (a-scale 0 (b == BN_MASK2 ||
+ rscale = a-scale * (u_int)b;
+ if (rscale m || (a-scale 0 (b == BN_MASK2 ||
b UINT_MAX)))
- scale = m;
+ rscale = m;
}
if (BN_is_zero(p-number)) {
r = new_number();
bn_check(BN_one(r-number));
- normalize(r, scale);
+ normalize(r, rscale);
} else {
+ u_int scale, ascale = a-scale;
`scale' should be renamed for clarity to signify that it's an
accumulator for `ascale'. at its current state, not being prefixed by
a letter that is, `scale' looks more important than it is
Re: upstream vendors and why they can be really harmful
i'm not sure how using js for configuration files, as opposed to using a language commonly deployed for the same purpose, such as lua, presents an innate constraint on security. if i'm somehow expected to ignore how unlikely it is for the configuration vm to: a. intentionally have the ability of boundlessly influencing program behavior, or b. provide exploits that aid users with the privileges required for configuring said program in boundlessly influencing program behaviour, and that said person even has the incentive to do so (maybe in your site sudo configuration files are generated from entries to pub/guestbook.html?) then i would point out that, if anything, a popular js implementation receives broader testing than sudo's dsl. On Thu, Nov 22, 2012 at 9:04 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Follow-up interview, much better to say what you want instead of having people interpret your email. Do you know polkit (which I believe is cross platform but I prefer to remove it, primarily because it gives little indication of what is allowed and requires constant review, unlike sudo) now uses Javascript for it's configuration files because the author (from his blog) believed JS to be the most universal language he could think of. I'm still unsure if he's serious or just taking the piss. I'm sure though he writes security software, he didn't realise any security ramifications in any case. Anyway sorry to lower the tone. Cross polination and health is important. Less can certainly be more and mean more sooner for everyone. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 11:58 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 22 Nov 2012 09:30:41 -0430 Andres Perera wrote: i'm not sure how using js for configuration files, as opposed to using a language commonly deployed for the same purpose, such as lua, presents an innate constraint on security. Firstly the article mentioned JIT preventing true randomisation. Secondly pulling in JS as a dependency even on servers is rediculous and is a language very familiar to attackers and unfamiliar to many users. It would be especially, shall we say kind to attackers utilising rop attacks. but jit isn't irreparably interleaved with js am i compromising by running luajit in interpreter mode instead of the reference implementation, moreover, would that imply that lua the language is insecure or is the specific implementation at fault? why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) then i would point out that, if anything, a popular js implementation receives broader testing than sudo's dsl. And it needs it and turns up bugs every week and grows constantly. Are you serious! i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() what now?
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 2:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 22 Nov 2012 14:18:59 -0430 Andres Perera wrote: there's still no tie-in to the privileges of the process, It still lets a process do something unintended. In fact getting a browser to execute an external javascript program is a threat in itself that could have no end of custom instructions executed as a normal user. something unintended like fiddling with its registers and increasing $pc in gdb In fact getting a browser to execute an external javascript program is a threat in itself that could have no end of custom instructions executed as a normal user. i'm convinced that you don't know what javascript is and in spite of that decided that it carries along the dom apis wherever it goes, like some sort of disfunctional sidekick relationship ala robin and batman as explained in my previous message, and there's also a new, pending tie-in; POSIX being influenced by such things -- i doubt that js is creeping its merry way into posix. Your twisting my meaning and I'm sure we're just boring everyone and polluting this thread for sure now and this is @tech. that's just the pussiest way of saying i've mistakenly sprayed my comments with acronyms like rop and jit, but i have no fucking clue how they relate
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 11:41 PM, Marc Espie es...@nerim.net wrote: On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) [...] i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() You're only talking about one small aspect of security. Just because your javascript apps cannot interact with your OS doesn't make them secure. that's not a specialized condition reserved to js interpreters, and i also don't wish to talk about larger aspects because i'd be entering an area that's dominated by quality of implementation issues that aren't solved by os access control tools They also have to be reliable, not trample on each other memory, so that you get predictable behavior and only have to worry about logic errors in each app. same applies People are *relying* on javascript to do real work. If you're depositing documents on servers. If you're using gmail. If you're using any kind of web app, basically. that's interesting. the subject is about a potential configuration language that is managed by the administrator, such as polkit's and sudo's Every day, people say that high-level languages like java or js are more secure. They are missing the point. Just because they don't have buffer overflows doesn't protect them from sloppy developer errors. Just the opposite, actually: being stupid is no longer a barrier to writing production code, and you end up with idiots writing code, instead of being stopped right away by C's nastiness. every time i pair malloc() with free(), i don't feel enlightened; i don't feel like wallowing in thoughts of my own self-worth; i don't feel like masturbating intellectually i should know by now, given that i'm 3 months into rewriting infrastrusture/bin/dpb in C
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 12:11 PM, Andres Perera andre...@zoho.com wrote:
don't know about OP, but yesterday i was surprised when rtlabel had to
be specified after inet
just double checked; s/after/before
ifconfig(8) section on rtlabel bears no mention about the order
before rearranging, lines were just C sorted:
cat hostname.ral0
inet 192.168.2/24
rtlabel egress
afterboot:
route -vn show -inet | awk '{$2=;print}' | column -t
...
Destination Flags Refs Use MtuPrio Iface Label
default UGS4 557 - 12ral0
10.0.0/24 UC 1 0 - 4 re0
10.0.0.11 UHLc 3 1100 - 4 re0
127/8 UGRS 0 0 33152 8 lo0
127.0.0.1 UH 2 2433152 4 lo0
192.168.2/24 UC 1 0 - 4 ral0
192.168.2.1 UHLc 1 0 - 4 ral0
224/4 URS0 0 33152 8 lo0
i haven't fully researched the relationship between the two, but at
least during boot's run of netstart, this is a case where order of
lines and thus ifconfig commands do matter
On Mon, Nov 26, 2012 at 11:56 AM, Jason McIntyre j...@kerhand.co.uk wrote:
On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote:
Be more specific about the order of interpretation. Okay?
diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5
index b07459f..aa8446f 100644
--- share/man/man5/hostname.if.5
+++ share/man/man5/hostname.if.5
@@ -49,6 +49,8 @@ A configuration file is not needed for lo0.
The configuration information is expressed in a line-by-line packed format
which makes the most common cases simpler; those dense formats are
described
below.
+The order of the configuration lines matters, they are interpreted from the
+top down.
Any lines not matching these packed formats are passed directly to
.Xr ifconfig 8 .
The packed formats are converted using a somewhat inflexible parser and
if we say this, then we should provide guidance to folks about how to
order the lines. what is the specific problem, or the general rule, that
you are addressing?
jmc
Re: ksh bad PS1 ascii octal to char conversion
On Sat, Mar 02, 2013 at 03:08:44PM -0800, Philip Guenther wrote:
On Sat, 2 Mar 2013, Andres Perera wrote:
On Sat, Mar 2, 2013 at 5:13 PM, Philip Guenther guent...@sendmail.com
wrote:
...
Hmm, this is actually changing two things: it's both fixing the problem
that the code is not subtracting '0' from each character before doing the
octal place conversion and it's also changing it to support octal
sequences of fewer than 3 digits. The latter seems unnecessary and isn't
documented, do we really need/want to add it?
the behaviour is consistent with bash, which is the shell ksh took it from
in addition to that, it's consistent with c string literals and printf(1)
ksh having an doing things differently is a bigger bug than
precedence... ps1 isn't exactly crucial in scripts
Yet it wasn't important enough to mention or document. Huh. I'm not
interested without a manpage update to match.
new patch below
like before
* fix the bug with PS1 octal conversion
* add 1 .. 3 octal number feature as seen in bash, printf(1), etc.
aditionally
* document the new behaviour in ksh(1)
* change `c' to int; match other routines
Index: lex.c
===
RCS file: /cvs/src/bin/ksh/lex.c,v
retrieving revision 1.46
diff -p -u -r1.46 lex.c
--- lex.c 20 Jan 2013 14:47:46 - 1.46
+++ lex.c 2 Mar 2013 23:07:19 -
@@ -1349,17 +1349,17 @@ dopprompt(const char *sp, int ntruncate,
case '4':
case '5':
case '6':
- case '7':
- if ((cp[1] '7' || cp[1] '0') ||
- (cp[2] '7' || cp[2] '0')) {
- snprintf(strbuf, sizeof strbuf,
- \\%c, *cp);
- break;
- }
- n = cp[0] * 8 * 8 + cp[1] * 8 + cp[2];
- snprintf(strbuf, sizeof strbuf, %c, n);
- cp += 2;
+ case '7': {
+ int c = 0, i = 3;
+
+ do
+ c = c * 8 + *cp - '0';
+ while (--i *++cp = '0' *cp = '7');
+ cp -= !!i;
+ strbuf[0] = c;
+ strbuf[1] = '\0';
break;
+ }
case '\\': /* '\' '\' */
strbuf[0] = '\\';
strbuf[1] = '\0';
Index: ksh.1
===
RCS file: /cvs/src/bin/ksh/ksh.1,v
retrieving revision 1.145
diff -p -u -r1.145 ksh.1
--- ksh.1 17 Jan 2013 21:20:25 - 1.145
+++ ksh.1 2 Mar 2013 23:07:21 -
@@ -1662,7 +1662,7 @@ as a special character within double quo
it is safer in this case to escape the backslash
than to try quoting it.
.It Li \e Ns Ar nnn
-The octal character
+The character whose octal value is the 1 to 3 (inclusive) digit number
.Ar nnn .
.It Li \e\e
Insert a single backslash character.
sudo documentation purports wrong loginclass functionality
There are at least two instances in sudo documentation that lead to believe that `use_loginclass' and `sudo -c` behave differently than they do in the implementation WRT which of the target and calling users' loginclass gets applied. sudoers(5): 831 832 use_loginclassIf set, sudo will apply the defaults specified for the 833 target user's login class if one exists. Only 834 available if sudo is configured with the 835 --with-logincap option. This flag is off by default. 836 By target user I understand NAME in `sudo -uNAME CMD` or root in absence of `-u'. sudo(8): 69 70 -c classThe -c (class) option causes sudo to run the specified 71 command with resources limited by the specified login class. 72 The class argument can be either a class name as defined in 73 /etc/login.conf, or a single `-' character. Specifying a 74 class of - indicates that the command should be run 75 restricted by the default login capabilities for the user the 76 command is run as. If the class argument specifies an 77 existing user class, the command must be run as root, or the 78 sudo command must be run from a shell that is already root. 79 This option is only available on systems with BSD login 80 classes. 81 In the `sudo -c- CMD` case, I understand that the user the command is run as is a synonym of the previous target user term; NAME in `sudo -uNAME CMD` or root. In spite both of these, it's the calling user's loginclass that is effective. The patch below attempts to aligns sudo with the documentation. I have no idea if it causes unwarranted privileges to be granted later on in the call stack. Alternatively, the documentation should be fixed to reflect the less useful and counter-intuitive current bevahiour. diff --git a/usr.bin/sudo/sudo.c b/usr.bin/sudo/sudo.c index a299bdc..650c41a 100644 --- a/usr.bin/sudo/sudo.c +++ b/usr.bin/sudo/sudo.c @@ -305,7 +305,7 @@ main(argc, argv, envp) log_error(NO_STDERR|NO_EXIT, problem with defaults entries); /* Set login class if applicable. */ -set_loginclass(sudo_user.pw); +set_loginclass(runas_pw); /* Update initial shell now that runas is set. */ if (ISSET(sudo_mode, MODE_LOGIN_SHELL))
Re: kern decrement
On Tue, Mar 19, 2013 at 10:47 AM, Ted Unangst t...@tedunangst.com wrote:
Maybe we want, maybe we don't. Here's a check to prevent a counter
from going negative, which usually means an accounting mistake
somewhere. On the shortcomiing side, it only catches double
decrements, not missing decrements, so maybe it's not worthwhile.
Anyway, it was like five minutes to make, figured I'd show it.
Index: lib/libkern/libkern.h
===
RCS file: /cvs/src/sys/lib/libkern/libkern.h,v
retrieving revision 1.29
diff -u -p -r1.29 libkern.h
--- lib/libkern/libkern.h 26 Apr 2012 01:22:31 - 1.29
+++ lib/libkern/libkern.h 19 Mar 2013 15:10:41 -
@@ -116,14 +116,11 @@ abs(int j)
#ifndef DIAGNOSTIC
#defineKASSERT(e) ((void)0)
+#define DECREMENT(x) x--
why not (x)--?
#else
-#ifdef __STDC__
#defineKASSERT(e) ((e) ? (void)0 :
\
__assert(diagnostic , __FILE__, __LINE__, #e))
-#else
-#defineKASSERT(e) ((e) ? (void)0 :
\
- __assert(diagnostic , __FILE__, __LINE__, e))
-#endif
+#define DECREMENT(x) decrement_checked((x)--, __FILE__, __LINE__, #x)
why (x)-- instead of x-- as before?
#endif
#ifndef DEBUG
@@ -141,6 +138,7 @@ abs(int j)
/* Prototypes for non-quad routines. */
void__assert(const char *, const char *, int, const char *)
__attribute__ ((__noreturn__));
+int64_t decrement_checked(int64_t, const char *, int, const char *);
why not intmax_t instead of int64_t?
int bcmp(const void *, const void *, size_t);
voidbzero(void *, size_t);
voidexplicit_bzero(void *, size_t);
Index: kern/subr_prf.c
===
RCS file: /cvs/src/sys/kern/subr_prf.c,v
retrieving revision 1.76
diff -u -p -r1.76 subr_prf.c
--- kern/subr_prf.c 3 Apr 2011 16:46:19 - 1.76
+++ kern/subr_prf.c 19 Mar 2013 15:13:27 -
@@ -161,6 +161,14 @@ __assert(const char *t, const char *f, i
t, e, f, l);
}
+int64_t
+decrement_checked(int64_t x, const char *f, int l, const char *e)
+{
+ if (x = 0)
+ __assert(decrement , f, l, e);
+ return x;
+}
+
/*
* tablefull: warn that a system table is full
*/
Index: kern/vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.146
diff -u -p -r1.146 vfs_bio.c
--- kern/vfs_bio.c 17 Feb 2013 17:39:29 - 1.146
+++ kern/vfs_bio.c 19 Mar 2013 15:12:12 -
@@ -129,7 +129,7 @@ bremfree(struct buf *bp)
bcstats.numcleanpages -= atop(bp-b_bufsize);
} else {
bcstats.numdirtypages -= atop(bp-b_bufsize);
- bcstats.delwribufs--;
+ DECREMENT(bcstats.delwribufs);
}
TAILQ_REMOVE(dp, bp, b_freelist);
}
@@ -155,7 +155,7 @@ buf_put(struct buf *bp)
#endif
LIST_REMOVE(bp, b_list);
- bcstats.numbufs--;
+ DECREMENT(bcstats.numbufs);
if (buf_dealloc_mem(bp) != 0)
return;
@@ -1221,9 +1221,9 @@ biodone(struct buf *bp)
if (bcstats.numbufs
(!(ISSET(bp-b_flags, B_RAW) || ISSET(bp-b_flags, B_PHYS {
if (!ISSET(bp-b_flags, B_READ))
- bcstats.pendingwrites--;
+ DECREMENT(bcstats.pendingwrites);
else
- bcstats.pendingreads--;
+ DECREMENT(bcstats.pendingreads);
}
if (ISSET(bp-b_flags, B_CALL)) { /* if necessary, call out */
CLR(bp-b_flags, B_CALL); /* but note callout done */
Re: LC_CTYPE for spanish speaking countries
On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling s...@openbsd.org wrote:
On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote:
+#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language
+ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE
Sorry, but I don't really see the point of this.
All these names are going to map to the same ctype definitions.
That just clutters the /usr/share/locale directory. Why can't people
just use es_ES?
Because that's wrong. es_VE for ctype alone won't make a difference,
but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are
different. And dictionary files (e.g., spellings for common cities)
are also different.
The way you specify locales, ll_CC.CHARTYPE, where ll is language and
CC is country-code, is unfortunate because it makes unnecesary
duplication for fields where it shouldn't make a difference, like
ctype, but that's just the way it is
I don't think locale names are standardized, so there should be nothing
that forces us to support a certain set of locale names.
+ES_ENCODINGS= ISO8859-1 ISO8859-15 UTF-8
+.for c in ${ES_COUNTRIES}
+LOCALES += es_${c}.UTF-8
+LOCALESRC_es_${c}.UTF-8 = en_US.UTF-8
+LOCALES += es_${c}.ISO8859-1
+LOCALESRC_es_${c}.ISO8859-1 = en_US.ISO_8859-1
+LOCALES += es_${c}.ISO8859-15
+LOCALESRC_es_${c}.ISO8859-15 = en_US.DIS_8859-15
+.endfor
LOCALES += fa_IR.UTF-8
LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
Re: LC_CTYPE for spanish speaking countries
Instead of perpetuating the idea that the number of locales is a precious resource tied to directory entries, the routines could parse the user supplied string instead of working with a table of all possible permutations of ll_CC.CTYPE. This means simplification for the build system, simplification for those reasoning about what the structure representing a locale should look like, and it also adds features without calling for a cliche, tower of babel discussion. Every field enclosed in brackets denotes the parameter(s) to the LC_ function on the LHS: LC_COLLATE=[ll]_CC.[CTYPE] LC_CTYPE=ll_CC.[CTYPE] LC_MONETARY=ll_[CC].CTYPE LC_NUMERIC=ll_[CC].CTYPE LC_TIME=ll_[CC].CTYPE LC_MESSAGES=[ll]_[CC].CTYPE That means that they can be indices to separate flat tables. N.B. POSIX says that locales don't need to map to directories, so why try to fit this into an expanded hierarchical structure when it's clearly not made for it?
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 7:12 AM, Stefan Sperling s...@openbsd.org wrote: On Fri, Mar 22, 2013 at 06:54:24AM -0430, Andres Perera wrote: Instead of perpetuating the idea that the number of locales is a precious resource tied to directory entries, the routines could parse the user supplied string instead of working with a table of all possible permutations of ll_CC.CTYPE. This means simplification for the build system, simplification for those reasoning about what the structure representing a locale should look like, and it also adds features without calling for a cliche, tower of babel discussion. Every field enclosed in brackets denotes the parameter(s) to the LC_ function on the LHS: LC_COLLATE=[ll]_CC.[CTYPE] LC_CTYPE=ll_CC.[CTYPE] LC_MONETARY=ll_[CC].CTYPE LC_NUMERIC=ll_[CC].CTYPE LC_TIME=ll_[CC].CTYPE LC_MESSAGES=[ll]_[CC].CTYPE That means that they can be indices to separate flat tables. Where is your patch series that implements this in a backwards-compatible fashion, in small steps that get us from here to there? I like the idea of uncoupling locales names from the /usr filesystem a lot. Well, that's just the incentive I needed! But if it is just an idea it is not as tangible as the patches that Vladimir is submitting, so it isn't something I can afford to pay attention to during the limited amount of time I have for OpenBSD development. As you've picked up on, I have nothing to show for now... hopefully my changes won't interfere.
Re: [patch] tic man page file path error
i see now that src/lib/libcurses has other defines for tic, i apologize to both
src `make obj` wrongly uses dirs instead of symlinks
When BSDSRCDIR is set through /etc/mk.conf or ${MAKECONF} to something
other than the default of /usr/src, make obj won't use symlinks for
`obj' in the affected directories.
Index: distrib/luna88k/Makefile.inc
===
RCS file: /cvs/src/distrib/luna88k/Makefile.inc,v
retrieving revision 1.1
diff -p -u -r1.1 Makefile.inc
--- distrib/luna88k/Makefile.inc21 Apr 2004 18:40:18 - 1.1
+++ distrib/luna88k/Makefile.inc23 Apr 2013 01:30:56 -
@@ -3,7 +3,3 @@
REV=${OSrev}
LDSTATIC=-static
-
-# Hack needed to find kernel images...
-BSDSRCDIR?=/usr/src
-SRCSYSDIR?=${BSDSRCDIR}/sys
Index: distrib/mvme68k/Makefile.inc
===
RCS file: /cvs/src/distrib/mvme68k/Makefile.inc,v
retrieving revision 1.3
diff -p -u -r1.3 Makefile.inc
--- distrib/mvme68k/Makefile.inc24 Jan 2000 04:50:25 - 1.3
+++ distrib/mvme68k/Makefile.inc23 Apr 2013 01:30:56 -
@@ -3,7 +3,3 @@
REV=${OSrev}
LDSTATIC= -static
-
-# Hack needed to find kernel images...
-BSDSRCDIR?=/usr/src
-SRCSYSDIR?=${BSDSRCDIR}/sys
Index: distrib/mvme88k/Makefile.inc
===
RCS file: /cvs/src/distrib/mvme88k/Makefile.inc,v
retrieving revision 1.2
diff -p -u -r1.2 Makefile.inc
--- distrib/mvme88k/Makefile.inc7 Aug 2003 20:57:03 - 1.2
+++ distrib/mvme88k/Makefile.inc23 Apr 2013 01:30:56 -
@@ -3,7 +3,3 @@
REV=${OSrev}
LDSTATIC=-static
-
-# Hack needed to find kernel images...
-BSDSRCDIR?=/usr/src
-SRCSYSDIR?=${BSDSRCDIR}/sys
Re: switch /usr/share/locale to different layout
On Thu, May 30, 2013 at 3:35 PM, Stefan Sperling s...@openbsd.org wrote:
I've received several requests for adding new locale names,
both on this list, and off-list, from several people.
I've been trying to find a way to keep /usr/share/locale reasonably
clean while also allowing people to use their preferred locale names.
Currently, the list of supported locale names is represented by the
list of directories in /usr/share/locale. I don't think we should
continue to maintain a list of language_country.encoding names
because such a list cannot be maintained properly.
Some requests that have been made are non-functional changes.
E.g. adding a country doesn't have a functional effect on OpenBSD.
Still, some users would like to use names containing
theirlanguage_theircountry, for whatever reason.
There have also been requests for supporting locale names such
as C.UTF-8. I'm not sure what the use case is but as a side-effect
of the proposal below such names would also be possible.
The inclusion of C.UTF-8 and POSIX.UTF-8 to their respective standards
has a greater chance of acceptance than the almost-functionally
equivalent en_US.UTF-8. If I define the first two in terms of
en_US.UTF-8 as implemented in various BSD and glibc, the only
difference is sorting order.
POSIX doesn't specify how files in /usr/share/locale are stored.
bluhm@ suggested to change the filesystem layout such that encoding
and language are separated. libc will look up locale definition data at
specific places depending on which of the LC_* categories is being set.
LC_CTYPE support code needs to look at the character encoding only.
It only cares about the encoding part of the locale name, which by
convention is the substring after the last dot in the locale name.
Actually, several assertions regarding file structure take place in
the library routines, which you haven't modified in your patch.
The suggested new layout looks like this:
/usr/share/locale/UTF-8/LC_CTYPE
/usr/share/locale/CP1251/LC_CTYPE
/usr/share/locale/ISO8859-1/LC_CTYPE
/usr/share/locale/ISO8859-15/LC_CTYPE
/usr/share/locale/ISO8859-2/LC_CTYPE
/usr/share/locale/ISO8859-7/LC_CTYPE
/usr/share/locale/ARMSCII-8/LC_CTYPE
/usr/share/locale/ISO8859-4/LC_CTYPE
/usr/share/locale/ISO8859-13/LC_CTYPE
/usr/share/locale/CP866/LC_CTYPE
/usr/share/locale/KOI8-R/LC_CTYPE
/usr/share/locale/ISO8859-5/LC_CTYPE
/usr/share/locale/KOI8-U/LC_CTYPE
All other files and directories currently in /usr/share/locale
can be removed.
If we later add support for language- or country-specific features
such as LC_COLLATE we can add directories for every language the
collation code supports:
/usr/share/locale/en/LC_COLLATE
/usr/share/locale/es/LC_COLLATE
/usr/share/locale/de/LC_COLLATE
Or even add country names, if necessary and supported by the
hypothetical collation code:
/usr/share/locale/it_IT/LC_COLLATE
/usr/share/locale/it_CH/LC_COLLATE
I did some research a few months ago on the optimal layout for
collation, transliteration, and date/misc formatting:
Cytrus systems don't seem to peruse CLDR, which covers quite alot, and
indexes certain data by cc_LL because it's not transient between
different countries that feature the same language. Since OpenBSD libc
doesn't cover such localization, and it's extremely unlikely that it
will in the near future, it's safe to say that the first hierarchy is
an ok investment.
Does anyone see problems with this plan?
As I mentioned, there's code that expects the prior layout, and that's
confusing.
on src/lib/libc/locale/setlocale.c, load_locale_sub() :
228 len = snprintf(name, sizeof(name), %s/%s/%s,
229 _PATH_LOCALE, locname, categories[category]);
230 if (len 0 || len = sizeof(name))
231 return -1;
on src/lib/libc/locale/setrunelocale.c, _xpg4_setrunelocale():
184 len = snprintf(path, sizeof(path),
185 %s/%s/LC_CTYPE, _PATH_LOCALE, encoding);
186 if (len 0 || len = sizeof(path))
187 return ENAMETOOLONG;
Index: share/locale/ctype/Makefile
===
RCS file: /cvs/src/share/locale/ctype/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
[...]
Index: lib/libc/locale/setrunelocale.c
===
RCS file: /cvs/src/lib/libc/locale/setrunelocale.c,v
retrieving revision 1.9
diff -u -p -r1.9 setrunelocale.c
--- lib/libc/locale/setrunelocale.c 30 May 2013 18:35:55 - 1.9
+++ lib/libc/locale/setrunelocale.c 30 May 2013 19:23:16 -
@@ -171,17 +171,27 @@ found:
}
int
-_xpg4_setrunelocale(const char *encoding)
+_xpg4_setrunelocale(const char *locname)
{
char path[PATH_MAX];
_RuneLocale *rl;
int error, len;
+ const char *dot, *encoding;
-
Re: switch /usr/share/locale to different layout
On Thu, May 30, 2013 at 11:49 PM, Stefan Sperling s...@openbsd.org wrote:
On Thu, May 30, 2013 at 05:18:48PM -0430, Andres Perera wrote:
As I mentioned, there's code that expects the prior layout, and that's
confusing.
on src/lib/libc/locale/setlocale.c, load_locale_sub() :
228 len = snprintf(name, sizeof(name), %s/%s/%s,
229 _PATH_LOCALE, locname, categories[category]);
230 if (len 0 || len = sizeof(name))
231 return -1;
Right, thanks for pointing this out.
I think the above check can just be removed.
It seems to serve no purpose other than making sure that the path
constructed from _PATH_LOCALE and the locname argument doesn't
exceed PATH_MAX. This is redundant because the same check is
performed again within _xpg4_setrunelocale(). If we assume that functions
handling other LC_* categories might use different paths in the future,
it makes sense to perform this overflow check only inside of the
LC_*-specific functions, rather than upfront.
Besides being redundant, it's generally better to bail on open() error
instead of checking if the length is less than PATH_MAX in
anticipation.
[Unrelated to your patch, but since we are on the subject of path
checks in setlocale()...]
However, since the routines also use locale data paths as keys for a
dynamically allocated cache of their contents, a single check should
persist. This raises an unrelated issue about the cache index: since
libc doesn't support arbitrary paths for locale files, there's no need
to index the cache by full locale data paths because all of the paths
are anchored at _PATH_LOCALE.
on src/lib/libc/locale/setrunelocale.c, _xpg4_setrunelocale():
184 len = snprintf(path, sizeof(path),
185 %s/%s/LC_CTYPE, _PATH_LOCALE, encoding);
186 if (len 0 || len = sizeof(path))
187 return ENAMETOOLONG;
This section is modified as part of my diff, isn't it?
Sorry, this assertion remains correct after your diff so there was no
need for me to list it.
In any case, it's also redundant and should be zapped to prevent
further confusion. There's yet another (x PATH_MAX) check--making it
the third one--which is a better candidate to keep due to its coupling
with the cache population logic:
125 int
126 _newrunelocale(const char *path)
127 {
128 struct localetable *lt;
129 FILE *fp;
130 _RuneLocale *rl;
131
132 if (strlen(path) + 1 sizeof(lt-path))
133 return EINVAL;
+ /* Assume whatever.encoding locale name. */
There should be some notion of syntax for cc_LL.CTYPE, even if only
mentioned in comments.
E.g.,
ISO 3166-1 for country codes and BCP 47 for language tags.
glibc did not do this and directly because of that it's a mess to
navigate their structure.
You mean we should specify encoding name syntax in a comment?
If so, my answer would be that recognized encoding names are
specified by filenames we use in /usr/share/locale. A comment
documenting the same would risk becoming obsolete over time.
Updated diff, with the redundant check removed:
[...]
Re: Ralink RT3090 should work now
On Sun, Oct 24, 2010 at 11:14 AM, Andres Perera andre...@zoho.com wrote: On Sat, Oct 23, 2010 at 10:02 AM, Damien Bergamini damien.bergam...@free.fr wrote: I finally found some time to finish RT3090 support in ral(4). If you have such a device, please test the driver in -current and report success/failure directly to me. Haven't tested it yet, but thanks a ton anyway. Will report as soon as I finish syncing cvs. Works great, thanks again.
less stupid kshrc example
Defining a bunch of functions just to update the term title is
ridiculous.
--- src/etc/ksh.kshrc.orig Fri Oct 29 21:40:51 2010
+++ src/etc/ksh.kshrc Fri Oct 29 21:51:48 2010
@@ -45,16 +45,7 @@
HOSTNAME=${HOSTNAME:-`uname -n`}
HOST=${HOSTNAME%%.*}
- PROMPT=$USER:!$PS1S
- #PROMPT=$u...@$host:!$PS1S
- PPROMPT='$USER:$PWD:!'$PS1S
- #PPROMPT='$u...@$host:$PWD:!'$PS1S
- PS1=$PPROMPT
- # $TTY is the tty we logged in on,
- # $tty is that which we are in now (might by pty)
- tty=`tty`
- tty=`basename $tty`
- TTY=${TTY:-$tty}
+ PS1='\...@\h:\w \$ '
set -o emacs
@@ -70,82 +61,29 @@
;;
esac
case $TERM in
- sun*-s)
- # sun console with status line
- if [ $tty != $console ]; then
- # ilabel
- ILS='\033]L'; ILE='\033\\'
- # window title bar
- WLS='\033]l'; WLE='\033\\'
- fi
+ dtterm*|screen*|rxvt*|xterm*)
+ ILS=\e]1;
+ ILE=\a
+ WLS=\e]2;
+ WLE=\a
;;
- xterm*)
- ILS='\033]1;'; ILE='\007'
- WLS='\033]2;'; WLE='\007'
- parent=`ps -ax 2/dev/null | grep $PPID | grep -v grep`
- case $parent in
- *telnet*)
- export TERM=xterms;;
- esac
+ ''|dumb|vt220)
+ true
;;
- *) ;;
+ *)
+ if tput hs /dev/null 21; then
+ WLS=`tput ts`
+ WLE=`tput fs`
+ fi
+ ;;
esac
- # do we want window decorations?
- if [ $ILS ]; then
- ilabel () { print -n ${ILS}$*${ILE}/dev/tty; }
- label () { print -n ${WLS}$*${WLE}/dev/tty; }
-
- alias stripe='label $u...@$host ($tty) - $PWD'
- alias istripe='ilabel $u...@$host ($tty)'
-
- wftp () { ilabel ftp $*; ftp $@; eval istripe; }
- wcd () { \cd $@ eval stripe; }
- wssh ()
- {
- local rc
- ssh $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wtelnet ()
- {
- local rc
- telnet $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wrlogin ()
- {
- local rc
- rlogin $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wsu ()
- {
- local rc
- su $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- alias su=wsu
- alias cd=wcd
- alias ftp=wftp
- alias ssh=wssh
- alias telnet=wtelnet
- alias rlogin=wrlogin
- eval stripe
- eval istripe
- PS1=$PROMPT
+ if [ -n $ILS ]; then
+ PS1=$ps1\[$il...@\h$ile\]
fi
+ if [ -n $WLS ]; then
+ PS1=$ps1\[$wl...@\h \w$WLE\]
+ fi
+ unset ILS ILE WLS WLE
alias quit=exit
alias cls=clear
alias logout=exit
Re: less stupid kshrc example
2010-10-30 14:34 +0100, Stuart Henderson: On 2010/10/29 21:55, Andres Perera wrote: Defining a bunch of functions just to update the term title is ridiculous. I use this. Also it's a good way to find bugs in cwm :) Not sure how it would help, but the title still changes, just not with independent functions. It doesn't work with set -o sh, though, since it doesn't evaluate PS1 escapes in this mode. In that case ksh.kshrc shouldn't be sourced anyway.
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 14, 2010 at 5:54 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: I have received a mail regarding the early development of the OpenBSD IPSEC stack. B It is alleged that some ex-developers (and the company they worked for) accepted US government money to put backdoors into our network stack, in particular the IPSEC stack. B Around 2000-2001. Funny how this happened right after the massive wiki leaks. It worked though, most people fell for it.
