Re: manpage text width

[Ingo Schwarze]

Hi Paul,

Paul Irofti wrote on Fri, Mar 30, 2018 at 11:23:54AM +0300:
> Ingo Schwarze wrote:

>>  * Nowadays, i guess that terminals narrower than 80 columns
>>have become seriously rare, so there is not very widespread
>>benefit for that case.

> Maybe that was true when we still had 4:3 screens, but now I always
> have 2 or 3 80 column xterms and space for another that is around 60
> columns.

I see.  I typically use three xterms side-by-side and for the remaining
space on the left a slightly overlapping one that i use more rarely.
When is use it, i often get away with only seeing the leftmost columns;
when i need to see all columns, i temporarily switch it to the
foreground.  Purely a matter of taste, of course.  I see that your
approach makes sense, too.

> So I guess a better choice would be:
> 
> $ alias man='man -Owidth=$(($COLUMNS<80?($COLUMNS-2):78))'

Sure, that seems reasonable for the usecase.

> which is EXACTLY what I was looking for! Can it be the default? :)

I'm neither particularly enthusiastiastic (because it requires
more code, in particular more getenv(3) which i dislike in general,
and because it adds another difference in behaviour depending on
isatty(3)) nor am im categorically rejecting the request.

If a few developers consider the feature useful, i shall implement
it; if nobody else speaks up, i'm more likely to KISS it.

Yours,
  Ingo

Re: expr: Fix integer overflows

[Ingo Schwarze]

Hi Tobias,

Tobias Stoeckmann wrote on Fri, Mar 30, 2018 at 05:39:11PM +0200:

> Our expr implementation supports 64 bit integers, but does not check
> for overflows during parsing and arithmetical operations.

Even though - as discussed previously for test(1) - behaviour is
undefined by POSIX outside the range 0 to 2147483647, we are allowed
to handle a larger range, and i agree that handling the range
-9223372036854775808 to 9223372036854775807 (INT64_MIN to INT64_MAX)
seems desirable.

> This patch fixes the problems based on FreeBSD's implementation, which
> is a bit more advanced than NetBSD, which it is based upon.

But i have two concerns regarding your implementation, see inline below.

> Index: bin/expr/expr.c
> ===
> RCS file: /cvs/src/bin/expr/expr.c,v
> retrieving revision 1.26
> diff -u -p -u -p -r1.26 expr.c
> --- bin/expr/expr.c   19 Oct 2016 18:20:25 -  1.26
> +++ bin/expr/expr.c   30 Mar 2018 15:33:50 -
> @@ -99,6 +99,7 @@ is_integer(struct val *vp, int64_t *r)
>   char   *s;
>   int neg;
>   int64_t i;
> + charc;
>  
>   if (vp->type == integer) {
>   *r = vp->u.i;
> @@ -120,8 +121,12 @@ is_integer(struct val *vp, int64_t *r)
>   if (!isdigit((unsigned char)*s))
>   return 0;
>  
> + c = *s - '0';
> + if (c < 0 || INT64_MAX / 10 < i || INT64_MAX - c < i * 10)
> + errx(3, "out of range");

Here is the first concern.

First look at our old implementation:

   $ /obin/expr -9223372036854775807 + 0
  -9223372036854775807

   $ /obin/expr -9223372036854775807 - 1
  -9223372036854775808
   $ /obin/expr -9223372036854775808 + 0 
  -9223372036854775808

   $ /obin/expr -9223372036854775807 - 2
  9223372036854775807
   $ /obin/expr -9223372036854775808 - 1 
  9223372036854775807
   $ /obin/expr -9223372036854775809 + 0 
  9223372036854775807

The first three are expected; the overflow in the last three is not.

Now look at what your new implementation does:

   $ /obin/expr.tobias -9223372036854775807 + 0
  -9223372036854775807

   $ /obin/expr.tobias -9223372036854775807 - 1 
  -9223372036854775808
   $ /obin/expr.tobias -9223372036854775808 + 0 
  expr.tobias: out of range

   $ /obin/expr.tobias -9223372036854775807 - 2 
  expr.tobias: overflow
   $ /obin/expr.tobias -9223372036854775808 - 1 
  expr.tobias: out of range
   $ /obin/expr.tobias -9223372036854775809 + 0 
  expr.tobias: out of range

The first two are expected, and so is the overflow in number 4
and the out of range in number 6.  But the out of range in
numbers 3 and 5 is unexpected.  I would expect number 3 to
succeed and number 5 to fail with overflow rather than out of range.

The reason is that the hand-rolled integer parser fails for INT64_MIN
because -INT64_MIN is larger than INT64_MAX.

I'm not saying this is an absolute show-stopper, but i consider
it somewhat ugly.  What do you think about using strtonum(3)
instead in is_integer?  long long is guaranteed to be at least
64 bits long, and that would solve the problem with INT64_MIN.

> +
>   i *= 10;
> - i += *s - '0';
> + i += c;
>  
>   s++;
>   }
> @@ -303,8 +308,9 @@ eval5(void)
>  struct val *
>  eval4(void)
>  {
> - struct val *l, *r;
> - enum token  op;
> + struct val  *l, *r;
> + enum token   op;
> + volatile int64_t res;
>  
>   l = eval5();
>   while ((op = token) == MUL || op == DIV || op == MOD) {
> @@ -316,7 +322,10 @@ eval4(void)
>   }
>  
>   if (op == MUL) {
> - l->u.i *= r->u.i;
> + res = l->u.i * r->u.i;
> + if (r->u.i != 0 && l->u.i != res / r->u.i)
> + errx(3, "overflow");
> + l->u.i = res;
>   } else {
>   if (r->u.i == 0) {
>   errx(2, "division by zero");
> @@ -324,6 +333,8 @@ eval4(void)
>   if (op == DIV) {
>   if (l->u.i != INT64_MIN || r->u.i != -1)
>   l->u.i /= r->u.i;
> + else
> + errx(3, "overflow");
>   } else {
>   if (l->u.i != INT64_MIN || r->u.i != -1)
>   l->u.i %= r->u.i;
> @@ -342,8 +353,9 @@ eval4(void)
>  struct val *
>  eval3(void)
>  {
> - struct val *l, *r;
> - enum token  op;
> + struct val  *l, *r;
> + enum token   op;
> + volatile int64_t res;
>  
>   l = eval4();
>   while ((op = token) == ADD || op == SUB) {
> @@ -355,9 +367,18 @@ eval3(void)
>   }
>  
>   if (op == ADD) {
> - l->u.i += r->u.i;

Re: manpage text width

[lists]

Fri, 30 Mar 2018 08:23:12 -0700 Chris Bennett

> On Thu, Mar 29, 2018 at 11:57:43PM +, Ingo Schwarze wrote:
> > I *could* maybe teach man(1) to honour $COLUMN by default when
> > starting up in interactive mode, but i did not do so for the following
> > reasons:
> > 
> >  * Many people are using terminals wider than 80 columns, but
> >texts get hard to read when much wider than that.  Very long
> >lines become hard to follow.  (That's why newspapers usually
> >have columns of even less than 80 characters, but they don't
> >have as much indentation as manual pages either.)  
> 
> This is very important. Our brains just are not good at working with
> long lines. This is hard-wired. If anyone doesn't believe me, try

Hi Chris,

Technical limitation of historic hardware, miscellaneous topics > misc@

https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_format_and_character_codes
https://en.wikipedia.org/wiki/Characters_per_line#History

Kind regards,
Anton Lazarov

[PATCH] src/etc/root/root.mail - URLs -> URL

[Raf Czlonka]

Hi all,

A small typo - plural -> singular.

Regards,

Raf

Index: etc/root/root.mail
===
RCS file: /cvs/src/etc/root/root.mail,v
retrieving revision 1.127
diff -u -p -r1.127 root.mail
--- etc/root/root.mail  23 Mar 2018 15:45:56 -  1.127
+++ etc/root/root.mail  30 Mar 2018 22:02:39 -
@@ -27,7 +27,7 @@ find further information regarding confi
 
 Several popular binary packages (pre-compiled applications) are
 available from mirror sites.  Mirror selection is usually automatic
-during install/upgrade -- a mirror URLs from https://www.openbsd.org/ftp.html
+during install/upgrade -- a mirror URL from https://www.openbsd.org/ftp.html
 is stored into the file /etc/installurl.  Installation of packages is
 as simple as:
 

[PATCH] xenocara/distrib/notes - remove problem_blurb

[Raf Czlonka]

Hi all,

problem_blurb hasn't been used in nearly 10 years[0].
Time to let it go?

Remove two trailing empty lines while there.

[0] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/distrib/notes/m4.common.diff?r1=1.3=1.4=h

Regards,

Raf

Index: distrib/notes/README.alpha
===
RCS file: /cvs/xenocara/distrib/notes/README.alpha,v
retrieving revision 1.4
diff -u -p -r1.4 README.alpha
--- distrib/notes/README.alpha  19 Feb 2011 19:51:53 -  1.4
+++ distrib/notes/README.alpha  30 Mar 2018 21:56:16 -
@@ -3,6 +3,4 @@ Post-installation instructions for X.Org
 
 There is no X server for alpha.  Only userland X.
 
-problem_blurb
-
 $OpenBSD: README.alpha,v 1.4 2011/02/19 19:51:53 matthieu Exp $
Index: distrib/notes/README.amd64
===
RCS file: /cvs/xenocara/distrib/notes/README.amd64,v
retrieving revision 1.12
diff -u -p -r1.12 README.amd64
--- distrib/notes/README.amd64  27 Feb 2017 21:16:05 -  1.12
+++ distrib/notes/README.amd64  30 Mar 2018 21:56:16 -
@@ -27,6 +27,4 @@ Conventions used in this document:
 
See Xorg(1) and xorg.conf(5) for details.
 
-problem_blurb
-
 $OpenBSD: README.amd64,v 1.12 2017/02/27 21:16:05 matthieu Exp $
Index: distrib/notes/README.arm64
===
RCS file: /cvs/xenocara/distrib/notes/README.arm64,v
retrieving revision 1.1
diff -u -p -r1.1 README.arm64
--- distrib/notes/README.arm64  3 Feb 2017 04:34:10 -   1.1
+++ distrib/notes/README.arm64  30 Mar 2018 21:56:16 -
@@ -3,7 +3,4 @@ Post-installation instructions for X.Org
 
 There is no X server for arm64.  Only userland X.
 
-problem_blurb
-
 $OpenBSD: README.arm64,v 1.1 2017/02/03 04:34:10 jsg Exp $
-
Index: distrib/notes/README.armv7
===
RCS file: /cvs/xenocara/distrib/notes/README.armv7,v
retrieving revision 1.1
diff -u -p -r1.1 README.armv7
--- distrib/notes/README.armv7  9 Sep 2013 13:38:33 -   1.1
+++ distrib/notes/README.armv7  30 Mar 2018 21:56:16 -
@@ -3,7 +3,4 @@ Post-installation instructions for X.Org
 
 There is no X server for armv7.  Only userland X.
 
-problem_blurb
-
 $OpenBSD: README.armv7,v 1.1 2013/09/09 13:38:33 patrick Exp $
-
Index: distrib/notes/README.hppa
===
RCS file: /cvs/xenocara/distrib/notes/README.hppa,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README.hppa
--- distrib/notes/README.hppa   27 Nov 2006 11:25:45 -  1.1.1.1
+++ distrib/notes/README.hppa   30 Mar 2018 21:56:16 -
@@ -3,6 +3,4 @@ Post-installation instructions for X.Org
 
 There is no X server for hppa.  Only userland X.
 
-problem_blurb
-
 $OpenBSD: README.hppa,v 1.1.1.1 2006/11/27 11:25:45 matthieu Exp $
Index: distrib/notes/README.i386
===
RCS file: /cvs/xenocara/distrib/notes/README.i386,v
retrieving revision 1.12
diff -u -p -r1.12 README.i386
--- distrib/notes/README.i386   27 Feb 2017 21:16:05 -  1.12
+++ distrib/notes/README.i386   30 Mar 2018 21:56:16 -
@@ -27,6 +27,4 @@ Conventions used in this document:
 
See Xorg(1) and xorg.conf(5) for details.
 
-problem_blurb
-
 $OpenBSD: README.i386,v 1.12 2017/02/27 21:16:05 matthieu Exp $
Index: distrib/notes/README.landisk
===
RCS file: /cvs/xenocara/distrib/notes/README.landisk,v
retrieving revision 1.1
diff -u -p -r1.1 README.landisk
--- distrib/notes/README.landisk12 May 2007 10:24:28 -  1.1
+++ distrib/notes/README.landisk30 Mar 2018 21:56:16 -
@@ -3,6 +3,4 @@ Post-installation instructions for X.Org
 
 There is no X server for landisk.  Only userland X.
 
-problem_blurb
-
 $OpenBSD: README.landisk,v 1.1 2007/05/12 10:24:28 matthieu Exp $
Index: distrib/notes/README.loongson
===
RCS file: /cvs/xenocara/distrib/notes/README.loongson,v
retrieving revision 1.5
diff -u -p -r1.5 README.loongson
--- distrib/notes/README.loongson   26 Feb 2017 16:39:22 -  1.5
+++ distrib/notes/README.loongson   30 Mar 2018 21:56:16 -
@@ -16,6 +16,4 @@ getty in /etc/ttys.
 
 Alternatively, you can log in at the console and run `startx'.
 
-problem_blurb
-
 $OpenBSD: README.loongson,v 1.5 2017/02/26 16:39:22 matthieu Exp $
Index: distrib/notes/README.luna88k
===
RCS file: /cvs/xenocara/distrib/notes/README.luna88k,v
retrieving revision 1.4
diff -u -p -r1.4 README.luna88k
--- distrib/notes/README.luna88k26 Feb 2017 16:39:22 -  1.4
+++ distrib/notes/README.luna88k30 Mar 2018 21:56:16 -
@@ -15,6 +15,4 @@ getty in /etc/ttys.
 
 Alternatively, you can log in on console and use `startx'.
 

shutdown(8): include timezone in deadline estimates

[Scott Cheloha]

Hey,

Shutting down a box at the wrong time of day could be bad.  Admins
are not infallible and they do they necessarily reside in the same
timezone as a given box.

Users, too, don't necessarily reside in the same timezone as
a given box, so broadcasting that the box is going down at
"23:00" could be misleading.

So, always print/log/broadcast the machine's local timezone when
we can, giving an admin an opportunity to correct the mistake, or
a user a better understanding of precisely when it's going to happen.

This patch also updates the process' understanding of the current
time before printing the estimated shutdown time everywhere.  It's
possible for the system wall clock to change after a shutdown is
scheduled, which would make subsequent warning broadcasts inaccurate
and might mislead the users on the system.

ok?

--
Scott Cheloha

Index: sbin/shutdown/shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.50
diff -u -p -r1.50 shutdown.c
--- sbin/shutdown/shutdown.c19 Mar 2018 14:51:45 -  1.50
+++ sbin/shutdown/shutdown.c30 Mar 2018 20:01:31 -
@@ -98,7 +98,7 @@ void doitfast(void);
 void __dead finish(int);
 void getoffset(char *);
 void __dead loop(void);
-void nolog(void);
+void nolog(time_t);
 void timeout(int);
 void timewarn(time_t);
 void usage(void);
@@ -106,9 +106,11 @@ void usage(void);
 int
 main(int argc, char *argv[])
 {
-   int arglen, ch, len, readstdin = 0;
-   struct passwd *pw;
+   char when[64];
char *p, *endp;
+   struct passwd *pw;
+   struct tm *lt;
+   int arglen, ch, len, readstdin = 0;
pid_t forkpid;
 
if (pledge("stdio rpath wpath cpath getpw tty id proc exec", NULL) == 
-1)
@@ -198,15 +200,16 @@ main(int argc, char *argv[])
}
mbuflen = strlen(mbuf);
 
-   if (offset) {
-   char *ct = ctime();
-
-   if (ct)
-   printf("Shutdown at %.24s.\n", ct);
-   else
+   if (offset > 0) {
+   shuttime = time(NULL) + offset;
+   lt = localtime();
+   if (lt != NULL) {
+   strftime(when, sizeof(when), "%a %b %e %T %Z %Y", lt);
+   printf("Shutdown at %s.\n", when);
+   } else
printf("Shutdown soon.\n");
} else
-   (void)printf("Shutdown NOW!\n");
+   printf("Shutdown NOW!\n");
 
if (!(whom = getlogin()))
whom = (pw = getpwuid(getuid())) ? pw->pw_name : "???";
@@ -261,7 +264,7 @@ loop(void)
broadcast = 1;
if (!logged && tlist[i].timeleft <= NOLOG_TIME) {
logged = 1;
-   nolog();
+   nolog(tlist[i].timeleft);
}
timeout.tv_sec = tlist[i].timetowait;
timeout.tv_nsec = 0;
@@ -279,6 +282,8 @@ void
 timewarn(time_t timeleft)
 {
static char hostname[HOST_NAME_MAX+1];
+   char when[64];
+   struct tm *lt;
static int first;
int fd[2];
pid_t pid, wpid;
@@ -317,11 +322,17 @@ timewarn(time_t timeleft)
"\007*** %sSystem shutdown message from %s@%s ***\007\n",
timeleft ? "": "FINAL ", whom, hostname);
 
-   if (timeleft > 10*60) {
-   struct tm *tm = localtime();
-
-   dprintf(fd[1], "System going down at %d:%02d\n\n",
-   tm->tm_hour, tm->tm_min);
+   if (timeleft > 10 * 60) {
+   shuttime = time(NULL) + timeleft;
+   lt = localtime();
+   if (lt != NULL) {
+   strftime(when, sizeof(when), "%H:%M %Z", lt);
+   dprintf(fd[1], "System going down at %s\n\n", when);
+   } else {
+   dprintf(fd[1], "System going down in %lld hour%s\n\n",
+   (long long)(timeleft / 3600),
+   (timeleft >= 7200) ? "s" : "");
+   }
} else if (timeleft > 59) {
dprintf(fd[1], "System going down in %lld minute%s\n\n",
(long long)(timeleft / 60), (timeleft > 60) ? "s" : "");
@@ -464,6 +475,7 @@ die_you_gravy_sucking_pig_dog(void)
 void
 getoffset(char *timearg)
 {
+   char when[64];
const char *errstr;
struct tm *lt;
int this_year;
@@ -475,13 +487,11 @@ getoffset(char *timearg)
return;
}
 
-   (void)time();
if (timearg[0] == '+') {/* +minutes */
minutes = strtonum(timearg, 0, INT_MAX, );
if (errstr)
errx(1, "relative offset is %s: %s", errstr, timearg);
offset = minutes * 60;
-   shuttime = now + offset;
return;
}
 
@@ -498,6 +508,7 @@ getoffset(char *timearg)
}
 
  

Should rm(1) -Pf change file permission?

[Grégoire Jadi]

Hello,

While working on a port of keyringer, I observed the following behavior
of rm(1) with the -P option: if the file does not have write permission,
the file is removed without being overwritten.

This is not the same behavior as shred(1) (from sysutils/coreutils) which do
not remove the file if it cannot be overwritten. If the -f option is
used with shred(1), the permission of the file are changed to allow
writing if necessary.

Is the current behavior desired? (need to update the manpage?)

Or should `rm -P` and `rm -Pf` have the same behavior as shred. That is:
`rm -P` should fail without removing the file if the file cannot be
overwritten and `rm -Pf` should change the permission and overwrite
file.


Here are excerpts from rm(1) and shred(1) manpages:
rm(1)
 -f  Attempt to remove the files without prompting for confirmation,
 regardless of the file's permissions.  If the file does not
 exist, do not display a diagnostic message or modify the exit
 status to reflect an error.  The -f option overrides any previous
 -i options.

 -P  Overwrite regular files before deleting them.  Files are
 overwritten once with a random pattern.  Files with multiple
 links will be unlinked but not overwritten.

shred(1)
   -f, --force
  change permissions to allow writing if necessary

And here is a small test to demonstrate this behavior:

$ echo bar > foo
$ chmod -w foo
$ rm -P foo
override r--r--r--  daimrod/wheel for foo? y
rm: foo: Permission denied
$ ls -l foo
ls: foo: No such file or directory

$ echo bar > foo
$ chmod -w foo
$ rm -Pf foo
rm: foo: Permission denied
$ ls -l foo
ls: foo: No such file or directory

$ echo bar > foo
$ chmod -w foo
$ gshred -u foo
gshred: foo: failed to open for writing: Permission denied
$ ls -l foo
-r--r--r--  1 daimrod  wheel  4 Mar 30 17:45 foo
$ gshred -uf foo
$ ls -l foo
ls: foo: No such file or directory

Best,

dd(1): overhaul operand parsing

[Scott Cheloha]

Hey,

This overhauls dd(1) operand parsing for expressions.

 - Eliminate duplicate code by using a single routine, get_expr().
   If we check for negative inputs we can use strtoull(3) safely,
   which covers the accepted input range for both off_t and size_t.

 - We can then use a single switch statement -- refactored here
   into a new routine, get_multiplier() -- for suffix evaluation.

 - This also lets us consolidate error handling.  We can provide
   better error messages if we catch invalid inputs in-place.  For
   instance, we no longer need to double-check whether cbs is zero,
   or if any of the other block sizes managed to wind up zero.

 - Parse iteratively with strsep(3).  The recursive parsing is clever,
   but it provides no advantages over iterative parsing.  It also allows
   for some pathological cases like the following, which overflows the
   stack on macppc:

count=$(perl -e 'print "1x"x10, "1"')

   Using strsep(3) is briefer and more familiar.

 - Catch all (I think?) multiplicative overflow.  Formerly, you could
   get away with something like:

2048x2147483649

   on a 32-bit architecture, or

2048x4611686018427387905

   on a 64-bit architecture.

   No more.  We check for overflow on the input, overflow
   when multiplying the input by the value of the suffix,
   and overflow when multiplying a new term by the product
   of the prior terms in the expression.

 - Standard dd(1) does not support hexidecimal or octal
   input.  BSD dd(1) does [1], but GNU dd(1) does not.

   Supporting both 'x' multiplication and hex input might
   be useful, but I think it's a bad idea from a parsing
   perspective.  I'm not sure if it makes the grammar ambiguous,
   but it does make it harder to reason about at a glance.
   What is the value of the following?

2x0x10K

   For us it's both a valid block size and a valid seek, but
   in GNU dd it's only valid as a seek or a count.

   That's a bit pathological, but I don't think enforcing decimal
   input, as prescribed by POSIX and adhered to by ancient dd(1) [1],
   makes dd(1) more annoying to use.  If you want hex or octal input
   you can eval it with the shell:

bs=$((0xFF))

   Perusing, e.g., github, this seems to be what most people
   do when they want hex in their scripts.

   Given that GNU dd doesn't try to parse hex input I'm pretty sure
   this will break nothing in ports, but I can audit if someone
   thinks it's worth it.

 - Somewhat less important, but using strtoull in a single routine
   as mentioned above uncouples the "count" and "files" operands from
   block sizes and offsets, which seems more appropriate.  They're
   counts, so they shouldn't be size_t, you know?

 - Disallow leading whitespace and leading plus ('+') characters.  We
   were already checking for leading minus ('-') characters with strchr(3),
   but just checking whether the first character is a digit is simpler.

   My thinking is that we should probably not allow something like the
   following:

bs="+64"

   which looks like it could be an error in someone's script.

   ... but this might be too strict.

Thoughts?

--
Scott Cheloha

[1] This seems to have happened when Keith Muller rewrote it.

Ancient BSD dd(1) only took integers:

https://github.com/dspinellis/unix-history-repo/blob/ebe7a4befa43c108621eccfe74a9d3afdffce0e/usr/src/bin/dd/dd.c#L389

But with the rewrite ca. 1991, operand parsing moved to args.c
and since then, hex/octal has been OK:

https://github.com/dspinellis/unix-history-repo/blob/71251a9529e71ac9602579b8b5fc5f8e4979d3a/usr/src/bin/dd/args.c#L344

I have no idea if this was accidental or not.

Index: bin/dd/args.c
===
RCS file: /cvs/src/bin/dd/args.c,v
retrieving revision 1.29
diff -u -p -r1.29 args.c
--- bin/dd/args.c   3 Jan 2018 19:12:20 -   1.29
+++ bin/dd/args.c   30 Mar 2018 02:23:57 -
@@ -39,8 +39,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -62,6 +64,9 @@ static void   f_skip(char *);
 static voidf_status(char *);
 static size_t  get_bsz(char *);
 static off_t   get_off(char *);
+static unsigned long long
+   get_expr(const char *, unsigned long long, unsigned long long);
+static long long get_multiplier(const char *);
 
 static const struct arg {
const char *name;
@@ -94,6 +99,7 @@ jcl(char **argv)
char *arg;
 
in.dbsz = out.dbsz = 512;
+   files_cnt = 1;
 
while ((oper = *++argv) != NULL) {
if ((oper = strdup(oper)) == NULL)
@@ -138,8 +144,6 @@ jcl(char **argv)
if (ddflags & (C_BLOCK|C_UNBLOCK)) {
if (!(ddflags & C_CBS))
errx(1, "record operations require cbs");
-   if (cbsz == 0)
-   errx(1, "cbs cannot be zero");
cfunc = ddflags & C_BLOCK ? block : 

expr: Fix integer overflows

[Tobias Stoeckmann]

Our expr implementation supports 64 bit integers, but does not check
for overflows during parsing and arithmetical operations.

This patch fixes the problems based on FreeBSD's implementation, which
is a bit more advanced than NetBSD, which it is based upon.

The added regression test case is taken from NetBSD and passes with
this patch.

Okay?


Tobias

Index: regress/bin/Makefile
===
RCS file: /cvs/src/regress/bin/Makefile,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 Makefile
--- regress/bin/Makefile14 Jan 2018 22:04:47 -  1.13
+++ regress/bin/Makefile30 Mar 2018 15:33:50 -
@@ -1,6 +1,6 @@
 #  $OpenBSD: Makefile,v 1.13 2018/01/14 22:04:47 bluhm Exp $
 
-SUBDIR+= cat chmod csh ed ksh ln md5 pax ps test
+SUBDIR+= cat chmod csh ed expr ksh ln md5 pax ps test
 
 install:
 
Index: bin/expr/expr.c
===
RCS file: /cvs/src/bin/expr/expr.c,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 expr.c
--- bin/expr/expr.c 19 Oct 2016 18:20:25 -  1.26
+++ bin/expr/expr.c 30 Mar 2018 15:33:50 -
@@ -99,6 +99,7 @@ is_integer(struct val *vp, int64_t *r)
char   *s;
int neg;
int64_t i;
+   charc;
 
if (vp->type == integer) {
*r = vp->u.i;
@@ -120,8 +121,12 @@ is_integer(struct val *vp, int64_t *r)
if (!isdigit((unsigned char)*s))
return 0;
 
+   c = *s - '0';
+   if (c < 0 || INT64_MAX / 10 < i || INT64_MAX - c < i * 10)
+   errx(3, "out of range");
+
i *= 10;
-   i += *s - '0';
+   i += c;
 
s++;
}
@@ -303,8 +308,9 @@ eval5(void)
 struct val *
 eval4(void)
 {
-   struct val *l, *r;
-   enum token  op;
+   struct val  *l, *r;
+   enum token   op;
+   volatile int64_t res;
 
l = eval5();
while ((op = token) == MUL || op == DIV || op == MOD) {
@@ -316,7 +322,10 @@ eval4(void)
}
 
if (op == MUL) {
-   l->u.i *= r->u.i;
+   res = l->u.i * r->u.i;
+   if (r->u.i != 0 && l->u.i != res / r->u.i)
+   errx(3, "overflow");
+   l->u.i = res;
} else {
if (r->u.i == 0) {
errx(2, "division by zero");
@@ -324,6 +333,8 @@ eval4(void)
if (op == DIV) {
if (l->u.i != INT64_MIN || r->u.i != -1)
l->u.i /= r->u.i;
+   else
+   errx(3, "overflow");
} else {
if (l->u.i != INT64_MIN || r->u.i != -1)
l->u.i %= r->u.i;
@@ -342,8 +353,9 @@ eval4(void)
 struct val *
 eval3(void)
 {
-   struct val *l, *r;
-   enum token  op;
+   struct val  *l, *r;
+   enum token   op;
+   volatile int64_t res;
 
l = eval4();
while ((op = token) == ADD || op == SUB) {
@@ -355,9 +367,18 @@ eval3(void)
}
 
if (op == ADD) {
-   l->u.i += r->u.i;
+   res = l->u.i + r->u.i;
+   if ((l->u.i > 0 && r->u.i > 0 && res <= 0) ||
+   (l->u.i < 0 && r->u.i < 0 && res >= 0))
+   errx(3, "overflow");
+   l->u.i = res;
} else {
-   l->u.i -= r->u.i;
+   res = l->u.i - r->u.i;
+   if ((r->u.i == INT64_MIN && l->u.i < 0) ||
+   (l->u.i > 0 && r->u.i < 0 && res <= 0) ||
+   (l->u.i < 0 && r->u.i > 0 && res >= 0))
+   errx(3, "overflow");
+   l->u.i = res;
}
 
free_value(r);
Index: regress/bin/expr/Makefile
===
RCS file: regress/bin/expr/Makefile
diff -N regress/bin/expr/Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ regress/bin/expr/Makefile   30 Mar 2018 15:33:50 -
@@ -0,0 +1,8 @@
+# $OpenBSD$
+
+REGRESS_TARGETS = expr
+
+expr:
+   sh ${.CURDIR}/expr.sh
+
+.include 
Index: regress/bin/expr/expr.sh
===
RCS file: regress/bin/expr/expr.sh
diff -N regress/bin/expr/expr.sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ regress/bin/expr/expr.sh30 Mar 2018 15:33:50 -
@@ -0,0 +1,98 @@
+#!/bin/ksh
+
+: ${EXPR=expr}
+
+function test_expr {
+   #echo "Testing: `eval echo $1`"
+   res=`eval $EXPR $1 2>&1`

Re: manpage text width

[Chris Bennett]

On Thu, Mar 29, 2018 at 11:57:43PM +, Ingo Schwarze wrote:
> I *could* maybe teach man(1) to honour $COLUMN by default when
> starting up in interactive mode, but i did not do so for the following
> reasons:
> 
>  * Many people are using terminals wider than 80 columns, but
>texts get hard to read when much wider than that.  Very long
>lines become hard to follow.  (That's why newspapers usually
>have columns of even less than 80 characters, but they don't
>have as much indentation as manual pages either.)

This is very important. Our brains just are not good at working with
long lines. This is hard-wired. If anyone doesn't believe me, try
setting your browser window to a narrower width or use reader mode.
We read by mapping things out on the line. If it's too long, our brains
get "confused" and information is lost.

This is a problem with textbooks. The wide pages are needed for pictures
and diagrams, but the text should be written in narrower columns.

It's interestng that older hardware caused us to use narrow widths, but
that turns out to be best anyway.

Could anybody really follow code written at 200 columns width?

Chris Bennett

Re: manpage text width

[Klemens Nanni]

On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote:
> When you want a manpage to exactly fill the available terminal width,
> you can use an alias like this:
> 
>   $ alias wman='man -Owidth=$COLUMNS'# or
>   $ alias wman='man -Owidth=$((COLUMNS-2))'
> 
> Of course, if you change the terminal width while man(1) is open,
> you will have to do: q Ctrl-p  to reformat.
There's also `fc' for that, nicely wrapped in ksh by default:

$ type r
r is an alias for 'fc -s'

For tmux, I'm used to having the right-most pane reserved for manual
pages. The following tmux.conf helps a lot:

bind M resize-pane -x 82

Re: manpage text width

[Paul Irofti]

Hi Ingo,

Thanks for the detailed reply. I was expecting it :)

>  * Nowadays, i guess that terminals narrower than 80 columns
>have become seriously rare, so there is not very widespread
>benefit for that case.

Maybe that was true when we still had 4:3 screens, but now I always
have 2 or 3 80 column xterms and space for another that is around 60
columns.

I always use the small one for trivial tasks like searching for
something in the filesystem, doing some calculations or, you guessed it,
reading a manpage.

>   $ alias wman='man -Owidth=$COLUMNS'# or
>   $ alias wman='man -Owidth=$((COLUMNS-2))'

So I guess a better choice would be:

$ alias man='man -Owidth=$(($COLUMNS<80?($COLUMNS-2):78))'

which is EXACTLY what I was looking for! Can it be the default? :)

Thank you,
Paul

Re: manpage text width

[Juan Francisco Cantero Hurtado]

On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote:
> Hi Paul,
> 
> Theo de Raadt wrote on Thu, Mar 29, 2018 at 04:17:14PM -0600:
> > piroft@ wrote:
> 
> >> Is there any reason why manpage text does not resize nicely
> >> with <80 columns xterms?
> 
> I want to avoid excessive magic.
> 
> By the way, actually, the default width is 78, not 80.
> By tradition.
> 
> >> Is it because of less(1)?
> 
> No.  less(1) always wraps and re-wraps its input file to fit the
> terminal width.  Of course, it preserves existing line breaks, it
> only adds new ones, and it adds the new ones after the last character
> that fits on each line, possibly in the middle of words and numbers.
> 
> > Can I do anything to fix this?
> 
> Yes.
> 
> When you want a manpage to exactly fill the available terminal width,
> you can use an alias like this:
> 
>   $ alias wman='man -Owidth=$COLUMNS'# or
>   $ alias wman='man -Owidth=$((COLUMNS-2))'
> 
> Of course, if you change the terminal width while man(1) is open,
> you will have to do: q Ctrl-p  to reformat.
> 
> I do *NOT* want to add SIGWINCH signal handling to man(1) to abort
> less(1), reformat, and respawn less(1) in that case.  That kind of
> magic would be over the top, and SIGWINCH is an abomination in the
> first place.
> 
> If you are in the habit of always using 65-column terminals on a given
> machine, this is another option:
> 
>   # echo output width 64 >> /etc/man.conf
> 
> I *could* maybe teach man(1) to honour $COLUMN by default when
> starting up in interactive mode, but i did not do so for the following
> reasons:
> 
>  * Many people are using terminals wider than 80 columns, but
>texts get hard to read when much wider than that.  Very long
>lines become hard to follow.  (That's why newspapers usually
>have columns of even less than 80 characters, but they don't
>have as much indentation as manual pages either.)

I'm not asking for this feature but CSS has max-width for cases like
this in HTML. It always fills the width until the maximum.

>  * Nowadays, i guess that terminals narrower than 80 columns
>have become seriously rare, so there is not very widespread
>benefit for that case.
>  * Even if someone does use a narrower terminal, formatting will
>be somewhat poor with the matching -Owidth.  Some text, in
>particular literal displays, will still overflow and wrap in
>less(1), and text with large indentations will become
>ridiculously narrow.
>One thing jmc@ does is trying to make sure that pages do not
>only read well, but also look visually nice, and much of that
>work is optimized for the default -Owidth=78.
>So even for narrower terminals, i'd rather leave the decision
>to the user.
>  * Setting up an alias as explained above is quite easy.
> 
> What i could maybe do is recognize "-Owidth=auto" and "output width
> auto" in man.conf(5) and use $COLUMNS in that case, but even that
> would require some additional code, and so far, i didn't notice
> much demand.
> 
> > It is pre-formatted.
> 
> Only in the sense than man(1) completes the formatting before it
> forks and executes less(1).  Only the manual pages of 25 (out of
> 9900) ports are still preformatted at port build time, and none in
> the base system and Xenocara are preformatted at system build time.
> 
> Yours,
>   Ingo
> 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: return packets may not be desired to be scrubbed

[Peter J. Philipp]

On Thu, Mar 29, 2018 at 10:01:02PM +0200, Peter J. Philipp wrote:
...
> The end result is here.  I add 2 arguments to pf_scrub() for rule/state
> direction that is desired and direction that the packet is taking.  Then
> in random-id the logic does not scrub when we had an "outbound scrub" and
> the packets direction is inbound.
> 
> Happy Easter!  May your pf get a little faster!
> 
> -peter

I'd like to retract this patch.  Sorry, it doesn't do what I expected, I
didn't test it well enough, and did just now and it doesn't do what I had
imagined.  I'll re-visit this some time later.  Happy Easter, again!

Regards,
-peter