An apparent typo was introduced in
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/units/units.lib.diff?r1=1.144=1.145=h
Does nobody use units(1) on their Chilean vacation anymore?
Jan
Index: units.lib
===
RCS file:
> > aplsmc(4) provides support for the lid position sensor.
Should that be mentioned in aplsmc(4)?
Index: aplsmc.4
===
RCS file: /cvs/src/share/man/man4/man4.arm64/aplsmc.4,v
retrieving revision 1.2
diff -u -p -r1.2 aplsmc.4
---
> > o On arm64, add a machdep.lidaction sysctl(8)
> > for aplsmc(4) Apple Silicon laptops.
Should that be mentioned in the arm64 examples/sysctl.conf
as on other such architectures?
Index: etc/etc.arm64/sysctl.conf
===
RCS file:
ping
On Sep 18 18:16:45, h...@stare.cz wrote:
> Better diff: remove the comment as well.
>
>
> Index: iostat.8
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
> retrieving revision 1.28
> diff -u -p -r1.28 iostat.8
> ---
Better diff: remove the comment as well.
Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.28
diff -u -p -r1.28 iostat.8
--- iostat.817 Sep 2022 11:39:09 - 1.28
+++ iostat.818
By default, iostat displays the first for drives.
It would be less surprising if it displayed all drives.
It seems that the reason to display four is that
it fits into the 80 columns (that is, with -d; otherwise,
the cpu and tty display make the line overflow anyway).
Jan
Index:
I believe this reads a little bit better.
Jan
Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.27
diff -u -p -r1.27 iostat.8
--- iostat.87 Sep 2018 12:54:44 - 1.27
+++
On Jun 02 07:16:52, dera...@openbsd.org wrote:
> Your diff completely breaks a majority of the ways people use it.
Does that mean people mostly use
the undocumented obsolete syntax
that obsolete() keeps supported?
> Jan Stary wrote:
>
> &g
On Jun 02 14:36:16, h...@stare.cz wrote:
> # dump /home
> dump: option requires an argument -- h
>
> # dump /music
> dump: option requires an argument -- s
>
> # dump /media
> dump: option requires an argument -- d
>
> What? Before passing
The following wording of dump(8)
can IMHO be be simplified without any loss:
Rewinding or ejecting tape features after a close operation
on a tape device depend on the name of the tape unit device used.
I am not a native speaker; but if I parse that right,
what "features" are
# dump /home
dump: option requires an argument -- h
# dump /music
dump: option requires an argument -- s
# dump /media
dump: option requires an argument -- d
What? Before passing its options to getopt(),
dump's main() processes them with
On May 28 10:34:35, s...@spacehopper.org wrote:
> On 2022/05/28 06:52, Jason McIntyre wrote:
> > On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote:
> > > apmd says:
> > >
> > > When the power status changes (battery is connected or disconnected),
>
apmd says:
When the power status changes (battery is connected or disconnected),
apmd fetches the current status and reports it via syslog(3)
with logging facility LOG_DAEMON.
Is "battery" really meant here? Should that be the AC power?
Batteries are typically not being reconnected while
On Feb 10 16:33:20, j...@juef.net wrote:
> (Thu, 10 Feb 14:59) Jan Stary:
> > With the recent change to apm -m,
> > reporting either the battery lifetime
> > or the estimated time to charge (thank you),
> > the manpage seems to have been left behind.
> >
> >
With the recent change to apm -m,
reporting either the battery lifetime
or the estimated time to charge (thank you),
the manpage seems to have been left behind.
While here, tweak some of the wording:
- "in minutes" or "in percent" is not parenthetical; say it explicitly
- surely -a displays the
On Feb 05 17:35:46, o...@drijf.net wrote:
> On Sat, Feb 05, 2022 at 05:22:50PM +0100, Jan Stary wrote:
>
> > On Feb 02 00:04:37, alexander.bl...@gmx.net wrote:
> > > On Tue, Feb 01, 2022 at 08:00:36AM +0100, Otto Moerbeek wrote:
> > > > > A
On Feb 02 00:04:37, alexander.bl...@gmx.net wrote:
> On Tue, Feb 01, 2022 at 08:00:36AM +0100, Otto Moerbeek wrote:
> > > Are you running with any malloc flags?
> >
> > This bug report enabled me to find a bug that would pop up if G mode
> > is enabled.
> >
> > New diff below. New tests
Intended to affect collation order. It may for example
affect alphabetic sorting, regular expressions including
equivalence classes, and the strcoll(3) and strxfrm(3) functions.
so only in strcoll(3) does one eventualy read that
the locale has in fact no effect on collation.
That was
Looking at the source, it's simply strcoll().
Jan
Index: bin/expr/expr.1
===
RCS file: /cvs/src/bin/expr/expr.1,v
retrieving revision 1.24
diff -u -p -r1.24 expr.1
--- bin/expr/expr.1 16 Aug 2017 20:10:58 -
Index: yppoll/yppoll.c
===
RCS file: /cvs/src/usr.sbin/yppoll/yppoll.c,v
retrieving revision 1.15
diff -u -p -r1.15 yppoll.c
--- yppoll/yppoll.c 16 Jan 2015 06:40:22 - 1.15
+++ yppoll/yppoll.c 1 Feb 2022 22:35:00
On Dec 24 10:20:03, h...@stare.cz wrote:
> Similarly for kern.proc and ps(1).
In fact,
warnx("use netstat to view %s", string);
warnx("use dmesg to view %s", string);
warnx("use ps to view %s information", string);
warnx("use vmstat or systat to view %s information",
warnx("use fstat to view %s
Similarly for kern.proc and ps(1).
On Dec 24 10:18:15, h...@stare.cz wrote:
> The sysctl(2) manpage also lists the corresponding sysctl(8) variables:
>
> Information may be retrieved and set using the sysctl(8) utility;
> the variable names used by this utility are given here in parentheses.
The sysctl(2) manpage also lists the corresponding sysctl(8) variables:
Information may be retrieved and set using the sysctl(8) utility;
the variable names used by this utility are given here in parentheses.
Among these is kern.file, which, understandably, just points to fstat(8).
Would it
On Dec 04 14:28:23, h...@stare.cz wrote:
> On Dec 04 12:23:42, h...@stare.cz wrote:
> > On Dec 01 09:07:43, h...@stare.cz wrote:
> > > > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote:
> > > > > > > Diff below unlock the bottom part of the UVM fault handler. I'm
> > > > > > > interested in
On Dec 04 12:23:42, h...@stare.cz wrote:
> On Dec 01 09:07:43, h...@stare.cz wrote:
> > > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote:
> > > > > > Diff below unlock the bottom part of the UVM fault handler. I'm
> > > > > > interested in squashing the remaining bugs. Please test with your
On Dec 01 09:07:43, h...@stare.cz wrote:
> > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote:
> > > > > Diff below unlock the bottom part of the UVM fault handler. I'm
> > > > > interested in squashing the remaining bugs. Please test with your
> > > > > usual
> > > > > setup & report back.
>
> > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote:
> > > > Diff below unlock the bottom part of the UVM fault handler. I'm
> > > > interested in squashing the remaining bugs. Please test with your usual
> > > > setup & report back.
> > >
> > > Thanks to all the testers, here's a new version
On Nov 30 10:40:25, s...@spacehopper.org wrote:
> On 2021/11/29 22:50, Martin Pieuchot wrote:
> > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote:
> > > Diff below unlock the bottom part of the UVM fault handler. I'm
> > > interested in squashing the remaining bugs. Please test with your usual
> >
> > Stop building the kernel with -Wno-uninitialized on clang archs.
> > This hides real problems like the recently fixed uninitialised memory
> > use in pf and igc.
> >
> > [-Wsometimes-uninitialized] /sys/arch/arm/arm/cpu.c:352:6: warning:
> > variable 'ci' is used uninitialized whenever 'if'
On Nov 25 01:38:35, h...@stare.cz wrote:
> On Nov 24 14:47:48, j...@maudlin.dev wrote:
> >
> > Jan Stary writes:
> > > smtpd just failed to parse a SMTP response (below),
> > > saying 'line too long'.
> > >
> > > Looking at the sourc
On Nov 24 14:47:48, j...@maudlin.dev wrote:
>
> Jan Stary writes:
> > smtpd just failed to parse a SMTP response (below),
> > saying 'line too long'.
> >
> > Looking at the source, this seems to be parse_smtp_response() in util.c,
> > which errors out
This is current/amd64 on a PC.
smtpd just failed to parse a SMTP response (below),
saying 'line too long'.
Looking at the source, this seems to be parse_smtp_response() in util.c,
which errors out right away with
if (len >= LINE_MAX)
return "line too long";
Apparently,
On Nov 23 00:10:08, h...@stare.cz wrote:
> extern optind and friends are already declared
> once unistd.h is included, to these can be removed.
This is the same for usr.bin except ssh.
Jan
Index: usr.bin//env/env.c
===
RCS
extern optind and friends are already declared
once unistd.h is included, to these can be removed.
This is the usr.sbin part; I am not touching nsd
and other third-party stuff.
Jan
Index: usr.sbin//yppoll/yppoll.c
===
RCS
On Nov 10 00:21:59, h...@stare.cz wrote:
> On Nov 02 12:30:56, dera...@openbsd.org wrote:
> > Paul de Weerd wrote:
> >
> > > A recent commit by Theo changed the hw.perfpolicy behavior to always
> > > run at full speed when AC power is on. This means that my workstation
> > > (and servers, once
On Nov 19 00:01:04, stef...@sdaoden.eu wrote:
> Jan Stary wrote in
> :
> |On Nov 18 20:13:03, h...@stare.cz wrote:
> |> On Nov 16 21:33:31, hen...@camandro.org wrote:
> |>> I've tried to setup a line like:
> |>> bind-key XF86MonBrightnessDown &quo
On Nov 18 20:13:03, h...@stare.cz wrote:
> On Nov 16 21:33:31, hen...@camandro.org wrote:
> > I've tried to setup a line like:
> > bind-key XF86MonBrightnessDown ""
> > in my .cwmrc and the result was that no key event was sent to my windows.
>
> Please excuse my X ignorance, but shouldn't
On Nov 16 21:33:31, hen...@camandro.org wrote:
> I've tried to setup a line like:
> bind-key XF86MonBrightnessDown ""
> in my .cwmrc and the result was that no key event was sent to my windows.
Please excuse my X ignorance, but shouldn't XF86MonBrightnessDown
be catched by the X server (to take
On Oct 09 20:26:13, tro...@kagu-tsuchi.com wrote:
> This is a new attempt at fixing vi(1) recovery by actually writing
> to the recovery file. Previously I restored the SIGALRM method that
> was deleted in the 90's but wondered if that was still the best way
> to handle this. Checking and
On Nov 15 17:58:38, schwa...@usta.de wrote:
> Hi Marc,
>
> Marc Espie wrote on Mon, Nov 15, 2021 at 05:06:23PM +0100:
> > On Mon, Nov 15, 2021 at 03:43:47PM +0100, Jan Stary wrote:
> >> On Nov 10 18:46:08, h...@stare.cz wrote:
> >>> On Nov 10 18:15:44, h...@st
Here's a try (see below);
one sentence one line while here.
I would also replace 'results' with 'result' everywhere,
but I am not a native speaker.
Jan
On Nov 10 18:46:08, h...@stare.cz wrote:
> On Nov 10 18:15:44, h...@stare.cz wrote:
> > expr(1) says
> >
> > expr1 {=, >, >=, <, <=,
(Does anyone want to commit this please?)
On Nov 10 09:31:57, mill...@openbsd.org wrote:
> On Wed, 10 Nov 2021 17:29:55 +0100, Jan Stary wrote:
>
> > With included, there is no need
> > to declare extern int optind and friends again.
>
> Right, most of this is old cod
On Nov 10 19:10:59, h...@stare.cz wrote:
> https://marc.info/?l=openbsd-tech=163389736000516=2
>
> Not related to the original head -5 -n 6 discussion,
> but a copy of obsolete() exists in usr.bin/join/
> (and seems to be the only instance, AFAIG).
Ah, that one seems to be specific to the
https://marc.info/?l=openbsd-tech=163389736000516=2
Not related to the original head -5 -n 6 discussion,
but a copy of obsolete() exists in usr.bin/join/
(and seems to be the only instance, AFAIG).
Jan
On Nov 10 18:15:44, h...@stare.cz wrote:
> expr(1) says
>
> expr1 {=, >, >=, <, <=, !=} expr2
>
> Returns the results of integer comparison if both arguments
> are decimal integers; otherwise, returns the results of
> string comparison using the locale-specific collation
expr(1) says
expr1 {=, >, >=, <, <=, !=} expr2
Returns the results of integer comparison if both arguments
are decimal integers; otherwise, returns the results of
string comparison using the locale-specific collation
sequence. The result of each comparison is 1
With included, there is no need
to declare extern int optind and friends again.
Jan
Index: usr.sbin/amd/amd/get_args.c
===
RCS file: /cvs/src/usr.sbin/amd/amd/get_args.c,v
retrieving revision 1.15
diff -u -p -r1.15
On Nov 10 13:20:45, k...@openbsd.org wrote:
> On Wed, Nov 10, 2021 at 12:07:37AM +0100, Jan Stary wrote:
> > On Nov 09 15:43:04, k...@openbsd.org wrote:
> > > This populates `systat sensors' with the correct lid status on my
> > > Pinebook Pro:
> > >
Why does who(1) need to setlocale()?
Jan
Index: who.c
===
RCS file: /cvs/src/usr.bin/who/who.c,v
retrieving revision 1.30
diff -u -p -r1.30 who.c
--- who.c 12 Jul 2021 15:09:20 - 1.30
+++ who.c 10 Nov
On Nov 10 00:21:59, h...@stare.cz wrote:
> Regarding C states, this machine has
>
> acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
>
> I suppose the cpu supports C1, C2, C3, but can someone please kindly
> explain (or point to an explanation of)
On Nov 02 12:30:56, dera...@openbsd.org wrote:
> Paul de Weerd wrote:
>
> > A recent commit by Theo changed the hw.perfpolicy behavior to always
> > run at full speed when AC power is on. This means that my workstation
> > (and servers, once I upgrade them) now consumes significantly more
> >
On Nov 09 15:43:04, k...@openbsd.org wrote:
> This populates `systat sensors' with the correct lid status on my
> Pinebook Pro:
>
> -gpio-key-lid at mainbus0 not configured
> -gpio-key-power at mainbus0 not configured
> +gpiokeys0 at mainbus0: "Lid"
> +gpiokeys0 at
On Nov 09 00:36:03, h...@stare.cz wrote:
> As a naive test of speed, I am downloading a 100MB file
> from a http server just behind the AP with
> ftp -o /dev/null http://stare.cz/.tmp/file
> An average of ten runs is 5.31 MB/s without the diff
> and 3.37 MB/s with the (updated) diff.
Any idea how
On Nov 01 12:56:26, s...@stsp.name wrote:
> This patch adds 802.11n 40MHz support to the iwn(4) driver.
>
> This driver supports many different devices. Please try to be precise
> about which device you have tested so I can maintain a record of our
> test coverage.
This is current/amd64 on a
Say explicitly that doas needs doas.conf to exist,
and point to the example one.
Jan
Index: doas.1
===
RCS file: /cvs/src/usr.bin/doas/doas.1,v
retrieving revision 1.25
diff -u -p -r1.25 doas.1
--- doas.1 16 Jan 2021
On Dec 26 23:24:57, h...@stare.cz wrote:
> ftpd doesn't need to declare extern int optreset
> as that is already done in the included unistd.h
Here's more for usr.sbin/, if desirable.
Jan
Index: usr.sbin//amd/amd/get_args.c
ftpd doesn't need to declare extern int optreset
as that is already done in the included unistd.h
Jan
Index: popen.c
===
RCS file: /cvs/src/libexec/ftpd/popen.c,v
retrieving revision 1.29
diff -u -p -r1.29 popen.c
---
On Oct 17 11:12:28, cpb_t...@bennettconstruction.us wrote:
> On Sat, Oct 17, 2020 at 05:52:58PM +0200, Jan Stary wrote:
> > Currently, mixerctl.conf(5) says
> >
> > Most devices have a number of digital to analogue converters
> > (DACs), used for sound
Currently, mixerctl.conf(5) says
Most devices have a number of digital to analogue converters
(DACs), used for sound playback, and each DAC has a corresponding
output mixer. The mixers are labelled “mix” or “sel”.
That doesn't seem to be the case, at least not universaly
On Aug 01 18:23:08, jonat...@d14n.org wrote:
> Much better theory: the acpicpu_sc array has MAXCPUS elements, but on this
> system (and all R6415s, as far as I can tell) we have more acpicpu devices
> than that. I suppose we should just make acpicpu_match fail if cf->cf_unit
> is >= MAXCPUS as we
ping
On Jul 16 09:23:22, h...@stare.cz wrote:
> On Jul 15 15:48:41, mill...@openbsd.org wrote:
> > Upstream tzcode removed the LOCALE_HOME bits in 2014. There's no
> > reason for us to keep it.
>
> With that removed, the header file can go too.
>
> Jan
>
>
> Index:
Does xargs need to set LC_MESSAGES?
Jan
Index: usr.bin/xargs/xargs.c
===
RCS file: /cvs/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.34
diff -u -p -r1.34 xargs.c
--- usr.bin/xargs/xargs.c 12 Jun 2018 15:24:31
On Jul 15 15:48:41, mill...@openbsd.org wrote:
> Upstream tzcode removed the LOCALE_HOME bits in 2014. There's no
> reason for us to keep it.
With that removed, the header file can go too.
Jan
Index: lib/libc/time/strftime.c
The OpenBSD libc tends to ignore the LC_* except LC_CTYPE.
However, strftime(3) seems to support a LOCALE_HOME thing,
where the user overrides LC_TIME with his own names of months etc.
Looking at http://cvsweb.openbsd.org/src/lib/libc/time/strftime.c ,
it has been there since the beginning.
The
This is in the vein of
https://marc.info/?l=openbsd-cvs=158170787221615=2
declares "extern int optind" and friends,
so there is no need to declare them again.
Still builds on current/amd64.
Leaving out gnu, nsd, unbound (third party)
and tic (is that third party)?
Also leaving out pr and rcs
On Feb 14 17:04:51, schwa...@usta.de wrote:
> Jason McIntyre wrote on Fri, Feb 14, 2020 at 07:28:59AM +:
> > On Thu, Feb 13, 2020 at 11:25:07PM +0100, Jan Stary wrote:
> >> * Fix a factual error in the description of bs: it does not
> >> supersede ibs/obs,
Hi,
On Feb 14 17:37:27, schwa...@usta.de wrote:
> Hi,
>
> Jason McIntyre wrote on Fri, Feb 14, 2020 at 07:28:59AM +:
> > On Thu, Feb 13, 2020 at 11:25:07PM +0100, Jan Stary wrote:
>
> >> -.It Cm seek= Ns Ar n
> >> +.It Cm seek Ns = Ns Ar n
>
-u -p -r1.15 fmt_test.c
> --- regress/lib/libutil/fmt_scaled/fmt_test.c 16 Mar 2017 02:42:31 -
> 1.15
> +++ regress/lib/libutil/fmt_scaled/fmt_test.c 9 Feb 2020 16:23:49 -
> @@ -36,8 +36,6 @@ __dead static void usage(int stat)
> int
> main(int argc, char **argv)
On Feb 10 09:28:38, yasu...@openbsd.org wrote:
> Hi,
>
> On Sun, 09 Feb 2020 19:28:50 +0100
> Jeremie Courreges-Anglas wrote:
> > On Sun, Feb 09 2020, Jan Stary wrote:
> >> Currently, sys/net/pipex_local.h asks #ifdef __OpenBSD__
> >> and if so, defines &qu
On Feb 13 23:25:07, h...@stare.cz wrote:
> This diff changes the dd(1) manpage in the following ways:
>
> * Replace "It Cm if= Ns Ar file" with "It Cm if Ns = Ns Ar file"
> and similarly for others. The operand is "if", not "if=";
> the "Ns = Ns" might be a slightly excessive markup,
> but
This diff changes the dd(1) manpage in the following ways:
* Replace "It Cm if= Ns Ar file" with "It Cm if Ns = Ns Ar file"
and similarly for others. The operand is "if", not "if=";
the "Ns = Ns" might be a slightly excessive markup,
but common: grep -Fr 'Ns = Ns' /usr/share/man | wc -l
On Feb 12 21:38:56, a...@caoua.org wrote:
> On Wed, Feb 12, 2020 at 09:22:20PM +0100, Jan Stary wrote:
> > Hi,
> >
> > On Feb 09 13:13:02, a...@caoua.org wrote:
> > > cd /usr/src
> > > patch -p0 <1.diff
> > > patch -p0 <2.diff
> >
Hi,
On Feb 09 13:13:02, a...@caoua.org wrote:
> cd /usr/src
> patch -p0 <1.diff
> patch -p0 <2.diff
> patch -p0 <3.diff
> cd /usr/src/include && doas make includes
> cd /usr/src/lib/libsndio && make obj && make && doas make install
> cd /usr/src/lib/libossaudio && make obj && make && doas make
Hi,
On Feb 09 13:13:02, a...@caoua.org wrote:
> cd /usr/src
> patch -p0 <1.diff
> patch -p0 <2.diff
> patch -p0 <3.diff
> cd /usr/src/include && doas make includes
> cd /usr/src/lib/libsndio && make obj && make && doas make install
> cd /usr/src/lib/libossaudio && make obj && make && doas make
On Feb 10 14:53:33, mill...@openbsd.org wrote:
> On Mon, 10 Feb 2020 17:12:53 +0100, Jan Stary wrote:
>
> > The -r option of newsyslog(8) removes the requirement
> > that newsyslog runs as root. Would it also make sense
> > to not try to send the SIGHUP to syslogd in th
Hi Ingo,
On Feb 10 22:40:20, schwa...@usta.de wrote:
> > The -r option of newsyslog(8) removes the requirement
> > that newsyslog runs as root. Would it also make sense
> > to not try to send the SIGHUP to syslogd in that case?
>
> While i'm not sure that i want to take care of this patch,
>
The -r option of newsyslog(8) removes the requirement
that newsyslog runs as root. Would it also make sense
to not try to send the SIGHUP to syslogd in that case?
Jan
Index: newsyslog.8
===
RCS file:
Why does cron(8) and crontab(1) need to setlocale()?
Jan
Index: cron.c
===
RCS file: /cvs/src/usr.sbin/cron/cron.c,v
retrieving revision 1.77
diff -u -p -r1.77 cron.c
--- cron.c 23 Oct 2017 15:15:22 - 1.77
+++
mv code contains copies of cp.c and rm.c
- is that so that mv can avoid the fork+exec
(and call the relevant cp/rm code itself)?
If so, is it so that mv can be pledged? It isn't.
There must be something worth the duplication ...
Jan
On Jan 02 11:30:35, es...@nerim.net wrote:
> Once in three times, I type scp -R and go "oh fuck" when it doesn't work.
Same here with 'ssh -p' vs 'scp -P'.
(Replying to an old thread)
On Jan 28 12:06:42, chrisbenn...@bennettconstruction.us wrote:
> #define _PATH_VFONT "/usr/libdata/vfont/"
> #define _PATH_VFONTB"/usr/libdata/vfont/B"
> #define _PATH_VFONTI"/usr/libdata/vfont/I"
> #define
On Feb 09 09:49:35, mill...@openbsd.org wrote:
> On Sun, 09 Feb 2020 17:46:51 +0100, Jan Stary wrote:
>
> > Whenever unistd.h declares getopt(3), it also declares
> > the extern optind and optarg, so files including unistd.h
> > don't need to declare those themselves, ri
The afile.h include has been so named for some time
but the corresponding #define has not been changed from WAV_H
- not that it matters much of course.
Jan
Index: afile.h
===
RCS file: /cvs/src/usr.bin/aucat/afile.h,v
Whenever unistd.h declares getopt(3), it also declares
the extern optind and optarg, so files including unistd.h
don't need to declare those themselves, right?
Jan
Index: games/fortune/strfile/strfile.c
===
RCS file:
Currently, sys/net/pipex_local.h asks #ifdef __OpenBSD__
and if so, defines "Static" to be nothing, to use it later.
That can go away, right?
Jan
Index: sys/net/pipex_local.h
===
RCS file: /cvs/src/sys/net/pipex_local.h,v
This seems to be a missed newline.
Jan
Index: EC_POINT_new.3
===
RCS file: /cvs/src/lib/libcrypto/man/EC_POINT_new.3,v
retrieving revision 1.9
diff -u -p -r1.9 EC_POINT_new.3
--- EC_POINT_new.3 29 Mar 2018 20:56:49
zic.c does not need to include
Jan
Index: zic.c
===
RCS file: /cvs/src/usr.sbin/zic/zic.c,v
retrieving revision 1.22
diff -u -p -r1.22 zic.c
--- zic.c 15 Mar 2016 19:50:47 - 1.22
+++ zic.c 11 Jan 2019
Does locate(1) need to setlocale(3)?
Jan
Index: locate/locate.c
===
RCS file: /cvs/src/usr.bin/locate/locate/locate.c,v
retrieving revision 1.31
diff -u -p -r1.31 locate.c
--- locate/locate.c 19 Nov 2015 21:46:05 -
Does comm(1) need to setlocale(3)?
It uses strcoll(3) by default, which ignores the locale
and does what strcmp(3) does, or strcasecmp(3) with -f,
which ignores the locale too.
So remove the setlocale(3), remove the header,
the LC_ that have been commented out since the initial revision in 1995,
calendar imho doesn't need to setlocale(LC_TIME, ...)
before and after strftime(3), as LC_TIME is ignored.
Jan
Index: day.c
===
RCS file: /cvs/src/usr.bin/calendar/day.c,v
retrieving revision 1.34
diff -u -p -r1.34 day.c
---
On Jan 10 14:43:39, h...@stare.cz wrote:
> The wprintf(3) manpage says
>
> The decimal point character is defined
> in the program's locale (category LC_NUMERIC)
>
> but LC_NUMERIC is ignored in OpenBSD's C library,
> as explained in setlocale(3).
>
> Would it be an improvement to
The wprintf(3) manpage says
The decimal point character is defined
in the program's locale (category LC_NUMERIC)
but LC_NUMERIC is ignored in OpenBSD's C library,
as explained in setlocale(3).
Would it be an improvement to remove that sentence?
(Removing a needless newline while
No really, it reads 20 packets and returns zero.
On Dec 08 13:56:09, h...@stare.cz wrote:
> The return value of pcap_dispatch() is described in pcap.3 as follows:
>
> The number of packets read is returned.
> Zero is returned when EOF is reached in a savefile.
> A return of -1 indicates an
ping
On Dec 08 13:56:09, h...@stare.cz wrote:
> The return value of pcap_dispatch() is described in pcap.3 as follows:
>
> The number of packets read is returned.
> Zero is returned when EOF is reached in a savefile.
> A return of -1 indicates an error in which case ...
>
> It will also
Currently, pcap_setdirection() is described in pcap.3 as follows:
pcap_setdirection() is used to limit the direction
that packets must be flowing in order to be captured.
The "direction" is not described, except in pcap.h.
Should the constants be mentioned in the manpage?
Also, the direction
pcap_dump() is described in pcap.3 as follows:
pcap_dump() outputs a packet to the savefile opened with pcap_dump_open().
Note that its calling arguments are suitable for use with pcap_dispatch().
That formulation is imho not entirely clear,
as the arguments mention no "savefile".
(Looking
The return value of pcap_dispatch() is described in pcap.3 as follows:
The number of packets read is returned.
Zero is returned when EOF is reached in a savefile.
A return of -1 indicates an error in which case ...
It will also return zero on the last short read (as "EOF is reached").
So
The wording of ifconfig DIAGNOSTICS can possibly baffle
a non-native speaker (such as me) with
Messages indicating the specified interface does not exist,
namely, only after parsing the (non)sentence does one realize
that the diagnostics consists of messages indicating THAT
the interface does
I am not a native speaker, but printf(3) "interprets" the conversion
specifiers, it does not "interpolate" them, right?
Jan
Index: printf.3
===
RCS file: /cvs/src/lib/libc/stdio/printf.3,v
retrieving revision 1.78
diff -u -p
Both _PATH_DEFPATH and _PATH_STDPATH, as defined in paths.h,
include /usr/local/bin but not /usr/local/sbin,
as opposed to /usr/bin:/bin:/usr/sbin:/sbin.
Is that intentional?
Jan
Index: include/paths.h
===
RCS file:
1 - 100 of 227 matches
Mail list logo
