Re: (b)make: Outputting a huge variable value
On Fri, 17 May 2024, Edgar Fuß wrote:
What happens here is that the child "make -V" reads the complete Makefile
again, and after that, it prints the variable value.
Oh, then it's propably useless in the pkgsrc context the question came up.
There's a trick to do this, but for it to work, compat mode must be
turned off. I'm using `-j' for this.
$ cat Makefile
X != cat /usr/src/sys/kern/*.c
.PHONY: main
main:
@wc -c <<\EoF${.newline}$X${.newline}EoF${.newline}
$ make -j1
4936770
$
The description for `-j' says:
When compatibility mode is off, all commands associated with a
target are executed in a single shell invocation as opposed to
the traditional one shell invocation per line.
So, in non-compat mode, make runs the shell with `-s' instead of `-c' and
therefore, here-docs will work.
-RVP
Re: (b)make: Outputting a huge variable value
On Thu, 16 May 2024, Edgar Fuß wrote: Does "make -V '$VARIABLE'" (or without the $, depending on exactly what you want) not work? I must be missing something. The point is to do this in a makefile, not as an isolated invocation of make. As Mouse said: $ cat Makefile X != cat /usr/src/sys/kern/*.c main: .PHONY make -V X | wc -c $ make 4938515 $ -RVP
Re: -mdoc: how to handle surrounding types?
On Thu, 8 Feb 2024, Mouse wrote: I'm writing a manpage for a library and want to describe a function which returns a pointer to a function. Specifically, it takes a handler of type void (*)(const char *, int) and returns the previous handler. If we call it foo, then: extern void (*foo(void (*)(const char *, int)))(const char *, int); After a bit of fiddling with signal.3: ``` diff -urN a/signal.3 b/signal.3 --- a/signal.3 2024-01-29 23:14:46.0 + +++ b/signal.3 2024-02-09 06:39:14.062233348 + @@ -41,8 +41,9 @@ .In signal.h .\" The following is Quite Ugly, but syntactically correct. Don't try to .\" fix it. +.ds cm \f[R],\f[] .Ft void \*(lp* -.Fn signal "int sig" "void \*(lp*func\*(rp\*(lpint\*(rp\*(rp\*(rp\*(lpint" +.Fn foo "void \*(lp*\*(rp\*(lpconst char *\*(cm int\*(rp\*(rp\*(rp\*(lpconst char *\*(cm int" .Sh DESCRIPTION This .Fn signal ``` (the `cm' string is for nroff only) -RVP
Re: tar vs device special files
On Sat, 28 Oct 2023, Mouse wrote:
I'm having trouble seeing what's responsible, and in particular am
wondering whether this is my bug or /bin/tar's bug or what. (It
doesn't help that I haven't managed to find a clear spec for tar
format; the closest I've found so far is a description of what pax, in
its (supposedly-)tar-compatible mode, is supposed to read/write.)
All of this can be found in:
src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c
If the libarchive tar doesn't see a "ustar \0" (GNU tar) or "ustar"
(POSIX tar) magic at 0x101 (see: tar_read_header()), it take the
file to be a non-POSIX old-style tar archive which (according to
libarchive) doesn't store maj./min. nos. (see: struct
archive_entry_header_ustar)
The 9.1 /bin/tar tarball (hexdump -C) is
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
0100 00 75 73 74 61 72 00 30 30 72 6f 6f 74 00 00 00 |.ustar.00root...|
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0120 00 00 00 00 00 00 00 00 00 6f 70 65 72 61 74 6f |.operato|
0130 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |r...|
0140 00 00 00 00 00 00 00 00 00 30 30 30 30 30 33 20 |.03 |
0150 00 30 30 30 30 30 33 20 00 00 00 00 00 00 00 00 |.03 |
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
whereas mine is
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
0140 00 00 00 00 00 00 00 00 00 30 30 30 30 30 33 20 |.03 |
0150 00 30 30 30 30 30 33 20 00 00 00 00 00 00 00 00 |.03 |
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
Except for the stuff at offsets 0x100-0x131, they look pretty close to
identical to me (the value at 0x94 is the header checksum), and that
stuff is, as far as I can tell, owner name strings (which I'm not
supplying, just using the numeric uid and gid values). But the stock
9.1 tar seems to be taking the 03 major and minor numbers as zero
for reasons I don't understand, since it understands its own,
apparently identical, major and minor numbers just fine.
Any ideas?
Maybe your tar could supply a "ustar" magic char. seq. at 0x101 for libarchive.
(see: header_ustar() vs. header_old_tar())
Or, fix libarchive like this:
```
diff -urN
a/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c
b/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c
---
a/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c
2019-07-24 13:50:23.0 +
+++
b/src/external/bsd/libarchive/dist/libarchive/archive_read_support_format_tar.c
2023-10-28 22:10:28.778721000 +
@@ -1383,6 +1383,14 @@
if (err > err2)
err = err2;
+ /* Parse out device numbers only for char and block specials. */
+ if (header->typeflag[0] == '3' || header->typeflag[0] == '4') {
+ archive_entry_set_rdevmajor(entry, (dev_t)
+ tar_atol(header->rdevmajor, sizeof(header->rdevmajor)));
+ archive_entry_set_rdevminor(entry, (dev_t)
+ tar_atol(header->rdevminor, sizeof(header->rdevminor)));
+ }
+
tar->entry_padding = 0x1ff & (-tar->entry_bytes_remaining);
return (err);
}
```
-RVP
Re: bin/57544: sed(1) and regex(3) problem with encoding
On Wed, 30 Aug 2023, Christos Zoulas wrote: Why don't we make next and end unsigned char so that all instances are fixed? :) My original attempt did just that, but then I had to cast to char in a lot more places to get libc to build. -RVP
Re: bin/57544: sed(1) and regex(3) problem with encoding
On Wed, 26 Jul 2023, tlaro...@polynum.com wrote:
$ export LC_CTYPE=fr_FR.ISO8859-15
and then:
$ echo "??" | sed 's/??\/g'
sed: 1: "s/??\/g": RE error: trailing backslash (\)
Not running NetBSD right now, but, FreeBSD 13.2 has the same issue which
can be seen even with a plain grep(1)--as it relies on the libc regexp
engine.
Can you try the patch below (it is for NetBSD):
```
diff -urN src/lib/libc/regex.orig/regcomp.c src/lib/libc/regex/regcomp.c
--- src/lib/libc/regex.orig/regcomp.c 2022-12-21 17:44:15.0 +
+++ src/lib/libc/regex/regcomp.c2023-07-26 17:05:50.832242252 +
@@ -898,7 +898,7 @@
handled = false;
assert(MORE()); /* caller should have ensured this */
- c = GETNEXT();
+ c = (unsigned char)GETNEXT();
if (c == '\\') {
(void)REQUIRE(MORE(), REG_EESCAPE);
cc = GETNEXT();
```
-RVP
Re: Trivial program size inflation
On Wed, 5 Jul 2023, Emmanuel Dreyfus wrote:
It is documented somewhere? Last time I tried to use it, I
had to make a static build.
If you mean the .spec file syntax, then yes:
https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
As for the patch itself, I'm travelling at present, so I don't have my NetBSD
laptop with the compiler-patch and notes I made last year. So, what I've done
is attach a hacked-up .spec file which allows `-pg' with shared libs. It
should be fairly easy to see to what changes to make back to the compiler
sources to make this permanent.
Since, I've only NetBSD on QEMU right now (and a full toolchain compile is
ruddy slow), I haven't done this, but, `gcc -specs=gcc-pg.spec ...' works as
it does on Linux (a gmon.out is produced with _only_ the functions from the
executable--none from the shared libs--which is how I want it anyway). Only
lightly tested. Tell me if there are any problems (apart from `-pie -fPIE'
which doesn't work with `-static -pg' in any case).
-RVP--- gcc-std.spec2023-07-05 21:45:17.067947887 +
+++ gcc-pg.spec 2023-07-05 21:49:25.062647745 +
@@ -53,7 +53,7 @@
%{!static|static-pie:--eh-frame-hdr} %{m32:-m elf_i386}%{m64:-m
elf_x86_64}%(netbsd_link_spec)
*lib:
-%{pthread: %{!p:
%{!pg:-lpthread}} %{p:-lpthread_p}
%{pg:-lpthread_p}}%{posix: %{!p:
%{!pg:-lposix}} %{p:-lposix_p}
%{pg:-lposix_p}} %{shared: %{!p:
%{!pg:-lc}} %{p:-lc_p}
%{pg:-lc_p}}%{!shared:%{!symbolic:
%{!p: %{!pg:-lc}}
%{p:-lc_p} %{pg:-lc_p}}}
+%{pthread: %{!p:
%{!pg:-lpthread}} %{p:-lpthread_p}%{pg:-lpthread}}
%{posix: %{!p:
%{!pg:-lposix}} %{p:-lposix_p} %{pg:-lposix}}
%{shared: %{!p:
%{!pg:-lc}} %{p:-lc_p}%{pg:-lc}}
%{!shared:%{!symbolic:
%{!p: %{!pg:-lc}} %{p:-lc_p}
%{pg:-lc}}}
*link_gomp:
Re: Trivial program size inflation
On Tue, 4 Jul 2023, Mouse wrote: I've failed to find where the second -lgcc -lgcc_eh is specified, though (I thought there may be explanatory comments); I searched /usr/src for -lgcc_eh and found only three hits, none of which appear to specify the duplication. I may take a closer look sometime. GCC used to rely on external .spec files a long time back, but, now they're built-in (which you can override with with `-spec=' after dumping with `-dumpspecs') using header files. For NetBSD/x86 ELF: /usr/src/external/gpl3/gcc/dist/gcc/config/netbsd-elf.h /usr/src/external/gpl3/gcc/dist/gcc/config/netbsd.h /usr/src/external/gpl3/gcc/dist/gcc/config/i386/netbsd-elf.h /usr/src/external/gpl3/gcc/dist/gcc/config/i386/netbsd64.h (I had to fiddle with them to get `-pg' working with shared libs...) -RVP
Re: Trivial program size inflation
On Tue, 4 Jul 2023, RVP wrote: I think lld(1) does things differently. I'll check this later... And I was right! On Linux (what I have at hand now): ``` $ clang -fuse-ld=lld -Wl,-Map=map.txt -static -s -o foo foo.c -L. -lmm $ fgrep -A3 ./libmm.a map.txt [...] -- 224c30 224c30 13 1 ./libmm.a(calloc.o):(.text) 224c30 224c30 13 1 calloc 224c50 224c50 ac316 /lib/x86_64-linux-gnu/libc.a(libc-start.o):(.text) 224c50 224c50 398 1 get_common_indices.constprop.1 -- 225f71 225f71 2d 1 ./libmm.a(malloc.o):(.text) 225f71 225f71f 1 malloc 225f80 225f80 13 1 realloc 225f93 225f93b 1 free -- [...] ``` This is what I had expected from GNU ld(1) also... -RVP
Re: Trivial program size inflation
On Tue, 4 Jul 2023, Joerg Sonnenberger wrote: On Tue, Jul 04, 2023 at 08:38:22AM +, RVP wrote: b) the alloc functions in libc.a not being marked as being "weak". This doesn't really matter at all, in fact, it is likely going to make the situation *worse*. You're right. And, kre@ pointed out the same thing offline just now. Can't say I understand why ld(1) behaves this way, though. (I'm pretty sure I ran ranlib too.) It should've noticed _all_ the functions in the supplied archive, right? I think lld(1) does things differently. I'll check this later... Thanks, -RVP
Re: Trivial program size inflation
On Tue, 4 Jul 2023, RVP wrote: So, we should: a) collapse the newly added functions back into a single file. Ah, looks like this patch will need a free_aligned_sized() to free the aligned memory. Regular free(), realloc() won't work here (as-is). -RVP
Re: Trivial program size inflation
5d50 T free 55f0 T malloc 7470 W posix_memalign 5fd0 T realloc $ ``` HTH, -RVP
Re: Trivial program size inflation
On Mon, 3 Jul 2023, RVP wrote: Somebody should maybe add calloc() to bsdmalloc. And posix_memalign() (any others?) too, else you end up with 2 different arenas and free()/realloc() operating on the wrong one. -RVP
Re: Trivial program size inflation
On Mon, 3 Jul 2023, Mouse wrote: Looking at the resulting null.map, I see, among many other lines, /usr/lib/libc.a(jemalloc.o) /usr/lib/libc.a(tls.o) (calloc) which makes sense: if nothing in null.o, crt0.o, crti.o, or crtbeginT.o refers to anything in the libgnumalloc file containing calloc, nothing will have brought it in from libgnumalloc. Then, when libc refers to it internally, -lgnumalloc is past and thus unavailable for resolving it, so it comes from the default malloc in libc. So I tried, instead, % ld -Map=null.map -dc -dp -e _start -static -o null /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbeginT.o null.o --whole-archive -lgnumalloc --no-whole-archive -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o to force all of libgnumalloc to be brought in. Sure enough, this time, "je" does not appear in the link map, and the executable is significantly smaller. Yes, except this doesn't work (as expected) with bsdmalloc because it doesn't implement calloc(), so the linker will get that (and all the je_* stuff now) from libc.a again. :) Somebody should maybe add calloc() to bsdmalloc. -RVP
Re: Trivial program size inflation
On Sun, 2 Jul 2023, Emmanuel Dreyfus wrote: On Sat, Jul 01, 2023 at 02:25:03PM +, RVP wrote: Not to forget the code for C++ support. And, of course even static binaries may call dlopen() and friends. So that dl*() and the ELF bits right there. At least in 9.3, dlopen() in a static binary does not work. Try using a NSS module from a statically lunked binary to check that. Ah, that's right: dl*() + static binary doesn't work on -HEAD either (unlike in Glibc where this _does_ work). I should've remembered since I looked into this for pin@ some time back. iconv*(), unsurprisingly, errors out too and those __dl*() in static binaries are just stubs put there to return an error instead of just crashing if the binary tries to do a dlopen(). Thanks! -RVP
Re: Trivial program size inflation
On Sat, 1 Jul 2023, Mouse wrote: But that support shouldn't be brought in if the program doesn't use i18n, NSS, or whatever. As in, sure, let's say i18n_something.o refers to dlopen. But if i18n_something.o itself is not brought in, its reference to dlopen won't be brought in either. Even in the default C/POSIX locale that all programs start in, libc loads the appropriate shared lib from /usr/lib/i18n/ in order to handle standard things like LC_CTYPE, LC_NUMERIC, etc. -RVP
Re: Trivial program size inflation
On Sat, 1 Jul 2023, Mouse wrote: dlopen, that doesn't make sense to me. For a statically linked program, the linker can tell whether it calls dlopen et al. Oh, I didn't mean the program needing to call dlopen() directly. libc itself may load shared objects to support things like i18n and NSS on an as-needed basis. -RVP
Re: Trivial program size inflation
On Fri, 30 Jun 2023, Mouse wrote:
Based on something at work, I was looking at executable sizes. I
eventually tried a program stripped about as far down as I could:
int main(void);
int main(void)
{
return(0);
}
and built it -static. size on the resulting binary:
[...]
amd64, 9.0_STABLE (ftp.n.o):
textdata bss dec hex filename
562318 29064 2176416 2767798 2a3bb6 main
12K to do nothing is bad enough (I'm going to be looking at why it's
that big). 149K is even more disturbing (I'll be looking at that too).
But over half a meg of text and two megs of BSS? To do nothing?
Surely something is wrong somewhere.
You need to look at the CRT stuff in /usr/src/lib/csu/ to figure this
out. A lot of initialization and set-up has to be done to get to the
point of calling main(): Calling the libc init routine--which pulls in
malloc, which brings in pthreads (stub or real code). Now you have all
the stuff needed to bring in malloc and stdio coming in: system calls
for those (write, mmap), and the functions these all rely on: strlen(),
strcmp(), ...
Not to forget the code for C++ support. And, of course even static
binaries may call dlopen() and friends. So that dl*() and the ELF bits
right there.
If you want to slim your static binary down, use a different libc first :)
-RVP
Re: old style tail(1) options and bin/57483
On Fri, 30 Jun 2023, Valery Ushakov wrote: The man page seems to be completely silent about the old style options. What exactly are we aiming for here? Do we want to support postfix options in something like old style +qF ? It would be nice to retain `[+-]N' as a shortcut for `-n [+-]N'. You can ditch every other compat as far as I'm concerned. You can even remove obsolete() entirely and I wouldn't shed any tears. -RVP
Re: printf(1), sh(1), POSIX.2 and octal escape sequences
On Wed, 28 Jun 2023, Martin Husemann wrote: If you want to write a two digit octal number you can not continue with another ocatal digit. In C you could do "...\77" "7" and have it concat the literals. In config files (without concatenation) you need some other trick. Couple of ways to do that: ``` $ printf '\0777' | hexdump -C 3f 37 |?7| 0002 $ printf '\77\067' 3f 37 |?7| 0002 $ ``` -RVP
Re: printf(1), sh(1), POSIX.2 and octal escape sequences
On Wed, 28 Jun 2023, tlaro...@polynum.com wrote: But you can't: from the syntax given, \777 is a perfectly valid \77 octal sequence followed by the character '7'. That would be a very surprising way to resolve the ambiguity which is present here. There are others when it comes to octal notation: Single-digit octal escapes can be confused with regexp back-references, so POSIX says octal escapes must have at least 2 digits in certain situations. As for resolving \777 as \777 and not \77'7 is this note in the EXTENDED DESCRIPTION for tr(1) (I knew I had read this somewhere in my travels through POSIX-land): \octal Octal sequences can be used to represent characters with specific coded values. An octal sequence shall consist of a followed by the _longest_ sequence of one, two, or three-octal-digit characters (01234567). (my emphasis) What's good for the goose is also good for the gander, I say. Cheers! -RVP
Re: printf(1), sh(1), POSIX.2 and octal escape sequences
On Wed, 28 Jun 2023, tlaro...@polynum.com wrote: But isn't it incorrect? POSIX 2018 says: '"\ddd", where ddd is a one, two, or three-digit octal number, shall be written as a byte with the numeric value specified by the octal number.' since 477 -> 777 are not byte values, shouldn't \777 be interpreted as '\77' octal then the digit 7; \677 -> \67 octal then 7 etc. ? Better to do what the C compiler does: try converting up to 3 digits, and if the result of the conversion is > 255, complain. -RVP
Re: unresolvable R_X86_64_NONE relocation against symbol `__sF'
On Thu, 18 May 2023, Edgar Fuß wrote: attached (gzip-ed and .work.log renamed). There are multiple invalid relocations types in those object files. For instance: ``` $ readelf -r common.o.bad | head Relocation section '.rela.text' at offset 0x3c20 contains 261 entries: Offset Info Type Sym. ValueSym. Name + Addend 001e 002f R_X86_64_NONE fetchLastErrCode - 4 002b 000a0002 R_X86_64_PC32 .LC0 - 4 0037 0030 R_X86_64_NONE fetchLastErrString - 4 0047 00330004 R_X86_64_PLT32 __errno - 4 0059 00060002 R_X86_64_PC32 .rodata - 4 0069 002f R_X86_64_NONE fetchLastErrCode - 4 0074 00330004 R_X86_64_PLT32 __errno - 4 $ ``` compared to one produced using gcc-10.4.0 + binutils-2.26.1 (in the /tmp/B/bin dir. which I got from here: http://archive.netbsd.org/pub/pkgsrc-archive/packages/NetBSD/amd64/8.0_2019Q3/All): ``` $ PATH=/tmp/B/bin:$PATH gcc -fcommon -Wl,-zrelro -O2 -fPIC -std=gnu99 \ -fstack-protector -Wall -DDEF_UMASK=0022 -D_LARGEFILE_SOURCE -D_LARGE_FILES \ -D_FILE_OFFSET_BITS=64 -DINET6 -DWITH_SSL -DFTP_COMBINE_CWDS -DNETBSD \ -c /usr/src/external/bsd/fetch/dist/libfetch/common.c -o common.o.good $ readelf -r common.o.good | head Relocation section '.rela.text' at offset 0x3600 contains 258 entries: Offset Info Type Sym. ValueSym. Name + Addend 0017 002b002a R_X86_64_REX_GOTP fetchLastErrCode - 4 0024 000f0002 R_X86_64_PC32 .LC0 - 4 0030 002c002a R_X86_64_REX_GOTP fetchLastErrString - 4 0040 002f0004 R_X86_64_PLT32 __errno - 4 004e 00060002 R_X86_64_PC32 .rodata - 4 005e 002b002a R_X86_64_REX_GOTP fetchLastErrCode - 4 0069 002f0004 R_X86_64_PLT32 __errno - 4 $ ``` `R_X86_64_REX_GOTP' is the correct relocation type for `-fPIC' as can be seen from the assembly: ``` $ PATH=/tmp/B/bin:$PATH gcc -fcommon -Wl,-zrelro -O2 -fPIC -std=gnu99 \ -fstack-protector -Wall -DDEF_UMASK=0022 -D_LARGEFILE_SOURCE -D_LARGE_FILES \ -D_FILE_OFFSET_BITS=64 -DINET6 -DWITH_SSL -DFTP_COMBINE_CWDS -DNETBSD \ -S /usr/src/external/bsd/fetch/dist/libfetch/common.c -o common.S $ sed -n '21,31p' common.S .L3: movl4(%rdi), %edx movqfetchLastErrCode@GOTPCREL(%rip), %rax movl%edx, (%rax) movq8(%rdi), %rcx leaq.LC0(%rip), %rdx movl$256, %esi movqfetchLastErrString@GOTPCREL(%rip), %rdi xorl%eax, %eax jmp snprintf@PLT .cfi_endproc $ ``` The assembler will turn GOTPCREL output by the compiler into R_X86_64_REX_GOTP (both for `-fPIC'). Can you post the assembly and object file produced by whatever compiler this points to: /var/work/pkgsrc/pkgtools/pkg_install/work/.gcc/bin/gcc You can use the command-lines I've given above to produce them. They should be functionally the same as the ones in your log file. -RVP
Re: unresolvable R_X86_64_NONE relocation against symbol `__sF'
On Wed, 17 May 2023, Edgar Fuß wrote: And another weird problem: Using a lang/gcc8 compiler patched to use gas and gld from devel/binutils 2.26.1 (see other thread), when building pkgtools/pkg_install, I get /usr/pkg/bin/gld: /var/work/pkgsrc/pkgtools/pkg_install/work/libfetch/libfetch.a(common.o)(.text+0x1e5): unresolvable R_X86_64_NONE relocation against symbol `__sF' /usr/pkg/bin/gld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status *** [pkg_add] Error code 1 What the hell does that mean? This looks like a binutils issue. You should never see a relocation type of `R_X86_64_NONE' assigned to `__sF' (the internal libc variable holding the first 3 `FILE' objects-stdin, stdout, stderr). Can you post the build log for this and the /var/work/pkgsrc/pkgtools/pkg_install/work/libfetch/libfetch.a file itself? -RVP
Re: Proposed chown(8)/chgrp(1) enhancement
On Fri, 28 Apr 2023, Paul Goyette wrote: I propose the attached enhancement to chown/chgrp to avoid setting a new user/group value if the desired values are already set. The change is pretty simple. I don't think we need a flag for this. I think what you're proposing should just be the default behaviour. -RVP
Re: jemalloc profiling
On Thu, 27 Apr 2023, tlaro...@polynum.com wrote: I was trying to use the profiling capabilities of jemalloc and found that there is a /usr/lib/libjemalloc_p.a that seems (from /usr/src/distrib/sets/lists/comp/mi) to be the profiling version. The *_p.a files are used for call-profiling. What you want is jemalloc's allocation profiling which is a different beast entirely. For this you'll have to re-compile jemalloc with `JEMALLOC_PROF' defined either in the Makefile: src/external/bsd/jemalloc/lib/Makefile.inc or, in the defs file: src/external/bsd/jemalloc/include/jemalloc/internal/jemalloc_internal_defs.h -RVP
Re: flock(2): locking against itself?
On Tue, 18 Apr 2023, Mouse wrote: While writing this mail, it occurs to me that a mode wherein everything operates same as now, except that output, instead of being pushed to the tty with fwrite() or write() or writev() or whatever, is just passed to a callback. That would address my use cases with a much less intrusive change. Try libtickit--that uses callbacks (I think): https://www.leonerd.org.uk/code/libtickit/ -RVP
Re: flock(2): locking against itself?
On Sun, 16 Apr 2023, Mouse wrote:
In particular, I wrote
[...]. I have a program that uses curses for output but wants to do
non-blocking input. So I set stdin nonblocking and threw fd 0 into
the poll() loop.
But, in normal use, stdin and stdout come from the same open on the
session's tty, so setting stdin nonblocking also sets stdout
nonblocking, which curses is not prepared to handle, leading to large
screen updates getting partially lost.
I think O_NONBLOCK on an input FD would be a problem too for curses.
Otherwise, if only a non-blocking output were the problem, then you
could just re-open the current tty twice and juggle the FDs like this:
```
#include
#include
#include
#include
int
main(void)
{
char* tty;
int fd1, fd2, flg;
if ((tty = ttyname(STDIN_FILENO)) == NULL)
err(1, "ttyname failed");
if ((fd1 = open(tty, O_RDWR)) == -1)
err(1, "open for FD 0 failed");
if ((fd2 = open(tty, O_RDWR)) == -1)
err(1, "open for FDs 1 & 2 failed");
if (dup2(fd1, 0) == -1)
err(1, "dup 0 failed");
if (dup2(fd2, 1) == -1)
err(1, "dup 1 failed");
if (dup2(fd2, 2) == -1)
err(1, "dup 2 failed");
if (close(fd1) == -1)
err(1, "close fd1 failed");
if (close(fd2) == -1)
err(1, "close fd2 failed");
if ((flg = fcntl(STDIN_FILENO, F_GETFL, 0)) == -1)
err(1, "fcntl F_GETFL failed");
if (fcntl(STDIN_FILENO, F_SETFL, flg | O_NONBLOCK) == -1)
err(1, "fcntl F_SETFL failed");
execl("/usr/bin/vi", "vi", NULL);
err(1, "exec /usr/bin/vi failed");
}
```
But, vi, at least, fails to run like this. So, I think using a pty is
the simplest, not to say standard, solution here...
-RVP
Re: setreuid(2)?
On Wed, 9 Nov 2022, Robert Elz wrote: Yes, there's no question that setreuid() works.Mouse's issue was that setreuid(2) (the man page) says "new code should not use this", yet for what he wanted to achieve (nothing like your code example), the supposed replacement method (relying upon saved user ids) doesn't do anything useful at all. On Wed, 9 Nov 2022, Mouse wrote: Probably. What does that have to do with what I was after? In my case, the process forks but does not exec; there is only one executable involved. Yes, of course, Mouse would need setreuid() for what he wants to do. I was addressing the "new code should not use this" case. Even POSIX acknowledges that setreuid() is the only way right now for unprivileged users to set the euid and saved uid = uid. I've never needed to set setreuid() before, so I went looking in the NetBSD source for usages, and found only about half-a-dozen instances, and most of them "safe": either not exec()ing binaries or only relying on setreuid() if _POSIX_SAVED_IDS is not available. But, of course, you guys would already know all this... -RVP
Re: setreuid(2)?
On Mon, 7 Nov 2022, Mouse wrote:
used in new code". But I must be missing something, because I can't
see any way to exploit the functionality described there, including the
saved IDs, to get the effect I want...short of creating an executable
I don't use seteuid(), but, it looks like you can just re-swap the
(uid, euid) in a child binary and regain the parent's privileges.
Compile with and without -DRELINQUISH.
```
cc -o /tmp/x x.c
cc -o /tmp/y y.c
sudo sh -c 'chown root:wheel /tmp/x; chmod 4555 /tmp/x'
/tmp/x
```
---START x.c---
#include
#include
#include
int
main(int argc, char* argv[])
{
uid_t uid, euid;
uid = getuid();
euid = geteuid();
if (uid == euid)
errx(1, "UID == EUID--won't proceed.");
printf("%s: UID=%d, EUID=%d\n", *argv, uid, euid);
if (setreuid(euid, uid) != 0)
err(1, "setreuid(%d, %d) failed", euid, uid);
printf("%s: UID=%d, EUID=%d\n", *argv, getuid(), geteuid());
#ifdef RELINQUISH
/*
* Need to do this to safely execute any binary,
*/
#if defined(__FreeBSD__) || defined(__OpenBSD__)
/*
* This works only on FreeBSD (13.1-RELEASE-p3) and
* OpenBSD (6.9).
*/
if (setuid(uid) != 0)
err(1, "setuid(%d) failed", uid);
#else
/*
* On NetBSD (9.99.106), setuid() fails.
* On Linux (5.0.0-38), the call succeeds, but has no effect.
* So, we use setreuid().
*/
if (setreuid(uid, uid) != 0)
err(1, "setreuid(%d, %d) failed", uid, uid);
#endif
#endif
execl("/tmp/y", "y", NULL);
err(1, "execl(/tmp/y) failed");
}
---END x.c---
---START y.c---
#include
#include
#include
int
main(int argc, char* argv[])
{
uid_t uid, euid;
uid = getuid();
euid = geteuid();
printf("%s: UID=%d, EUID=%d\n", *argv, uid, euid);
fflush(stdout);
if (setreuid(uid, uid) != 0)
err(1, "setreuid(%d, %d) failed", uid, uid);
printf("%s: UID=%d, EUID=%d\n", *argv, getuid(), geteuid());
return 0;
}
---END y.c---
-RVP
Re: unhide reallocarray
On Fri, 28 Oct 2022, Thomas Klausner wrote:
I cleaned up the _OPENBSD_SOURCE defines for X, but we can probably
remove some more in other parts of the tree, I plan to do that but
feel free to beat me to it.
I have:
```
$ egrep -r -- '-D_OPENBSD_SOURCE|#define[[:blank:]]+_OPENBSD_SOURCE' /usr/src/
/usr/src/external/gpl3/gdb/dist/gnulib/configure: $as_echo "#define _OPENBSD_SOURCE
1" >>confdefs.h
/usr/src/external/bsd/dhcpcd/sbin/dhcpcd/Makefile:CPPFLAGS+=
-DHAVE_CONFIG_H -D_OPENBSD_SOURCE
/usr/src/external/bsd/file/dist/configure: printf "%s\n" "#define _OPENBSD_SOURCE 1"
>>confdefs.h
/usr/src/external/bsd/file/dist/configure~: printf "%s\n" "#define _OPENBSD_SOURCE
1" >>confdefs.h
/usr/src/external/bsd/libpcap/sbin/rpcapd/Makefile:CPPFLAGS+=
-DHAVE_CONFIG_H -D_OPENBSD_SOURCE
/usr/src/external/bsd/mdocml/Makefile.inc:#CPPFLAGS+= -D_OPENBSD_SOURCE
/usr/src/external/bsd/mdocml/dist/configure:[ "X$3" =
"X-D_OPENBSD_SOURCE" ] && NEED_OPENBSD_SOURCE=1
/usr/src/external/bsd/mdocml/dist/configure: runtest reallocarray
REALLOCARRAY-D_OPENBSD_SOURCE || true
/usr/src/external/bsd/mdocml/dist/configure: runtest recallocarray
RECALLOCARRAY -D_OPENBSD_SOURCE || true
/usr/src/external/bsd/mdocml/dist/configure: runtest strtonum STRTONUM
-D_OPENBSD_SOURCE || true
/usr/src/external/bsd/mdocml/dist/configure:[ ${NEED_OPENBSD_SOURCE} -eq 0 ] || echo
"#define _OPENBSD_SOURCE"
/usr/src/external/bsd/mdocml/include/config.h:#define _OPENBSD_SOURCE
/usr/src/external/bsd/nsd/Makefile.inc:CPPFLAGS+=-D_OPENBSD_SOURCE
-D_NETBSD_SOURCE
/usr/src/external/bsd/nsd/dist/configure:#define _OPENBSD_SOURCE 1
/usr/src/external/bsd/nsd/dist/configure.ac:#define _OPENBSD_SOURCE 1
/usr/src/external/bsd/tmux/dist/Makefile.am:AM_CPPFLAGS += -D_OPENBSD_SOURCE
/usr/src/external/bsd/tmux/dist/Makefile.in:@IS_NETBSD_TRUE@am__append_9 =
-D_OPENBSD_SOURCE
/usr/src/external/bsd/tmux/usr.bin/tmux/Makefile:-D_OPENBSD_SOURCE \
/usr/src/external/bsd/unbound/Makefile.inc:CPPFLAGS += -D_OPENBSD_SOURCE
/usr/src/external/bsd/unbound/dist/config.h.in:#define _OPENBSD_SOURCE 1
/usr/src/external/bsd/unbound/dist/configure:#define _OPENBSD_SOURCE 1
/usr/src/external/bsd/unbound/dist/configure.ac:#define _OPENBSD_SOURCE 1
/usr/src/external/bsd/unbound/dist/configure.ac:#define _OPENBSD_SOURCE 1
/usr/src/external/bsd/unbound/include/config.h:#define _OPENBSD_SOURCE 1
/usr/src/external/mit/xorg/server/drivers/Makefile.xf86-driver:CPPFLAGS+=
-D_OPENBSD_SOURCE
/usr/src/crypto/external/bsd/openssh/Makefile.inc:CPPFLAGS+=-D_OPENBSD_SOURCE
/usr/src/lib/libc/regex/regcomp.c:#define _OPENBSD_SOURCE
/usr/src/lib/libc/stdlib/reallocarray.c:#define _OPENBSD_SOURCE
/usr/src/lib/libc/stdlib/strtonum.3:.Vt #define _OPENBSD_SOURCE
/usr/src/lib/libc/stdlib/strtonum.c:#define _OPENBSD_SOURCE
/usr/src/sbin/bioctl/Makefile:CPPFLAGS+=-D_OPENBSD_SOURCE
/usr/src/tools/mandoc/Makefile:HOST_CPPFLAGS+= -D_OPENBSD_SOURCE
/usr/src/usr.bin/sdiff/Makefile:CPPFLAGS+=-D_OPENBSD_SOURCE
/usr/src/usr.sbin/gpioctl/Makefile:CPPFLAGS+=-D_OPENBSD_SOURCE
/usr/src/usr.sbin/pf/Makefile.inc:CPPFLAGS+= -D_OPENBSD_SOURCE
$
```
-RVP
Re: grep -r: add default "."
On Sun, 4 Sep 2022, Alistair Crooks wrote: agcre was not really meant to be a drop-in replacement for grep: - defaults to extended regexps - does most (sane/useful) perl extensions - does utf-8 searching and matching - is built around a vm style of matching, rather than a dfa, or aho corasick-style optimizations, so sacrifices performance for protection against sociopathic expressions - extends the api to do backwards searching (similar to memrchr in a byte string, where memchr does the forward searching) But certainly has none of the production-ready style of matching that would be necessary for a full grep replacement, to say nothing of atf tests (it has its own test suite, just not atf) Neither OpenBSD's nor FreeBSD's grep use Aho-Corasick for fgrep: OpenBSD's grep looks like the non-GNU version in `usr.bin/grep'. Both use the system (Spencer?) regex for the heavy lifting; and, FreeBSD's fgrep is just regcomp(REG_NOSPEC) :). -RVP
Re: grep -r: add default "."
On Sat, 3 Sep 2022, Martin Husemann wrote: How about fixing the bsd version we have in tree instead? Maybe FreeBSD or OpenBSD already did that and we can borrwo? There is also the home-grown agcre in othersrc which looks (mostly) feature-complete... -RVP
Re: grep -r: add default "."
On Fri, 2 Sep 2022, Thomas Klausner wrote: I'd like the change the behaviour to match what GNU grep does. Comments? FreeBSD's and OpenBSD's grep (both non-GNU) do the same thing, so it makes sense to harmonize NetBSD's (old GNU) grep -r behaviour too. -RVP
Re: unhide reallocarray
On Tue, 30 Aug 2022, Thomas Klausner wrote: So I'd like to put it outside of the _OPENBSD_SOURCE #ifdef so it is available without _OPENBSD_SOURCE being defined. Comments? Go for it. (Had intended to ask for exactly that myself some time back to prevent PR #56746 from happening again.) -RVP
Re: sh(1) and ksh(1) default PATH
On Mon, 15 Aug 2022, Hauke Fath wrote: On Sun, 14 Aug 2022 09:04:21 + (UTC), RVP wrote: Linux has a pam_env.so which reads /etc/environment and /etc/environment.d/* for this kind of thing. I was looking for something like that on NetBSD a while back... login.conf(5) can set PATH. Yeah, I looked into that for someone a while ago, and that doesn't work in all cases. For example: 1. xdm The `setenv' capability doesn't work in xdm (the code just won't work as it stands); and in any case, xdm prefers a different method for setting PATH and env. (the `DisplayManager.*' resource settings). 2. su The default PAM variant does honour `setenv', but, the non-PAM one doesn't look like it does (it only does PATH). 3. sudo/doas/... 3rd-party programs don't seem to grok `setenv' OTOH, all of these, if they use PAM, do seem to call pam_getenvlist() and use properly the returned variables. -RVP
Re: sh(1) and ksh(1) default PATH
Linux has a pam_env.so which reads /etc/environment and /etc/environment.d/* for this kind of thing. I was looking for something like that on NetBSD a while back... -RVP
lib/libcrypt/crypt-argon2.c: ctx.{out,outlen} assigned twice
Looks like ctx.{out,outlen} are being assigned twice:
---START---
--- lib/libcrypt/crypt-argon2.c.orig2021-11-22 21:56:12.532724453 +
+++ lib/libcrypt/crypt-argon2.c 2022-02-11 09:59:51.260664174 +
@@ -386,9 +386,6 @@
/* we use static buffers to avoid allocation */
/* and easier cleanup */
- ctx.out = (uint8_t *)ebuf;
- ctx.outlen = sizeof(ebuf);
-
ctx.out = (uint8_t *)encodebuf;
ctx.outlen = sizeof(encodebuf);
---END---
Thanks,
-RVP
Re: possible bug in fseek of buffered files shared between processes (example uses stdin)
On Wed, 3 Nov 2021, Carlo Arenas wrote: but it didn't work (even if it seems to be a step in the right direction); not sure if it was me who messed it up though, but building another iteration takes too long to know; will try with NetBSD current next. Don't bother; that first patch only handles the non-seek case like the test code in your initial mail. I have to fix-up the code to take care of explicit seeks, too. in my testcase[1] (and pcre2grep), we are using the buffer whole and need to fseek to get it to the right place if the read was overshot, Yes, that case is not handled in the patch... but something else seems to be doing an lseek(0, 0, SEEK_CUR) at the end of the buffer read, and that conflicts with the new fclose code, That's an ftell() (or similar) and shouldn't interfere with subsequent fseek()s. an alternative implementation, might use to its advantage the fact that at close time the streams should be flushed and do the necessary seek there as required by fflush[2] in POSIX (seems that at least since SUSv3, an fflush(stdin) is a valid operation and should update the position of the underlying file)[3] If you read closely, you'll see that those requirements are marked as extensions and so not necessary for (strict) compliance. In fact, the fflush() RATIONALE says: Data buffered by the system may make determining the validity of the position of the current file descriptor impractical. Thus, enforcing the repositioning of the file descriptor after fflush() on streams open for read() is not mandated by POSIX.1-2017. but, fflush() causing an underlying seek seems useful. I'll see what I can do this weekend. -RVP
Re: possible bug in fseek of buffered files shared between processes (example uses stdin)
On Tue, 2 Nov 2021, Christos Zoulas wrote:
In article ,
RVP wrote:
This looks like a useful behaviour to add to the libc close routines.
I agree!
A first cut is something like this:
---START PATCH---
diff -urN stdio.orig/fclose.c stdio/fclose.c
--- stdio.orig/fclose.c 2012-03-15 18:22:30.0 +
+++ stdio/fclose.c 2021-11-02 22:00:31.604704902 +
@@ -62,6 +62,15 @@
FLOCKFILE(fp);
WCIO_FREE(fp);
r = fp->_flags & __SWR ? __sflush(fp) : 0;
+ if (fp->_seek != NULL && fp->_flags & __SRD) {
+ if (fp->_flags & __SOFF)
+ fp->_seek(fp->_cookie, fp->_offset, SEEK_SET);
+ else if (fp->_bf._base != NULL) {
+ off_t o = -fp->_r;
+ _DIAGASSERT(o <= 0);
+ fp->_seek(fp->_cookie, o, SEEK_CUR);
+ }
+ }
if (fp->_close != NULL && (*fp->_close)(fp->_cookie) < 0)
r = EOF;
if (fp->_flags & __SMBF)
diff -urN stdio.orig/findfp.c stdio/findfp.c
--- stdio.orig/findfp.c 2012-03-27 15:05:42.0 +
+++ stdio/findfp.c 2021-11-02 21:46:29.767257736 +
@@ -207,8 +207,10 @@
void
_cleanup(void)
{
- /* (void) _fwalk(fclose); */
+ (void) _fwalk(fclose);
+#if 0
(void) fflush(NULL);/* `cheating' */
+#endif
}
/*
---END PATCH---
Carlo, can you see if that works with your use-case?
-RVP
Re: possible bug in fseek of buffered files shared between processes (example uses stdin)
On Tue, 2 Nov 2021, Carlo Arenas wrote:
while troubleshooting a test failure for pcre2[0] in OpenBSD, tracked
down the problem to code that was inherited from NetBSD for their
fseek implementation in libc.
This isn't actually an fseek issue. Glibc and musl do an explicit lseek()
when closing a file if there is unread data in the buffer:
$ cc -o h head.c
$ (strace -o x.log ./h 1; echo .; ./h 2; echo .; cat) < head.c
#include
.
#include
.
int
main(int argc, char* argv[])
{
char line[BUFSIZ];
int n;
if (argc != 2)
return EXIT_FAILURE;
n = atoi(argv[1]);
while (n-- && fgets(line, sizeof line, stdin))
printf("%s", line);
return EXIT_SUCCESS;
}
$ tail x.log
munmap(0x7f0f0e89d000, 78789) = 0
fstat(0, {st_mode=S_IFREG|0600, st_size=258, ...}) = 0
brk(NULL) = 0x5564cc789000
brk(0x5564cc7aa000) = 0x5564cc7aa000
read(0, "#include \n#include \n", 19)= 19
lseek(0, -239, SEEK_CUR)= 19
exit_group(0) = ?
+++ exited with 0 +++
$
This looks like a useful behaviour to add to the libc close routines.
-RVP
Re: Strange pthread_self() return value
On Fri, 11 Jun 2021, nia wrote:
The segfault is actually in hwloc, a library used by OpenCL:
Program received signal SIGSEGV, Segmentation fault.
0x764e5660a2c8 in pthread_getaffinity_np () from /usr/lib/libpthread.so.1
(gdb) bt
#0 0x764e5660a2c8 in pthread_getaffinity_np () from
/usr/lib/libpthread.so.1
#1 0x764e5ec1f86e in hwloc_netbsd_get_thread_cpubind
(topology=topology@entry=0x764e6006,
tid=0x, hwloc_cpuset=hwloc_cpuset@entry=0x764e60078a80,
flags=flags@entry=4)
at topology-netbsd.c:112
#2 0x764e5ec1f8d3 in hwloc_netbsd_get_thisthread_cpubind
(topology=0x764e6006,
hwloc_cpuset=0x764e60078a80, flags=4) at topology-netbsd.c:133
Notice how "tid" is 0x. Attempting to set the affinity
of thread "0x" obviously fails.
However, this value comes from the return value of pthread_self():
static int
hwloc_netbsd_get_thisthread_cpubind(hwloc_topology_t topology, hwloc_bitmap_t
hwloc_cpuset, int flags)
{
return hwloc_netbsd_get_thread_cpubind(topology, pthread_self(), hwloc_cpuset,
flags);
}
What's going on?
1. Is `hwloc_thread_t' the same as `pthread_t' when hwloc is compiled
on NetBSD?
2. Does a `make check' of hwloc on NetBSD pass?
-RVP
Re: proposal: remove traditional C support from lint
On Thu, 18 Mar 2021, Thomas Klausner wrote: with -S, one more warning is removed, but still a lot remain: inttypes.h(66): warning: struct _locale never defined [233] ansi.h(51): warning: struct __tag_wctrans_t never defined [233] ansi.h(54): warning: struct __tag_wctype_t never defined [233] types.h(323): warning: struct kauth_cred never defined [233] pthread_types.h(61): warning: struct __pthread_st never defined [233] pthread_types.h(70): warning: struct __pthread_spin_st never defined [233] time.h(146): warning: struct sigevent never defined [233] time.h(198): warning: struct __state never defined [233] Add `-z' for those. I also usually add `-nu' because /usr/libdata/llib-lc.ln is MIA in 9.1_STABLE. -RVP
Re: Waiting for Randot (or: nia and maya were right and I was wrong)
On Thu, 14 Jan 2021, nia wrote: On Thu, Jan 14, 2021 at 09:43:44PM +, RVP wrote: Is this OK (or, it is hopelessly insecure)?: If you have the same secure randomness as everyone else you don't have secure randomness. True, generally, but I was thinking of a) the hopeless cases, b) the work-factor involved in an attacker guessing which random bits were chosen from a random file, and c) this is only for initial installs. -RVP
Re: Waiting for Randot (or: nia and maya were right and I was wrong)
On Thu, 14 Jan 2021, Manuel Bouyer wrote: And what about systems that don't have a /dev/audio (or system that have play-only /dev/audio) ? Is this OK (or, it is hopelessly insecure)?: 1. Use environment (keyb. delay, mouse, ...) to seed the libc PRNG. 2. Use the PRNG values to pick out random bits from a truely random file. The random file is generated anew each time an distrib. image is built. If one needs 256 bits to seed /dev/random, then a 32K random file should suffice. The other alternative is the user mashing the keyboard and moving a mouse for a few minutes. -RVP
Re: wsmoused broken since 9.1
On Wed, 23 Dec 2020, Martin Husemann wrote:
On Wed, Dec 23, 2020 at 06:56:31AM +, RVP wrote:
/usr/sbin/wsmoused has been non-working since slightly
before 9.1 was released. Specifically, any button click
or release generates:
Can you narrow down the pullup that broke it?
I was mis-remembering. I just tried out 9.0 and it is broken
there too. This change is what caused the breakage in
wsmoused(8):
cvs rdiff -r 1.13 -r 1.14 src/sys/dev/wscons/wsdisplay_vcons.c
This test in function vcons_getwschar():
if ((wsc->row >= 0) && (wsc->row < ri->ri_rows) && (wsc->col >= 0) &&
(wsc->col < ri->ri_cols)) {
I'm surprised that nobody's noticed this breakage since Aug 2007.
Is console + wsmoused so little used? ;)
-RVP
Re: wsmoused broken since 9.1
On Wed, 23 Dec 2020, Martin Husemann wrote: Can you narrow down the pullup that broke it? I can only tell you when I noticed it. It was OK in 9.0 RELEASE; then I tried one of the final 9.0-STABLE images (the last or next-to-last) before 9.1 and found the bug. Is it still broken in -current? Yes. -RVP
Re: EDID from multiple displays using ioctl(WSDISPLAYIO_GET_EDID)
On Wed, 23 Dec 2020, Michael van Elst wrote: If you had multiple wsdisplay* instances, there would be some corresponding ttyE* that you could send the ioctl to. Hmm: wsdisplay0 at intelfb0; wsdisplay1 at nouveaufb0 ? What about multiple multiple monitors connected to the same card? -RVP
wsmoused broken since 9.1
/usr/sbin/wsmoused has been non-working since slightly
before 9.1 was released. Specifically, any button click
or release generates:
wsmoused: ioctl(WSDISPLAYIO_GETWSCHAR) failed: Invalid argument
and click+drags produce a torrent of the same. Here is a patch
which fixes this problem:
---START---
diff -urN a/wsmoused/selection.c b/wsmoused/selection.c
--- a/wsmoused/selection.c 2007-05-27 15:05:00.0 +
+++ b/wsmoused/selection.c 2020-10-21 06:17:38.666544347 +
@@ -144,6 +144,7 @@
static void selarea_start(void);
static void selarea_end(void);
static void selarea_calculate(void);
+static void selarea_getrowcol(size_t, size_t*, size_t*);
static void selarea_hide(void);
static void selarea_show(void);
static void selarea_paste(void);
@@ -624,14 +625,29 @@
/* -- */
+/* Turns selection absolute position in the screen buffer back into
+ row, col co-ordinates */
+static void
+selarea_getrowcol(size_t pos, size_t* row, size_t* col)
+{
+ size_t xres = Selmouse.sm_max_x + 1;
+
+ *row = pos / xres;
+ *col = pos - (*row * xres);
+}
+
+/* -- */
+
/* Hides the highlighted region, returning it to normal colors. */
static void
selarea_hide(void)
{
- size_t i;
+ size_t i, row, col;
- for (i = Selarea.sa_startoff; i <= Selarea.sa_endoff; i++)
- char_invert(0, i);
+ for (i = Selarea.sa_startoff; i <= Selarea.sa_endoff; i++) {
+ selarea_getrowcol(i, , );
+ char_invert(row, col);
+ }
}
/* -- */
@@ -640,11 +656,13 @@
static void
selarea_show(void)
{
- size_t i;
+ size_t i, row, col;
selarea_calculate();
- for (i = Selarea.sa_startoff; i <= Selarea.sa_endoff; i++)
- char_invert(0, i);
+ for (i = Selarea.sa_startoff; i <= Selarea.sa_endoff; i++) {
+ selarea_getrowcol(i, , );
+ char_invert(row, col);
+ }
}
/* -- */
diff -urN a/wsmoused/wsmoused.c b/wsmoused/wsmoused.c
--- a/wsmoused/wsmoused.c 2011-05-31 03:37:02.0 +
+++ b/wsmoused/wsmoused.c 2020-10-21 06:17:38.666544347 +
@@ -71,7 +71,7 @@
static int X_Console = -1;
static int X_Console_Delay = 5;
-#ifdef WSMOUSED_SELECTION_MODE
+#ifdef WSMOUSED_ACTION_MODE
extern struct mode_bootstrap Action_Mode;
#endif
#ifdef WSMOUSED_SELECTION_MODE
---END---
Thanks,
-RVP
EDID from multiple displays using ioctl(WSDISPLAYIO_GET_EDID)
Is there a way to retrieve EDID data from displays other than the default one using ioctl(WSDISPLAYIO_GET_EDID) ? On my Asus X202E laptop with 3 physical outputs (LVDS, VGA, HDMI) the ioctl gets the EDID only of the LVDS panel. This is for situations where X is not running/can't run and xrandr unavailable. -RVP
Re: set -o emacs when su?
On Tue, 10 Nov 2020, Mouse wrote: What do I have to do to arrange that "set -o emacs" is in effect when I su? I'm would expect I just need to drop the right incantation into the right file, but so far I have failed to discover the magic formula. I've been limping along manually typing set -o emacs each time, but that is...less than satisfactory. Use "su -l" and add that emacs option to /root/.shrc -RVP
