Bug in command line switch parsing in lpr.c
Hi, In usr.sbin/lpr/lpr/lpr.c there isn't a break in the case for '#' when there should be. Here's a patch to fix it from writing a pointer where it shouldn't. Thanks! --- lpr.c 2009-10-29 00:34:48.0 -0400 +++ lpr.patched.c 2013-02-14 17:46:28.364251608 -0500 @@ -150,6 +150,7 @@ if (i > 0) ncopies = i; } + break; case '4': /* troff fonts */ case '3':
Re: Security and ignorance from the major ISPs
On 02/14/2013 06:40 PM, Ryan Freeman wrote On Thu, Feb 14, 2013 at 04:20:30PM -0700, Daniel Bertrand wrote: Hello, Thanks for providing such great software. It really is much appreciated. I was wondering what your stance is about the constant hack attempts on machines on our ISP networks.. I see CONSTANT scanning for ports from all over the world, mostly from Italy, Russia, and China. yeah i see this daily. doesn't matter, they never get anywhere. Every firewall/router product that I have purchased has been compromised so far. Is there really a secure, trustworthy adaptive filtering firewall configuration for each OS configuration out there? l block all is the right place to start from adaptive??? adapt to what??? if you can't define that, the problem is undefined and impossible to solve. then: what unsolicited incoming packets do you want? for user systems, (especially u$soft ones) NONE. for server systems, what services do you need to expose? only the incoming ports associated with those services. you should consider allowing ICMP echo (ping) and traceroute (UDP) to your domain.xxx and/or www.domain.xxx addresses. outgoing connections? from secure systems, allow all is probably OK - though blocking packets to useless "privileged" ports is probably a good idea. there is very little you can do if a system inside your firewall is infected. subnets can help you: for instance, only allowing requests to port 80 from users will defeat some portion of dangerous packets. any use of micro$oft inside your firewall is very dangerous - that software is, by architecture and design, impossible to make secure. any system using u$soft software must be regarded as insecure at all times. Programs like skype, etc. which use proprietary packet formats are inherently security failures. The internet is an extremely hostile place. "need to know" and "need to access" must be your rules. block everything else. geoff steckel
Re: Security and ignorance from the major ISPs
I'd reccomend http://www.openbsd.org/books.html#book8 It's a very good way to learn pf enough to deal with it. On Thu, Feb 14, 2013 at 4:20 PM, Daniel Bertrand wrote: > Hello, > > Thanks for providing such great software. It really is much appreciated. > > I was wondering what your stance is about the constant hack attempts on > machines on our ISP networks.. > > I see CONSTANT scanning for ports from all over the world, mostly from Italy, > Russia, and China. > > Every firewall/router product that I have purchased has been compromised so > far. > > Is there really a secure, trustworthy adaptive filtering firewall > configuration for each OS configuration out there? > > > Most people who are on the net are completely oblivious and helpless when it > comes to this constant trolling for access, they have no idea what to do to > secure their machines. > > > Shaw has neglected me and left me for dead when I ask for better control and > protection from malicious attackers. > > > What do I do to make sure I don't spend money on new hardware but get a PF > configuration that I can trust besides "block in all"? > > Are there published rulesets for Mac/Windows etc. that we can just drop into > our pf.conf and /etc/pf.anchors/ directory? > > Regards, > > Dan >
Re: Security and ignorance from the major ISPs
On Thu, Feb 14, 2013 at 04:20:30PM -0700, Daniel Bertrand wrote: > Hello, > > Thanks for providing such great software. It really is much appreciated. > > I was wondering what your stance is about the constant hack attempts on > machines on our ISP networks.. > > I see CONSTANT scanning for ports from all over the world, mostly from Italy, > Russia, and China. yeah i see this daily. doesn't matter, they never get anywhere. > Every firewall/router product that I have purchased has been compromised so > far. > > Is there really a secure, trustworthy adaptive filtering firewall > configuration for each OS configuration out there? > learning the pf ruleset and configuring to your needs seems to work pretty well. > Most people who are on the net are completely oblivious and helpless when it > comes to this constant trolling for access, they have no idea what to do to > secure their machines. > > Shaw has neglected me and left me for dead when I ask for better control and > protection from malicious attackers. you want the isp selectively blocking traffic for you? i don't. > What do I do to make sure I don't spend money on new hardware but get a PF > configuration that I can trust besides "block in all"? > > Are there published rulesets for Mac/Windows etc. that we can just drop into > our pf.conf and /etc/pf.anchors/ directory? it sounds like you just want a magic working result from no real effort. maybe thats why your purchased firewalls didn't work out, you bought them, drop them in and expect it to just take care of issues regardless of user activity? shrug, sounds like a case of i don't want to do the work but i'm sure someone else does it for me, not really gonna get anywhere. > > Regards, > > Dan >
Security and ignorance from the major ISPs
Hello, Thanks for providing such great software. It really is much appreciated. I was wondering what your stance is about the constant hack attempts on machines on our ISP networks.. I see CONSTANT scanning for ports from all over the world, mostly from Italy, Russia, and China. Every firewall/router product that I have purchased has been compromised so far. Is there really a secure, trustworthy adaptive filtering firewall configuration for each OS configuration out there? Most people who are on the net are completely oblivious and helpless when it comes to this constant trolling for access, they have no idea what to do to secure their machines. Shaw has neglected me and left me for dead when I ask for better control and protection from malicious attackers. What do I do to make sure I don't spend money on new hardware but get a PF configuration that I can trust besides "block in all"? Are there published rulesets for Mac/Windows etc. that we can just drop into our pf.conf and /etc/pf.anchors/ directory? Regards, Dan
Re: install(1) confusing error message
Yes. absolutely.. ok
On Thu, Feb 14, 2013 at 1:38 PM, Miod Vallat wrote:
> This is what happens when install(1) is used to install files on a
> read-only filesystem:
>
> # mount -u -o ro /usr
> # cd /usr/src
> # make build
> cd /usr/src/share/mk && exec make install
> install -c -o root -g bin -m 444 bsd.README bsd.dep.mk bsd.lib.mk bsd.man.mk
> bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.port.arch.mk bsd.port.mk
> bsd.port.subdir.mk bsd.prog.mk bsd.regress.mk bsd.subdir.mk bsd.sys.mk
> sys.mk bsd.lkm.mk bsd.xconf.mk bsd.xorg.mk /usr/share/mk
> install: /usr/share/mk/bsd.README: File exists
> *** Error 71 in share/mk (Makefile:13 'install')
> *** Error 1 in /usr/src (Makefile:78 'build')
> #
>
> Not really helpful. With the diff below, I will now get:
>
> install: /usr/share/mk/bsd.README: Read-only file system
>
> which helps figuring out what is wrong.
>
> Miod
>
> Index: xinstall.c
> ===
> RCS file: /cvs/src/usr.bin/xinstall/xinstall.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 xinstall.c
> --- xinstall.c 14 Sep 2012 00:00:29 - 1.52
> +++ xinstall.c 14 Feb 2013 20:32:21 -
> @@ -639,8 +639,10 @@ create_newfile(char *path, struct stat *
> /* It is ok for the target file not to exist. */
> if (rename(path, backup) < 0 && errno != ENOENT)
> err(EX_OSERR, "rename: %s to %s (errno %d)", path,
> backup, errno);
> - } else
> - (void)unlink(path);
> + } else {
> + if (unlink(path) < 0 && errno != ENOENT)
> + err(EX_OSERR, "%s", path);
> + }
>
> return(open(path, O_CREAT | O_RDWR | O_EXCL, S_IRUSR | S_IWUSR));
> }
>
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
> > a section of athn.4 manpage is fluff, information is repeated twice. once > > in words, other times in a table summarizing the list of working/supported > > chips. the same manpage was copied over for iwn, a table of supported chips > > would be nice in there too. if there's any interest i will sit down and > > submit a manpage diff. > > all diffs welcome. > jmc > i just tried to duplicate the words into the table. any suggestions? Index: athn.4 === RCS file: /cvs/src/share/man/man4/athn.4,v retrieving revision 1.22 diff -u -p -r1.22 athn.4 --- athn.4 14 Feb 2013 07:40:42 - 1.22 +++ athn.4 14 Feb 2013 22:14:17 - @@ -100,23 +100,26 @@ The following table summarizes the suppo .It "AR5008-3NG (AR5416+AR2133)" Ta 2GHz Ta 3x3:2 Ta PCI/CardBus .It "AR5008-2NX (AR5416+AR5122)" Ta 2GHz/5GHz Ta 2x2:2 Ta PCI/CardBus .It "AR5008-3NX (AR5416+AR5133)" Ta 2GHz/5GHz Ta 3x3:2 Ta PCI/CardBus -.It "AR5008E-2NG (AR5418+AR2122)" Ta 2GHz Ta 2x2:2 Ta PCIe -.It "AR5008E-3NG (AR5418+AR2133)" Ta 2GHz Ta 3x3:2 Ta PCIe -.It "AR5008E-2NX (AR5418+AR5122)" Ta 2GHz/5GHz Ta 2x2:2 Ta PCIe -.It "AR5008E-3NX (AR5418+AR5133)" Ta 2GHz/5GHz Ta 3x3:2 Ta PCIe -.It "AR9001-2NG (AR9160+AR9103)" Ta 2GHz Ta 2x2:2 Ta PCI -.It "AR9001-3NG (AR9160+AR9103)" Ta 2GHz Ta 3x3:2 Ta PCI -.It "AR9001-3NX2 (AR9160+AR9106)" Ta 2GHz/5GHz Ta 3x3:2 Ta PCI -.It "AR9220" Ta 2GHz/5GHz Ta 2x2:2 Ta PCI -.It "AR9223" Ta 2GHz Ta 2x2:2 Ta PCI -.It "AR9280" Ta 2GHz/5GHz Ta 2x2:2 Ta PCIe +.It "AR5008E-2NG (AR5418+AR2122)" Ta 2GHz Ta 2x2:2 Ta Mini PCIe +.It "AR5008E-3NG (AR5418+AR2133)" Ta 2GHz Ta 3x3:2 Ta Mini PCIe +.It "AR5008E-2NX (AR5418+AR5122)" Ta 2GHz/5GHz Ta 2x2:2 Ta Mini PCIe +.It "AR5008E-3NX (AR5418+AR5133)" Ta 2GHz/5GHz Ta 3x3:2 Ta Mini PCIe +.It "AR9001-2NG (AR9160+AR9103)" Ta 2GHz Ta 2x2:2 Ta Mini PCI +.It "AR9001-3NG (AR9160+AR9103)" Ta 2GHz Ta 3x3:2 Ta Mini PCI +.It "AR9001-3NX2 (AR9160+AR9106)" Ta 2GHz/5GHz Ta 3x3:2 Ta Mini PCI +.It "AR9220" Ta 2GHz/5GHz Ta 2x2:2 Ta PCI/Mini PCI +.It "AR9223" Ta 2GHz Ta 2x2:2 Ta PCI/Mini PCI +.It "AR9280" (XB92) Ta 2GHz/5GHz Ta 2x2:2 Ta Mini PCIe +.It "AR9280" (HB92) Ta 2GHz/5GHz Ta 2x2:2 Ta half Mini PCIe .It "AR9280+AR7010" Ta 2GHz/5GHz Ta 2x2:2 Ta USB 2.0 -.It "AR9281" Ta 2GHz Ta 1x2:2 Ta PCIe -.It "AR9285" Ta 2GHz Ta 1x1:1 Ta PCIe +.It "AR9281" (XB91) Ta 2GHz Ta 1x2:2 Ta Mini PCIe +.It "AR9281" (HB91) Ta 2GHz Ta 1x2:2 Ta half Mini PCIe +.It "AR9285" Ta 2GHz Ta 1x1:1 Ta half Mini PCIe +.It "AR9285+AR3011" Ta 2GHz Ta 1x1:1 Ta half Mini PCIe .It "AR9271" Ta 2GHz Ta 1x1:1 Ta USB 2.0 -.It "AR2427" Ta 2GHz Ta 1x1:1 Ta PCIe -.It "AR9227" Ta 2GHz Ta 2x2:2 Ta PCI -.It "AR9287" Ta 2GHz Ta 2x2:2 Ta PCIe +.It "AR2427" Ta 2GHz Ta 1x1:1 Ta Mini PCIe +.It "AR9227" Ta 2GHz Ta 2x2:2 Ta PCI/Mini PCI +.It "AR9287" Ta 2GHz Ta 2x2:2 Ta half Mini PCIe .It "AR9287+AR7010" Ta 2GHz Ta 2x2:2 Ta USB 2.0 .El .Pp
Re: install(1) confusing error message
On Thu, Feb 14, 2013 at 08:38:02PM +, Miod Vallat wrote:
> This is what happens when install(1) is used to install files on a
> read-only filesystem:
>
> # mount -u -o ro /usr
> # cd /usr/src
> # make build
> cd /usr/src/share/mk && exec make install
> install -c -o root -g bin -m 444 bsd.README bsd.dep.mk bsd.lib.mk bsd.man.mk
> bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.port.arch.mk bsd.port.mk
> bsd.port.subdir.mk bsd.prog.mk bsd.regress.mk bsd.subdir.mk bsd.sys.mk
> sys.mk bsd.lkm.mk bsd.xconf.mk bsd.xorg.mk /usr/share/mk
> install: /usr/share/mk/bsd.README: File exists
> *** Error 71 in share/mk (Makefile:13 'install')
> *** Error 1 in /usr/src (Makefile:78 'build')
> #
>
> Not really helpful. With the diff below, I will now get:
>
> install: /usr/share/mk/bsd.README: Read-only file system
>
> which helps figuring out what is wrong.
>
> Miod
>
> Index: xinstall.c
> ===
> RCS file: /cvs/src/usr.bin/xinstall/xinstall.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 xinstall.c
> --- xinstall.c14 Sep 2012 00:00:29 - 1.52
> +++ xinstall.c14 Feb 2013 20:32:21 -
> @@ -639,8 +639,10 @@ create_newfile(char *path, struct stat *
> /* It is ok for the target file not to exist. */
> if (rename(path, backup) < 0 && errno != ENOENT)
> err(EX_OSERR, "rename: %s to %s (errno %d)", path,
> backup, errno);
> - } else
> - (void)unlink(path);
> + } else {
> + if (unlink(path) < 0 && errno != ENOENT)
> + err(EX_OSERR, "%s", path);
> + }
>
> return(open(path, O_CREAT | O_RDWR | O_EXCL, S_IRUSR | S_IWUSR));
> }
>
Makes sense to me.
Ken
mg(1) M-{} line number fix
Fix forward-paragraph and backward-paragraph's handling of line
numbers.
ok?
-lum
Index: paragraph.c
===
RCS file: /cvs/src/usr.bin/mg/paragraph.c,v
retrieving revision 1.22
diff -u -p -r1.22 paragraph.c
--- paragraph.c 29 Nov 2011 05:59:54 - 1.22
+++ paragraph.c 14 Feb 2013 20:35:18 -
@@ -41,9 +41,10 @@ gotobop(int f, int n)
if (llength(lback(curwp->w_dotp)) &&
lgetc(curwp->w_dotp, 0) != ' ' &&
lgetc(curwp->w_dotp, 0) != '.' &&
- lgetc(curwp->w_dotp, 0) != '\t')
+ lgetc(curwp->w_dotp, 0) != '\t') {
curwp->w_dotp = lback(curwp->w_dotp);
- else {
+ curwp->w_dotline--;
+ } else {
if (llength(lback(curwp->w_dotp)) &&
lgetc(curwp->w_dotp, 0) == '.') {
curwp->w_dotp = lforw(curwp->w_dotp);
@@ -56,6 +57,7 @@ gotobop(int f, int n)
lback(curwp->w_dotp);
curwp->w_doto =
llength(curwp->w_dotp);
+ curwp->w_dotline--;
}
}
break;
@@ -93,9 +95,10 @@ gotoeop(int f, int n)
if (llength(curwp->w_dotp) &&
lgetc(curwp->w_dotp, 0) != ' ' &&
lgetc(curwp->w_dotp, 0) != '.' &&
- lgetc(curwp->w_dotp, 0) != '\t')
+ lgetc(curwp->w_dotp, 0) != '\t') {
curwp->w_dotp = lforw(curwp->w_dotp);
- else
+ curwp->w_dotline++;
+ } else
break;
}
if (curwp->w_dotp == curbp->b_headp) {
@@ -103,7 +106,8 @@ gotoeop(int f, int n)
curwp->w_dotp = lback(curwp->w_dotp);
curwp->w_doto = llength(curwp->w_dotp);
break;
- }
+ } else
+ curwp->w_dotline++;
}
/* force screen update */
curwp->w_rflag |= WFMOVE;
install(1) confusing error message
This is what happens when install(1) is used to install files on a
read-only filesystem:
# mount -u -o ro /usr
# cd /usr/src
# make build
cd /usr/src/share/mk && exec make install
install -c -o root -g bin -m 444 bsd.README bsd.dep.mk bsd.lib.mk bsd.man.mk
bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.port.arch.mk bsd.port.mk
bsd.port.subdir.mk bsd.prog.mk bsd.regress.mk bsd.subdir.mk bsd.sys.mk sys.mk
bsd.lkm.mk bsd.xconf.mk bsd.xorg.mk /usr/share/mk
install: /usr/share/mk/bsd.README: File exists
*** Error 71 in share/mk (Makefile:13 'install')
*** Error 1 in /usr/src (Makefile:78 'build')
#
Not really helpful. With the diff below, I will now get:
install: /usr/share/mk/bsd.README: Read-only file system
which helps figuring out what is wrong.
Miod
Index: xinstall.c
===
RCS file: /cvs/src/usr.bin/xinstall/xinstall.c,v
retrieving revision 1.52
diff -u -p -r1.52 xinstall.c
--- xinstall.c 14 Sep 2012 00:00:29 - 1.52
+++ xinstall.c 14 Feb 2013 20:32:21 -
@@ -639,8 +639,10 @@ create_newfile(char *path, struct stat *
/* It is ok for the target file not to exist. */
if (rename(path, backup) < 0 && errno != ENOENT)
err(EX_OSERR, "rename: %s to %s (errno %d)", path,
backup, errno);
- } else
- (void)unlink(path);
+ } else {
+ if (unlink(path) < 0 && errno != ENOENT)
+ err(EX_OSERR, "%s", path);
+ }
return(open(path, O_CREAT | O_RDWR | O_EXCL, S_IRUSR | S_IWUSR));
}
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
On 2013/02/14 17:47, Jason McIntyre wrote: > On Thu, Feb 14, 2013 at 10:53:54AM -0600, Amit Kulkarni wrote: > > On Thu, Feb 14, 2013 at 6:33 AM, Stuart Henderson > > wrote: > > > > > Amit Kulkarni gmail.com> writes: > > > > > > > > > > > I was reading the manpages of athn/iwn for purchasing a suitable > > > wireless card > > > and found repeated > > > > occurences of 2GHz, when in fact it should be 2.4GHz. That is the > > > standard > > > frequency when purchasing a > > > > wireless a/b/g/n card. The code is filled with 2GHz references but just > > > changed to man pages in section 4. > > > > > > I don't think there is anything 'wrong' in saying "operates in the 2GHz > > > spectrum". Saying 2.4GHz in documentation seems like it might be a > > > good idea as it's more common usage, but it seems wrong to say "2.4GHz > > > spectrum", it seems like "2.4GHz band" would make more sense if doing > > > this. (But then mixing 'band' and 'spectrum' would also be weird so the > > > references to 5GHz would need changing to 'bands' (not 'band' there as > > > there are 3 non-continuous ranges). Is it worth it? I don't know. > > > > > > > > > you guys beat me with a stick if i push more than once, so i will refrain > > from commenting on it. > > > > a section of athn.4 manpage is fluff, information is repeated twice. once > > in words, other times in a table summarizing the list of working/supported > > chips. the same manpage was copied over for iwn, a table of supported chips > > would be nice in there too. if there's any interest i will sit down and > > submit a manpage diff. > > all diffs welcome. > jmc > Related, if someone has time: ifmedia(4) has a table of channel/frequency (and regulatory information) which only covers 1-14, extending this to cover the 5GHz channels would be handy.
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
On Thu, Feb 14, 2013 at 10:53:54AM -0600, Amit Kulkarni wrote: > On Thu, Feb 14, 2013 at 6:33 AM, Stuart Henderson wrote: > > > Amit Kulkarni gmail.com> writes: > > > > > > > > I was reading the manpages of athn/iwn for purchasing a suitable > > wireless card > > and found repeated > > > occurences of 2GHz, when in fact it should be 2.4GHz. That is the > > standard > > frequency when purchasing a > > > wireless a/b/g/n card. The code is filled with 2GHz references but just > > changed to man pages in section 4. > > > > I don't think there is anything 'wrong' in saying "operates in the 2GHz > > spectrum". Saying 2.4GHz in documentation seems like it might be a > > good idea as it's more common usage, but it seems wrong to say "2.4GHz > > spectrum", it seems like "2.4GHz band" would make more sense if doing > > this. (But then mixing 'band' and 'spectrum' would also be weird so the > > references to 5GHz would need changing to 'bands' (not 'band' there as > > there are 3 non-continuous ranges). Is it worth it? I don't know. > > > > > > you guys beat me with a stick if i push more than once, so i will refrain > from commenting on it. > > a section of athn.4 manpage is fluff, information is repeated twice. once > in words, other times in a table summarizing the list of working/supported > chips. the same manpage was copied over for iwn, a table of supported chips > would be nice in there too. if there's any interest i will sit down and > submit a manpage diff. all diffs welcome. jmc
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
Amit Kulkarni [amitk...@gmail.com] wrote: > I was reading the manpages of athn/iwn for purchasing a suitable wireless > card and found repeated occurences of 2GHz, when in fact it should be 2.4GHz. > That is the standard frequency when purchasing a wireless a/b/g/n card. The > code is filled with 2GHz references but just changed to man pages in section > 4. > The atheros chip, and probably several others, are capable of operating in a much wider range than just 2400-2500 MHz. -- "That's what." -- She
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
On Thu, Feb 14, 2013 at 6:33 AM, Stuart Henderson wrote: > Amit Kulkarni gmail.com> writes: > > > > > I was reading the manpages of athn/iwn for purchasing a suitable > wireless card > and found repeated > > occurences of 2GHz, when in fact it should be 2.4GHz. That is the > standard > frequency when purchasing a > > wireless a/b/g/n card. The code is filled with 2GHz references but just > changed to man pages in section 4. > > I don't think there is anything 'wrong' in saying "operates in the 2GHz > spectrum". Saying 2.4GHz in documentation seems like it might be a > good idea as it's more common usage, but it seems wrong to say "2.4GHz > spectrum", it seems like "2.4GHz band" would make more sense if doing > this. (But then mixing 'band' and 'spectrum' would also be weird so the > references to 5GHz would need changing to 'bands' (not 'band' there as > there are 3 non-continuous ranges). Is it worth it? I don't know. > > > you guys beat me with a stick if i push more than once, so i will refrain from commenting on it. a section of athn.4 manpage is fluff, information is repeated twice. once in words, other times in a table summarizing the list of working/supported chips. the same manpage was copied over for iwn, a table of supported chips would be nice in there too. if there's any interest i will sit down and submit a manpage diff.
Re: fcntl F_SETFD 1->FD_CLOEXEC
This was ok'd by millert@
anyone else want to ok and commit?
On Sun, Jan 20, 2013 at 05:23:00PM -0500, David Hill wrote:
>Use FD_CLOEXEC instead of 1.
>
>Change one instance in libutil to use O_CLOEXEC instead of a fcntl right
>after.
>
>Index: bin/systrace/openbsd-syscalls.c
>===
>RCS file: /cvs/src/bin/systrace/openbsd-syscalls.c,v
>retrieving revision 1.41
>diff -N -u -p bin/systrace/openbsd-syscalls.c
>--- bin/systrace/openbsd-syscalls.c18 Sep 2011 23:24:14 - 1.41
>+++ bin/systrace/openbsd-syscalls.c20 Jan 2013 22:15:09 -
>@@ -166,7 +166,7 @@ obsd_open(void)
> goto out;
> }
>
>- if (fcntl(cfd, F_SETFD, 1) == -1)
>+ if (fcntl(cfd, F_SETFD, FD_CLOEXEC) == -1)
> warn("fcntl(F_SETFD)");
>
> out:
>Index: lib/libc/db/btree/bt_open.c
>===
>RCS file: /cvs/src/lib/libc/db/btree/bt_open.c,v
>retrieving revision 1.14
>diff -N -u -p lib/libc/db/btree/bt_open.c
>--- lib/libc/db/btree/bt_open.c17 Sep 2007 07:07:23 - 1.14
>+++ lib/libc/db/btree/bt_open.c20 Jan 2013 22:15:09 -
>@@ -204,7 +204,7 @@ __bt_open(const char *fname, int flags, int mode, cons
> F_SET(t, B_INMEM);
> }
>
>- if (fcntl(t->bt_fd, F_SETFD, 1) == -1)
>+ if (fcntl(t->bt_fd, F_SETFD, FD_CLOEXEC) == -1)
> goto err;
>
> if (fstat(t->bt_fd, &sb))
>Index: lib/libc/db/hash/hash.c
>===
>RCS file: /cvs/src/lib/libc/db/hash/hash.c,v
>retrieving revision 1.23
>diff -N -u -p lib/libc/db/hash/hash.c
>--- lib/libc/db/hash/hash.c2 Jul 2010 16:46:28 - 1.23
>+++ lib/libc/db/hash/hash.c20 Jan 2013 22:15:10 -
>@@ -117,7 +117,7 @@ __hash_open(const char *file, int flags, int mode,
> if (file) {
> if ((hashp->fp = open(file, flags, mode)) == -1)
> RETURN_ERROR(errno, error0);
>- (void)fcntl(hashp->fp, F_SETFD, 1);
>+ (void)fcntl(hashp->fp, F_SETFD, FD_CLOEXEC);
> new_table = fstat(hashp->fp, &statbuf) == 0 &&
> statbuf.st_size == 0 && (flags & O_ACCMODE) != O_RDONLY;
> } else
>Index: lib/libc/db/hash/hash_page.c
>===
>RCS file: /cvs/src/lib/libc/db/hash/hash_page.c,v
>retrieving revision 1.19
>diff -N -u -p lib/libc/db/hash/hash_page.c
>--- lib/libc/db/hash/hash_page.c 11 May 2008 22:21:25 - 1.19
>+++ lib/libc/db/hash/hash_page.c 20 Jan 2013 22:15:10 -
>@@ -858,7 +858,7 @@ open_temp(HTAB *hashp)
> (void)sigprocmask(SIG_BLOCK, &set, &oset);
> if ((hashp->fp = mkstemp(path)) != -1) {
> (void)unlink(path);
>- (void)fcntl(hashp->fp, F_SETFD, 1);
>+ (void)fcntl(hashp->fp, F_SETFD, FD_CLOEXEC);
> }
> (void)sigprocmask(SIG_SETMASK, &oset, (sigset_t *)NULL);
> return (hashp->fp != -1 ? 0 : -1);
>Index: lib/libc/gen/syslog_r.c
>===
>RCS file: /cvs/src/lib/libc/gen/syslog_r.c,v
>retrieving revision 1.3
>diff -N -u -p lib/libc/gen/syslog_r.c
>--- lib/libc/gen/syslog_r.c30 May 2011 18:48:33 - 1.3
>+++ lib/libc/gen/syslog_r.c20 Jan 2013 22:15:10 -
>@@ -279,7 +279,7 @@ connectlog_r(struct syslog_data *data)
> if (data->log_file == -1) {
> if ((data->log_file = socket(AF_UNIX, SOCK_DGRAM, 0)) == -1)
> return;
>- (void)fcntl(data->log_file, F_SETFD, 1);
>+ (void)fcntl(data->log_file, F_SETFD, FD_CLOEXEC);
> }
> if (data->log_file != -1 && !data->connected) {
> memset(&SyslogAddr, '\0', sizeof(SyslogAddr));
>Index: lib/libc/yp/yp_bind.c
>===
>RCS file: /cvs/src/lib/libc/yp/yp_bind.c,v
>retrieving revision 1.17
>diff -N -u -p lib/libc/yp/yp_bind.c
>--- lib/libc/yp/yp_bind.c 5 Jun 2009 17:19:00 - 1.17
>+++ lib/libc/yp/yp_bind.c 20 Jan 2013 22:15:10 -
>@@ -242,7 +242,7 @@ gotdata:
> ysd->dom_vers = -1;
> goto again;
> }
>- if (fcntl(ysd->dom_socket, F_SETFD, 1) == -1)
>+ if (fcntl(ysd->dom_socket, F_SETFD, FD_CLOEXEC) == -1)
> perror("fcntl: F_SETFD");
>
> if (new) {
>Index: lib/libevent/signal.c
>===
>RCS file: /cvs/src/lib/libevent/signal.c,v
>retrieving revision 1.15
>diff -N -u -p lib/libevent/signal.c
>--- lib/libevent/signal.c 12 Jul 2010 18:03:38 - 1.15
>+++ lib/libevent/signal.c 20 Jan 2013 22:15:10 -
>@@ -85,7 +85,7 @@ evsignal_cb(int fd, short what, void *arg)
>
> #ifdef HAVE_SETFD
> #define FD_CLOSEONEXEC(x) do { \
>-if (fcntl(x, F_SETFD, 1)
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
On 02/14/13 07:33, Stuart Henderson wrote: Amit Kulkarni gmail.com> writes: I was reading the manpages of athn/iwn for purchasing a suitable wireless card and found repeated occurences of 2GHz, when in fact it should be 2.4GHz. That is the standard frequency when purchasing a wireless a/b/g/n card. The code is filled with 2GHz references but just changed to man pages in section 4. I don't think there is anything 'wrong' in saying "operates in the 2GHz spectrum". Saying 2.4GHz in documentation seems like it might be a good idea as it's more common usage, but it seems wrong to say "2.4GHz spectrum", it seems like "2.4GHz band" would make more sense if doing this. (But then mixing 'band' and 'spectrum' would also be weird so the references to 5GHz would need changing to 'bands' (not 'band' there as there are 3 non-continuous ranges). Is it worth it? I don't know. Yes, exactly right--2.4GHz band is correct and consistent with many governmental agencies terminology. This is a picky point that isn't major, but there are clear definitions of the wireless bands, and using them is better. And, consistent with OpenBSD's striving to get it right. --STeve Andre'
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
Amit Kulkarni gmail.com> writes: > > I was reading the manpages of athn/iwn for purchasing a suitable wireless card and found repeated > occurences of 2GHz, when in fact it should be 2.4GHz. That is the standard frequency when purchasing a > wireless a/b/g/n card. The code is filled with 2GHz references but just changed to man pages in section 4. I don't think there is anything 'wrong' in saying "operates in the 2GHz spectrum". Saying 2.4GHz in documentation seems like it might be a good idea as it's more common usage, but it seems wrong to say "2.4GHz spectrum", it seems like "2.4GHz band" would make more sense if doing this. (But then mixing 'band' and 'spectrum' would also be weird so the references to 5GHz would need changing to 'bands' (not 'band' there as there are 3 non-continuous ranges). Is it worth it? I don't know.
