Klemens Nanni(k...@openbsd.org) on 2023.10.26 13:28:42 +:
> On Tue, Oct 24, 2023 at 09:09:21AM +0200, Peter N. M. Hansteen wrote:
> > On Tue, Oct 24, 2023 at 06:54:30AM +, Klemens Nanni wrote:
> > > - parse.y still accepting undocumented "ssl" with a warning since 2014
> > > - more "SSL/TLS
On Tue, Oct 24, 2023 at 09:09:21AM +0200, Peter N. M. Hansteen wrote:
> On Tue, Oct 24, 2023 at 06:54:30AM +, Klemens Nanni wrote:
> > - parse.y still accepting undocumented "ssl" with a warning since 2014
> > - more "SSL/TLS" instead of "TLS" in manual and code comments
>
> my take would be t
On Tue, Oct 24, 2023 at 06:54:30AM +, Klemens Nanni wrote:
> - parse.y still accepting undocumented "ssl" with a warning since 2014
> - more "SSL/TLS" instead of "TLS" in manual and code comments
my take would be that while it's fine to streamline the documentation to use
the modern terminolog
Wanted to learn about TLS usage in relayd(8) and thought these SSL history
bits in the TLS RELAYS section read out of place.
Index: relayd.conf.5
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v
retrieving revision 1.206
diff -u
On Fri, Jun 09, 2023 at 08:10:22PM +0200, Jan Klemkow wrote:
> On Fri, Jun 09, 2023 at 06:59:57PM +0200, Jan Klemkow wrote:
> > On Fri, Jun 09, 2023 at 06:11:38PM +0200, Jan Klemkow wrote:
> > > TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
> > > allocate IXGBE_TSO_SIZE (256
On Fri, Jun 09, 2023 at 06:59:57PM +0200, Jan Klemkow wrote:
> On Fri, Jun 09, 2023 at 06:11:38PM +0200, Jan Klemkow wrote:
> > TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
> > allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
> >
> > This saves 3/4 of th
On Fri, Jun 09, 2023 at 06:11:38PM +0200, Jan Klemkow wrote:
> TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
> allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
>
> This saves 3/4 of the memory and allows me to pack over 8 ix(8) ports
> into one machine.
Hi,
TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
This saves 3/4 of the memory and allows me to pack over 8 ix(8) ports
into one machine. Otherwise I run out of devbuf in malloc(9).
ok?
bye,
Jan
Index:
On Wed, May 10, 2023 at 10:08:09AM +0200, Theo Buehler wrote:
> > Thanks! It has been committed. I doubt though if the Go runtime uses
> > libc malloc.
>
> I don't know if the pure Go runtime uses libc malloc. However, some
> of the test code involves cgo and calls into various C libraries
> incl
> Thanks! It has been committed. I doubt though if the Go runtime uses
> libc malloc.
I don't know if the pure Go runtime uses libc malloc. However, some
of the test code involves cgo and calls into various C libraries
including libcrypto. So it definitely exercised malloc in a threaded
environmen
On Tue, May 09, 2023 at 09:55:32PM +0200, Theo Buehler wrote:
> On Thu, May 04, 2023 at 03:40:35PM +0200, Otto Moerbeek wrote:
> > On Thu, Apr 27, 2023 at 02:17:10PM +0200, Otto Moerbeek wrote:
> >
> > > This was introduced to not stall other threads while mmap is called by
> > > a thread. But no
On Thu, May 04, 2023 at 03:40:35PM +0200, Otto Moerbeek wrote:
> On Thu, Apr 27, 2023 at 02:17:10PM +0200, Otto Moerbeek wrote:
>
> > This was introduced to not stall other threads while mmap is called by
> > a thread. But now that mmap is unlocked, I believe it is no longer
> > useful.
> >
> > A
On Mon, May 08, 2023 at 02:29:12PM +0200, Alexander Bluhm wrote:
> Hi,
>
> The call to in_proto_cksum_out() is only needed before the packet
> is passed to ifp->if_output(). The fragment code has its own
> checksum calculation and the other paths end in goto bad.
>
> My TSO tcp_copper() will als
Hi,
The call to in_proto_cksum_out() is only needed before the packet
is passed to ifp->if_output(). The fragment code has its own
checksum calculation and the other paths end in goto bad.
My TSO tcp_copper() will also do its own checksum handling, so I
have to move the call to in_proto_cksum_ou
On Thu, Apr 27, 2023 at 02:17:10PM +0200, Otto Moerbeek wrote:
> This was introduced to not stall other threads while mmap is called by
> a thread. But now that mmap is unlocked, I believe it is no longer
> useful.
>
> A full build is slighlty faster with this. But this also needs testing
> with
On Wed, May 03, 2023 at 12:22:16AM +0200, Alexander Bluhm wrote:
> Hi,
>
> Some checks in nd6_resolve() do not require kernel lock. The analog
> code for ARP has been unlocked in if_ether.c revision 1.250 since
> 2022/06/27 20:47:10.
Same diff here, thought I sent/committed that already.
OK kn i
Hi,
Some checks in nd6_resolve() do not require kernel lock. The analog
code for ARP has been unlocked in if_ether.c revision 1.250 since
2022/06/27 20:47:10.
ok?
bluhm
Index: netinet6/nd6.c
===
RCS file: /data/mirror/openbsd/cvs/
This was introduced to not stall other threads while mmap is called by
a thread. But now that mmap is unlocked, I believe it is no longer
useful.
A full build is slighlty faster with this. But this also needs testing
with you favorite multithreaded program.
-Otto
Index: stdlib/malloc.c
=
On 14.10.2022. 23:57, Mikolaj Kucharski wrote:
> Kind reminder. Below there is a comment with an OK from sthen@
>
> Diff at the end of this email.
>
>
Hi all,
can this diff be committed? Less verbose output of ifconfig wg interface
is quite nice when handling wg vpn server
Th
Kind reminder. Below there is a comment with an OK from sthen@
Diff at the end of this email.
On Wed, Sep 07, 2022 at 05:29:38PM +0100, Stuart Henderson wrote:
> On 2022/09/07 15:25, Mikolaj Kucharski wrote:
> > Hi.
> >
> > I didn't get a lof of feedback on this on the code level, however
> > g
Kind reminder.
Below diff at https://marc.info/?l=openbsd-tech&m=166256415030704&w=2
On Wed, Sep 07, 2022 at 03:25:58PM +, Mikolaj Kucharski wrote:
> Hi.
>
> I didn't get a lof of feedback on this on the code level, however
> got some intput on manual page changes. At the end of the email i
On 2022/09/07 15:25, Mikolaj Kucharski wrote:
> Hi.
>
> I didn't get a lof of feedback on this on the code level, however
> got some intput on manual page changes. At the end of the email is
> ifconfig.8 change from jmc@ and ifconfig.c from me.
>
>
> On Sat, Sep 03, 2022 at 04:51:03PM +0100, Jas
Hi.
I didn't get a lof of feedback on this on the code level, however
got some intput on manual page changes. At the end of the email is
ifconfig.8 change from jmc@ and ifconfig.c from me.
On Sat, Sep 03, 2022 at 04:51:03PM +0100, Jason McIntyre wrote:
> On Sat, Sep 03, 2022 at 08:55:51AM +,
On Sat, Sep 03, 2022 at 08:55:51AM +, Mikolaj Kucharski wrote:
> Hi,
>
> I tried to address what jmc@ mentioned below. I don't really know
> mdoc(7) and English is not my native language, so I imagine there is
> place for improvement in the wg(4) diff.
>
hi.
after looking again, i think may
Hi,
I tried to address what jmc@ mentioned below. I don't really know
mdoc(7) and English is not my native language, so I imagine there is
place for improvement in the wg(4) diff.
Full diff at the very end of this email, below here `diff -wu` to
visualize how minimal ifconfig.c changes are:
| I
On Sat, Aug 20, 2022 at 02:25:25PM +0100, Stuart Henderson wrote:
> >
> > Long output with as an argument, wgpeers section present:
> >
> > pce-0067# ifconfig.ifaliases wg0
> > wg0: flags=80c3 mtu 1420
> > index 8 priority 0 llprio 3
> > wgport 51820
> > wgpubkey qcb...
>
the behaviour of ifconfig(8) make sense?
> - Does the code which makes above, make sense?
I think so, and the diff works exactly as I would expect it to.
> This is minimal diff, I would appreciate feedback, I did least
> resistance approach. Looking at diff -wu shows even less changes
&
the behaviour of ifconfig(8) make sense?
> - Does the code which makes above, make sense?
>
> This is minimal diff, I would appreciate feedback, I did least
> resistance approach. Looking at diff -wu shows even less changes
> as wg_status() is mainly identation with if-statement.
>
On Mon, Jul 18, 2022 at 03:46:05PM +0200, Claudio Jeker wrote:
> Noticed the other day, when the RDE dies the session engine may log the
> "Can't send message %u to RDE, ctl pipe closed" multiple times because
> the queue is still processed.
>
> Since this error only happens after a "SE: Lost conn
Noticed the other day, when the RDE dies the session engine may log the
"Can't send message %u to RDE, ctl pipe closed" multiple times because
the queue is still processed.
Since this error only happens after a "SE: Lost connection to RDE" error
it does not anything to the crash log. This is why t
?
This is minimal diff, I would appreciate feedback, I did least
resistance approach. Looking at diff -wu shows even less changes
as wg_status() is mainly identation with if-statement.
Short output by default, only 6 lines, no wgpeers section:
pce-0067# ifconfig.ifaliases -a | tail -n6
wg0: flags=80c3
> Date: Wed, 18 May 2022 21:43:29 +0200
> From: Alexander Bluhm
>
> On Tue, May 17, 2022 at 07:20:49PM +, Miod Vallat wrote:
> > As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
> > POWER processors define exception addresses past EXC_LAST.
> >
> > The following diff
On Tue, May 17, 2022 at 07:20:49PM +, Miod Vallat wrote:
> As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
> POWER processors define exception addresses past EXC_LAST.
>
> The following diff changes EXC_LAST to no longer be the last
> "traditional" (0x100 bytes long) e
> > As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
> > POWER processors define exception addresses past EXC_LAST.
>
> Erh, wait, not really. EXC_AST is "fake" and EXC_USER is a flag that
> indicates we came from userland.
I was referring to the few hardware vectors abov
> Date: Tue, 17 May 2022 19:20:49 +
> From: Miod Vallat
>
> As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
> POWER processors define exception addresses past EXC_LAST.
Erh, wait, not really. EXC_AST is "fake" and EXC_USER is a flag that
indicates we came from userl
As seen in sys/arch/powerpc64/include/trap.h, not-so-ancient PowerPC and
POWER processors define exception addresses past EXC_LAST.
The following diff changes EXC_LAST to no longer be the last
"traditional" (0x100 bytes long) exception address, but the
(conveniently page-aligned) end of the except
out to the one
I've sent because it modifies less lines of code.
So if nobody objects, I will use your version.
Tobias
On Fri, Dec 31, 2021 at 6:22 AM Tobias Stoeckmann
wrote:
> Hi,
>
> it is possible to trigger a use after free bug in less with huge
> files or tight memory constraints. PoC with 100 MB file:
>
> dd if=/dev/zero bs=1024 count=102400 | tr '\0' 'a' > le
Hi,
it is possible to trigger a use after free bug in less with huge
files or tight memory constraints. PoC with 100 MB file:
dd if=/dev/zero bs=1024 count=102400 | tr '\0' 'a' > less-poc.txt
ulimit -d 157286
less less-poc.txt
The linebuf and attr buffers in line.c a
On Fri, Dec 10, 2021 at 03:04:11PM GMT, Richard Ulmer wrote:
> Hi,
> this is just a minor copy-and-paste error fix for the less(1) man page.
> I also contributed this upstream: https://github.com/gwsw/less/pull/228
Hi Richard,
You might want to consider reporting it to less-fork[0] whic
Hi Richard,
Richard Ulmer wrote on Fri, Dec 10, 2021 at 04:04:11PM +0100:
> this is just a minor copy-and-paste error fix for the less(1) man page.
Committed, thank you.
> I also contributed this upstream: https://github.com/gwsw/less/pull/228
>
> I hope this is the right mail
On Sat, 09 Oct 2021 13:15:39 +0200, Tobias Stoeckmann wrote:
> this merges latest bugfixes from upstream to our version of less.
> No new features introduced. Upstream commits and issues are linked as
> references.
OK millert@
- todd
Hi,
this merges latest bugfixes from upstream to our version of less.
No new features introduced. Upstream commits and issues are linked as
references.
brac.c:
Signed integer overflow with huge files.
https://github.com/gwsw/less/pull/210
https://github.com/gwsw/less/commit
Tobias Stoeckmann(tob...@stoeckmann.org) on 2021.09.21 22:23:55 +0200:
> Hi,
>
> upstream (greenwood) less has disabled history file support for secure
> mode, i.e. LESSSECURE=1: https://github.com/gwsw/less/pull/201
>
> The problem was about permanent marks for which we d
Hi,
upstream (greenwood) less has disabled history file support for secure
mode, i.e. LESSSECURE=1: https://github.com/gwsw/less/pull/201
The problem was about permanent marks for which we do not have support
anyway. Users could possibly access files they should not be able to.
Since upstream
> >
> > I'm ok with this.
> >
> > Should we assert after the for loops that we added as many filehashes or
> > addresses as allocated? This is currently more obvious than after this
> > change.
>
> Hmm. The code is correct even if it loads less elements.
as allocated? This is currently more obvious than after this
> change.
Hmm. The code is correct even if it loads less elements. It will
overallocate but with NULL. Also currently the code fails hard if an
element does not parse. So not sure about that.
> > --
> > :wq Claudio
&g
On Wed, Sep 08, 2021 at 03:05:41PM +0200, Claudio Jeker wrote:
> Looking at profiling information and the code made me realize that these
> recallocarray calls growing the array by one every time are unnecessary.
> The size of the array is known in advance so use that information and
> build it up
Looking at profiling information and the code made me realize that these
recallocarray calls growing the array by one every time are unnecessary.
The size of the array is known in advance so use that information and
build it up ahead of time.
In the roa case the IP list is double nested and so one
ility in less. Instead of !echo
> a > % and !echo b > %, run
> $ echo a > /tmp/test
> Press h and q in less to reload the file
> $ echo b > /tmp/test
> Press h and q in less to reload the file
>
> On Thu, Aug 05, 2021 at 12:37:00AM -0500, user wrote:
> > Bug
3, 2021 at 11:15:59AM -0500, user wrote:
>
> >>> Less contains a hack to force files of size 0 to become non-seekable
> >>> in order to workaround a linux kernel bug.
>
> I'm inserting a few words into the next sentence to make it clearer
> what it is tr
> Any developer willing to provide an OK?
ok tb
Hi,
after quite some head-scratching, i consider the following bug report
legitimate:
user wrote on Thu, Aug 05, 2021 at 12:43:21AM -0500:
> On Thu, Aug 05, 2021 at 12:37:00AM -0500, user wrote:
>> On Fri, Jul 23, 2021 at 11:15:59AM -0500, user wrote:
>>> Less contains a hack
Oops, forgot that OpenBSD doesn't have ! capability in less. Instead of !echo a
> % and !echo b > %, run
$ echo a > /tmp/test
Press h and q in less to reload the file
$ echo b > /tmp/test
Press h and q in less to reload the file
On Thu, Aug 05, 2021 at 12:37:00AM -0500,
Bug Reproduction:
$ touch /tmp/test
$ less /tmp/test
Press r
Run !echo a > %
Run !echo b > %
Output:
a
b
On Fri, Jul 23, 2021 at 11:15:59AM -0500, user wrote:
> Less contains a hack to force files of size 0 to become non-seekable in order
> to workaround a linux kernel bug.
>
Less contains a hack to force files of size 0 to become non-seekable in order
to workaround a linux kernel bug.
When the file becomes non-seekable any further reads from the file are
appended rather than overwriting the original contents of the file.
diff --git ch.c ch.c
index 1a679767a42
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.05.05 20:03:19 +0200:
> I like rsync -v but hell it is noisy with openrsync.
> Just shut up about all the files that have not changed unless you go -vv.
Before we do this, are there reasons to keep this like it is in the original?
I think i actually
I like rsync -v but hell it is noisy with openrsync.
Just shut up about all the files that have not changed unless you go -vv.
--
:wq Claudio
Index: downloader.c
===
RCS file: /cvs/src/usr.bin/rsync/downloader.c,v
retrieving revisio
On Wed, Mar 24, 2021 at 12:10:20AM +0100, Ulf Brosziewski wrote:
> This means we have two distinct issues here. On the Thinkpad, it's
> coordinates, on the Pinebook, it's the timing - as your logs have shown,
> there are either overlong delays between some reports, or the clock is
> irregular. So
On 3/23/21 10:39 PM, Klemens Nanni wrote:
> On Tue, Mar 23, 2021 at 09:29:09PM +0100, Ulf Brosziewski wrote:
>> In order to distinguish tap gestures from short movements, the touchpad
>> input driver in wsmouse checks whether the distance between the initial
>> and the last position of a touch exce
On Tue, Mar 23, 2021 at 09:29:09PM +0100, Ulf Brosziewski wrote:
> In order to distinguish tap gestures from short movements, the touchpad
> input driver in wsmouse checks whether the distance between the initial
> and the last position of a touch exceeds the 'maxdist' limit. Some
> touchpads prov
In order to distinguish tap gestures from short movements, the touchpad
input driver in wsmouse checks whether the distance between the initial
and the last position of a touch exceeds the 'maxdist' limit. Some
touchpads provide unreliable coordinates when more than one contact is
being made simul
Hi,
i noticed that the mouse movement on my powermac can be pretty jittery at times.
One of the reasons I have identified is our use of a position change threshold.
The driver ignores all finger position changes below a certain threshold.
If the finger position change is > threshold it is used to
Hi,
ropers wrote on Mon, Jul 20, 2020 at 05:54:46AM +0100:
> Ah, I see where you're coming from, Ingo. You've dropped the idea of
> testing for less(1) in non-portable mandoc because we know less(1) is
> in base.[1]
Configuration testing is never needed in a base system
Ah, I see where you're coming from, Ingo. You've dropped the idea of
testing for less(1) in non-portable mandoc because we know less(1) is
in base.[1]
That makes a lot of sense.
Like you said, the idea of testing for less might be worth revisiting
in mandoc-portable. Admittedly, t
Hi Jason & Theo,
thanks for the feedback!
Jason McIntyre wrote on Sun, Jul 19, 2020 at 05:02:02PM +0100:
> i guess the argument in favour of more(1) would be that it is part of
> posix, even if optional, where less(1) is not. so it makes sense to
> choose a command most likely to
> about -s: it's inclusion probably comes from a time when there was an
> annoying bug in nroff that made our man pages randomly display a number
> of blank lines in the middle of a page. -s mitigated that somewhat.
that is also what I recall.
ity documented in the system documentation."
>
> Right now, i even failed to find any indication that POSIX ever
> required more(1) as the default for this purpose. I no longer
> understand where i got that idea from in the first place.
>
> That said, on OpenBSD, the pager w
Good.
The user-interface of less is slightly more refined, and definately
preferred.
Ingo Schwarze wrote:
> Hi,
>
> currently, if neither the MANPAGER nor the PAGER environment variable
> is set, man(1) uses "more -s" as the manual page pager. I am quite
> sure t
e default for this purpose. I no longer
understand where i got that idea from in the first place.
That said, on OpenBSD, the pager we provide is less(1). In effect,
it is less(1) even when called as more(1), albeit with minor
differences in the default behaviour. On top of that, our man(1)
ut
comes after. LAM before ALEF has to become the ligature glyph "al",
> whereas ALEF before LAM remains two glyphs. Technically, the
> question of ordering in space, whether glyphs are painted onto the
> screen right to left or left to right, only comes into play after
> cha
Hi,
The command line handling code in less/cmdbuf.c is very complicated.
>From the top level function cmd_char(), the stack can go down nine levels
before finally reaching the bottom level function cmd_step_common().
One of the functions traversed during that descent is the recursive
funct
lly, the
question of ordering in space, whether glyphs are painted onto the
screen right to left or left to right, only comes into play after
characters have already been combined into glyphs.
Actually, now that you bring up the topic, i see another situation
where less(1) causes an issue. Let
Hi Ingo,
Persian is my native language and I think that the major problem that
all RTL (Right-To-Left) languages like Persian and Arabic currentlly suffer
from is the lack of BiDi (Bidirectionality) support in console and terminal
environment like xterm(1). KDE konsole(1) support bidi and that's wh
Ingo Schwarze wrote:
> I have no idea how many of those work in konsole(1) - but i'm sure
> none of those, except the four LAM WITH ALEF discussed here, work
> with less(1), so i think support for LAM WITH ALEF provided no value
> in the first place. The way it is implemente
Hi,
i have to admit that i am neither able to speak nor to write nor
to understand the Arabic language nor the Arabic script, but here
is my current, probably incomplete understanding of what our less(1)
program is trying to do with Arabic ligatures.
If somebody is reading this who is able to
Hi,
the file less/line.c currently contains three copies of code to
step one multibyte character to the left in a char * buffer, and
cleaning up the file less/cmdbuf.c will require similar functionality
in the future. So let's introduce a new function for that purpose.
Keep it as simil
On Sun, Aug 11, 2019 at 02:18:08PM -0700, Evan Silberman wrote:
> - less(1) should explain what it does before it talks about more(1)
> - reference the COMMANDS section directly when mentioning commands
> - add HISTORY to less.1
> - credit Garret D'Amore in AUTHORS since he is a
completion, here's the diff i'm proposing, which is
evan's diff plus feedback from ingo. feel free to ok it too!
jmc
Index: less.1
===
RCS file: /cvs/src/usr.bin/less/less.1,v
retrieving revision 1.55
diff -u -r1.55 le
The more(1) manual implies that more will accept and handle all the
options less(1) takes, but this is not the case.
--- usr.bin/less/more.1
+++ usr.bin/less/more.1
@@ -65,17 +65,6 @@ It then waits for input from the user.
Scrolling forward switches to the next file,
or exits if there is none
On Mon, Aug 19, 2019 at 11:57:23AM -0700, Evan Silberman wrote:
> bump
>
i'm taking care of it. please be patient...
jmc
> Evan Silberman wrote:
> > - less(1) should explain what it does before it talks about more(1)
> > - reference the COMMANDS section directl
"Theo de Raadt" wrote:
> And let me comment in general. When diffs contain multiple aspects
> like this, the people can commit sometimes raise their nose at a piece
> and ignore the whole thing. That chunk raises my nose, and I forget
> what else is in your diff.
Good advice. When I get a chanc
I don't think that piece of history matters enough. Garret's
changes were not even close to the original work, or even other
unmentioned work.
And let me comment in general. When diffs contain multiple aspects like
this, the people can commit sometimes raise their nose at a piece and
ignore the
bump
Evan Silberman wrote:
> - less(1) should explain what it does before it talks about more(1)
> - reference the COMMANDS section directly when mentioning commands
> - add HISTORY to less.1
> - credit Garret D'Amore in AUTHORS since he is also attributed in the
> source
- less(1) should explain what it does before it talks about more(1)
- reference the COMMANDS section directly when mentioning commands
- add HISTORY to less.1
- credit Garret D'Amore in AUTHORS since he is also attributed in the
source code as a copyright holder
- it is false that more(1) c
No kidding.
Claudio Jeker wrote:
> When running rsync against rsync://rpki.ripe.net/repository it will
> print the following all the time:
> The RIPE NCC Certification Repository is subject to Terms and Conditions
> See http://www.ripe.net/lir-services/ncc/legal/certification/repository-tc
>
When running rsync against rsync://rpki.ripe.net/repository it will
print the following all the time:
The RIPE NCC Certification Repository is subject to Terms and Conditions
See http://www.ripe.net/lir-services/ncc/legal/certification/repository-tc
This is not helpful. I changed the log message t
Hi Ingo,
Yes the usage of "truncate" and "chop" are unfortunate. I agree positive
language is always better.
Many thanks,
George
Hi George,
George Brown wrote on Sat, Jul 20, 2019 at 01:29:37PM +0100:
> When viewing a file with "less -S" that has lines longer than $COLUMNS
> said lines are simply not wrapped. The contents of said lines is still
> available, one simply needs to scroll horizontally. I wo
When viewing a file with "less -S" that has lines longer than $COLUMNS
said lines are simply not wrapped. The contents of said lines is still
available, one simply needs to scroll horizontally. I would have
expected the contents displayed within less to be as if I had run
something like
it can be radically simplified, deleting two LWCHAR variables,
one call to step_char(), is_composing_char(), is_combining_char(),
and is_wide_char() each.
OK?
Ingo
Index: cmdbuf.c
===
RCS file: /cvs/src/usr.bin/less/cmdbuf.c,v
retrievin
Ted Unangst(t...@tedunangst.com) on 2019.05.08 23:39:30 -0400:
> there are lists of annointed usernames in battlestar. this creates an unfair
> playing field! worse, there is a list of "bad" people! and i'm almost one of
> them!
ok, but i think you need krw@ to ok it too.
> -static const char *co
there are lists of annointed usernames in battlestar. this creates an unfair
playing field! worse, there is a list of "bad" people! and i'm almost one of
them!
-static const char *const badguys[] = {
- "wnj",
- "root",
- "ted",
- 0
-};
Index: com1.c
==
behaviour.
OK?
Ingo
Index: charset.c
===
RCS file: /cvs/src/usr.bin/less/charset.c,v
retrieving revision 1.22
diff -u -p -r1.22 charset.c
--- charset.c 7 May 2019 14:26:38 - 1.22
+++ charset.c 8 May 2019 14:03:01 -
@@
On Tue, 07 May 2019 23:32:20 +0200, Ingo Schwarze wrote:
> Here is basic cleanup of the last major function in line.c, pshift().
> Several minor issues still remain in the file, but those are for later.
>
> This gets rid of two LWCHAR variables, one call to utf_len(),
> get_wchar(), is_composing_c
the comment above pshift() is simply wrong.
The function does not discard a specific number of characters.
Tested by running
LC_CTYPE=en_US.UTF-8 less -# 1
LC_CTYPE=en_US.UTF-8 less -# 1 -R
LC_CTYPE=C less -# 1
on my set of test files containing a wide variety of combinations
of valid
Hi Stefan,
Stefan Sperling wrote on Thu, Mar 14, 2019 at 04:11:00PM +0100:
> Yes, OK.
Thanks for checking.
Here is the next step outside line.c, completely cleaning up the file
less/filename.c with respect to UTF-8 handling. The loop needed is very
similar to the one in search.c except t
On Thu, Mar 14, 2019 at 04:04:20PM +0100, Ingo Schwarze wrote:
> Hi,
>
> the following is a very simple patch to completely clean up the
> file less/search.c with respect to UTF-8 handling. It also fixes
> an outright bug: Searching for uppercase UTF-8 characters currently
> do
Hi,
the following is a very simple patch to completely clean up the
file less/search.c with respect to UTF-8 handling. It also fixes
an outright bug: Searching for uppercase UTF-8 characters currently
doesn't work because passing a Unicode codepoint (in this case, the
"ch"
r output bytes still fit on the
current screen output line.
* All tests were also performed with LC_CTYPE=C.
OK?
Ingo
Index: line.c
===
RCS file: /cvs/src/usr.bin/less/line.c,v
retrieving revision 1.28
diff -u -p -r1.28 line.c
--
1 - 100 of 364 matches
Mail list logo
