---
commit 44bc262d8170b10e6949c2836a820b7fee533de4 (local)
from: Christian Weisgerber
date: Tue Oct 24 14:09:57 2023 UTC
do not create /usr/local/share/nls and subdirectories by default
The share/nls/ paths are unused.
diff 85c70083e85910ddc7626ad658e5652c024b844a 44bc262d8170b10e6949c2836a820b7fee533
etters."
Sigh. Yes, duplication is evil, yada, yada, but would it really
be so bad to also list the tracepoints directly in kdump.1 instead
of pointing to ktrace.1?
---
commit 6537a30531732808760afdc5dcd7331aeb9d7618 (local)
from: Christian Weisgerber
Alexander Bluhm:
> Variable scs_use is basically counting packet insertions to syn
> cache, so I would prefer type long to exclude overflow on fast
> machines. With the current limits int should be enough, but long
> does not hurt.
But long is the same size as int. On our 32-bit archs. Or are
Klemens Nanni:
> If the root disk contains a valid CRYPTO volume, bioctl(8) by default
> unlocks that instead of creating a new one.
>
> Use `-C force' to prevent reuse of old volumes,
Yes, I like this. During testing I ran into the case where it
re-used an existing crypto volume and I thought
This replaces "$(cat file)" with the ksh construct "$(/dev/null)
unchanged, since it would require
{ local var=$(<$HTTP_SEC); } 2>/dev/null
which is sufficiently opaque that I'm not sure it's an improvement.
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -77,7 +77
Jan Klemkow:
> This diff introduces separate flags for TCP offloading. We split this
> into LRO (large receive offloading) and TSO (TCP segmentation
> offloading). Thus, we are able to turn it on/off separately.
Wait, why do we even have a knob for TSO?
We specifically decided not to have a kn
commit 072b0a41d978c446342c34a7a901579f460f80d2 (llvm15)
from: Christian Weisgerber
date: Fri Apr 21 21:25:24 2023 UTC
Implement support for PT_OPENBSD_NOBTCFI in lld(1). This can be set using
the -z nobtcfi option.
ok deraadt@
diff 0
Alexander Bluhm:
> After enabling -fcf-protection=branch for the kernel, we have a new
> .plt section in the kernel. It was not there before.
Same issue in userland: At least /usr/lib/crt0.o and /usr/lib/crtbegin.o
have grown .plt and .note.gnu.property sections and some tools
(ld.bfd?) don't li
penBSD.
LLVM 15 reshuffled some code, so the change above no longer applies
there. Here's my attempt to add it:
---
commit d80c4bf3bc72f631512bdaa922cc31d46a07257b (llvm15)
from: Christian Weisgerber
date: Mon Apr 17 22:33:20 2023 UTC
llvm:
On 2023-04-05, Klemens Nanni wrote:
>> In conversation with Klemens (kn@) new iteration has been born, it
>> follows to what Omar (op@) has suggested - we're not trying to change
>> the default answer for all cases, since no one complained for all these
>> years, but just flip default for install
The installer deletes obsolete libLLVM.so versions during an upgrade.
However, a number of libLLVM.so versions have come and gone and the
installer hasn't been synced. We're now at .7.0, so delete all the
earlier ones.
ok?
---
remove obsolete libLLVM.s
Jan Klemkow:
> > igc(4) has very similar code, but I don't have access to a machine
> > with that hardware.
>
> Send me an ssh-key and I give you access to this machine:
Alternatively, here's the diff, so other people can test it.
diff a0c537a1c9d84e98322b55d8f71438a147aaa7c4
7d976644b87094d08
Christian Weisgerber:
> I also switched over em(4) to this and have successfully used it
> for a full 30-hour package build on the four amd64 ports machines
> with their I350 interfaces. Additionally, I've done some IPv6
> testing at home over an I210.
ok for this?
igc(4) has
Jan Klemkow:
> > > - I turned the KASSERTS to returns.
> > > - Check if the mbuf is large enough for an ether header.
> > > - additionally #ifdef'd INET6 around the ip6_hdr in the new struct
> >
> > For non-initial fragments of TCP/UDP packets, ether_extract_headers()
> > will create ext.tcp/e
Jan Klemkow:
> - I turned the KASSERTS to returns.
> - Check if the mbuf is large enough for an ether header.
> - additionally #ifdef'd INET6 around the ip6_hdr in the new struct
For non-initial fragments of TCP/UDP packets, ether_extract_headers()
will create ext.tcp/ext.udp pointers that do
Crystal Kolipe:
> Here is the latest version of the double underline and strikeout parts of my
> console patchset.
I'm sorry, but I gotta ask: Who or what uses something like this??
Offhand, I don't even know if xterm can do it. If you want this
kind of typographic detail, shouldn't you be usin
Vitaliy Makkoveev:
> The ether_extract_headers() diff was reverted, because is wrong for the
> cases other than tcp/udp/icmp. We need to fix it and recommit again
> before continue.
I think (TCP or) UDP fragments are the problem. Fragments don't have
the protocol header but will still end up her
Jan Klemkow:
> we have several drivers which have to parse the content of mbufs. This
> diff suggest a central parsing function for this. Thus, we can reduce
> redundant code.
>
> I just start with ix(4) and ixl(4) because it was easy to test for me.
> But, this could also improve em(4), igc(4)
Scott Cheloha:
> The UltraSPARC IIe's %TICK register has a variable frequency.
> miod@ confirmed that the problem is real.
Indeed, I remember clocking down the Blade 100 with apm(8).
Somebody with access to the hardware might want to adapt the NetBSD
code that adds timecounter support for the ST
Klemens Nanni:
> This has been running fine through regress and daily usage on my X230 driver
> for months, incl. selected ports builds.
>
> Feedback? Objection? Tests? OK?
The only user of minherit() in base appears to be libc's arc4random.
I successfully ran a full amd64 package bulk build wi
Yuichiro NAITO:
> +static void
> +ixv_set_multi(struct ix_softc *sc)
> +{
[...]
> + if ((ifp->if_flags & IFF_PROMISC) == 0 && ac->ac_multirangecnt <= 0 &&
> + ac->ac_multicnt <= MAX_NUM_MULTICAST_ADDRESSES) {
> + ETHER_FIRST_MULTI(step, &sc->arpcom, enm);
> +
Martin Pieuchot:
> These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> will reduce contention a lot. I'd be happy to hear from test reports
> on many architectures and possible workloads.
This survived a full amd64 package build.
--
Christian "naddy" Weisgerber
Damien Miller:
> bash has a PROMPT_COMMAND that allows a command to be executed before
> each PS1 prompt is displayed. I've found this useful on occasion, so
> this is the same thing for ksh(1).
PS1 is evaluated each time the prompt is displayed. You can put a
command in $() in there.
PROMPT_CO
Scott Cheloha:
> > kern.timecounter.tick=1
> > kern.timecounter.timestepwarnings=0
> > kern.timecounter.hardware=i8254
> > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000)
>
> This is expected behavior with the patch.
>
> cpu0's TSC is way out of sync with every
> oth
The X11 session startup files for xenodm and xinit share the same
snippet which checks if any of the default ssh private key files
exist, and if so, starts ssh-agent and runs ssh-add.
The list of key files is outdated. SSH1 "identity" is gone, and
"id_ecdsa_sk" and "id_ed25519_sk" have been added
Jan Stary:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/dump/main.c.diff?r1=1.4&r2=1.5&f=h
> "Use getopt(3), with obsolete() from restore(8) for backward compatibility."
>
> So it's restore(8); I write "restore rf" myself.
> Is this it? Does that still need to be supported by dump(8)?
The same
Florian Obser:
> Sounds reasonable, this adds the FIDO section and moves the -O bits in.
> The wording is inspired by / copied from the 8.2 release notes and the
> CERTIFICATES section.
I think that makes sense.
s/token/authenticator/g
We standardized on "FIDO authenticator" some time ago, beca
So I did "objdump -t bsd | fgrep 'O .data' | sort -k5r" on arm64.
Oh my.
The diff below constifies a myriad of pin, clock, etc. tables.
This is all very mechanical. An arm64 GENERIC.MP kernel still
builds and boots with this.
OK?
M sys/dev/fdt/amlclock.c
M sys/dev/fdt/amlpinctrl.c
M sys/dev
Christian Weisgerber:
> This will allow constifying the ddb command tables in a subsequent
> step.
And here's that boring follow-up diff.
M sys/arch/alpha/alpha/db_interface.c
M sys/arch/amd64/amd64/db_interface.c
M sys/arch/arm/arm/db_interface.c
M sys/arch/arm64/arm64/db_in
Most of our architectures implement a "machine" command as a MD
extension in ddb(4).
Currently that is handled in this way:
* A define is placed in a MD header.
* The MI ddb code checks for the define, creates an incomplete
entry in the command table, and provides an initialization function.
* M
Marcus Glocker:
> > This constifies the bus method and pipe method tables in our USB
> > host controller drivers.
>
> dwctwo(4) also exists on arm64.
Oops, right. That arch I have.
The USB host controller drivers also have another set of tables to
emulate the root hub. I have extended the dif
This constifies the SCSI adapter entry points (struct scsi_adapter).
It reaches into some archs I don't have...
ok?
M sys/arch/luna88k/dev/mb89352.c
M sys/arch/luna88k/dev/mb89352var.h
M sys/arch/luna88k/dev/spc.c
M sys/arch/sparc64/dev/vdsk.c
M sys/dev/ata/atascsi.c
M sys/dev/atapiscsi/ata
This constifies the method tables used by the atascsi framework and
the ahci(4) and sili(4) drivers.
ok?
diff 9939c0709df17eb9b8160ad1561241ed2c4b8922
83fd09f48cb0df5e29a782b651c4210e90f90b00
blob - 46c681203e8e39e25167f98907a2ecc848e9d1a4
blob + 19f61480e83314afe9d58d24b52e1b1d7e64ea93
--- sys
This constifies the method tables in the OAK USB sensor drivers.
Bycatch from the ucom changes.
ok?
diff b29fcdeeb3e7dfaa7565194eb526a7ece255a8a8
9939c0709df17eb9b8160ad1561241ed2c4b8922
blob - 789cef98e6a9a4d88bbb19b33e1801396618c591
blob + 511c0e62aec982253cdf4b27ae2af3e020cc6f9f
--- sys/dev/
This constifies the ucom method tables in the USB serial adapter
drivers, i.e., moves another kilobyte of function pointers into
read-only space.
ok?
diff 4df278d953b03573222cb39b422e005d4701614e
b29fcdeeb3e7dfaa7565194eb526a7ece255a8a8
blob - 0f5d4bed40c58062bd043d0366485629d59c53cd
blob + bb96
This constifies the bus method and pipe method tables in our USB
host controller drivers.
dwctwo(4) only exists on octeon, which I don't have access to.
Could somebody check that it builds?
ok?
diff b5489662588c813212f71c840fa931535322293d
4df278d953b03573222cb39b422e005d4701614e
blob - 9b9d16
This constifies the tables of two unrelated sensor drivers:
esm(4/i386) and it(4).
ok?
diff d6a09d27ff49886a6b6f4bd1f7d89c0f90a64b40 refs/heads/const
blob - 0a734dc971d9402e738d08d014555c8afb95827b
blob + e8a4e5eeadcdcfd23c1dd525470e70522272676b
--- sys/arch/i386/i386/esm.c
+++ sys/arch/i386/i386
This constifies the sensor tables of the lm(4), uguru(4), fins(4), and
wbenv(4) drivers, which all share the same basic design.
ok?
diff refs/heads/master refs/heads/const_sensors
blob - a813447ec9521a2a11a8b1f5daa38b881da007c1
blob + 3a1b2bfdc2b1d92d62f3b156479ad0ff5b57e463
--- sys/dev/i2c/w83l7
This constifies the ifmedia description tables, both in the kernel
(yes, I did a test compile with option IFMEDIA_DEBUG) and one
straggler in userland.
ok?
diff 3c78bc9451ce7ce927aaecc9f8e5113de7023a9c /usr/src
blob - 0ef67c56edd8be741533ccba974c11f198887b32
file + sbin/ifconfig/ifconfig.c
--- sb
You'd think that the kernel font bitmaps are a primary example of
data that could be read-only... and you'd be wrong.
The font encoding tables however are indeed constant as far as I can
tell. The diff below marks them as such. NetBSD has the same.
ok?
diff e8186ba8726c14dfc3512467cc2bc0b2ae1a
It appears that in revision 1.85 of usr.bin/ftp/ftp.1 a sentence
fragment was accidentally not removed.
OK?
Index: usr.bin/ftp/ftp.1
===
RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
retrieving revision 1.122
diff -u -p -r1.122 ftp.1
--- us
Mark Kettenis:
> There is a scenario where this goes wrong. If a shared library lacks
> a DT_SONAME entry, the library filename is used to generate the
> DT_NEEDED entries. But I would consider such a shared library broken
> and we fixed base a lng time ago. Some care has to be taken when
>
Christian Weisgerber:
> usr.sbin/ypldap: fix -Wunused-but-set-variable warnings
>
> * "wrlen" has been write-only since the code was imported.
> * Removing "dns_pid" replicates ntpd/ntp.c 1.122 (aece4353519f).
> * yp_check() looks like unfinished code. Rathe
First up, note that clang 13 does not produce those
"variable foo set but not used" warnings by default.
They need to be enabled by -Wunused-but-set-variable
or, more typically, as part of -Wall.
Here are the remaining warnings seen in a "make build":
bin/ksh required arguments to macros
usr.sbin/ypldap: fix -Wunused-but-set-variable warnings
* "wrlen" has been write-only since the code was imported.
* Removing "dns_pid" replicates ntpd/ntp.c 1.122 (aece4353519f).
* yp_check() looks like unfinished code. Rather than removing it
we can ifdef it out.
ok?
M usr.sbin/ypldap/ent
usr.sbin/tcpdump: fix -Wunused-but-set-variable warning
All "infile" handling was moved into priv_exec() when tcpdump was
priviledge separated. The options are scanned both in priv_exec()
and in main(), so the empty case needs to remain in the latter.
ok?
M usr.sbin/tcpdump/tcpdump.c
diff 81
remove unused variable from all copies of _asr_strdname() and print_dname()
This also fixes -Wunused-but-set-variable warnings warnings in smtpd
and smtpctl. The code was imported with asr and then copied around.
ok?
M lib/libc/asr/asr.c
M regress/lib/libc/asr/bin/res_mkquery.c
M regress/li
usr.sbin/rad: fix -Wunused-but-set-variable warning
Trivial removal of unused variable.
M usr.sbin/rad/frontend.c
diff c9fb0989c5128843af76d1ecd08c6f483f233307
1779a21799642d5916a407f0cea6255b101c055c
blob - e6f6ae0419ab1662ebb2e8cdd17c07a82d1b87f9
blob + afddc245017e4576571e89b17f3655d352dc1
usr.sbin/ospf6ctl: fix -Wunused-but-set-variable warning
Maybe this is uncompleted code, but I think we can remove it for
the time being.
M usr.sbin/ospf6ctl/ospf6ctl.c
diff a992977b148f5fd9d4e3b9af9aeccac488edfa7a
c9fb0989c5128843af76d1ecd08c6f483f233307
blob - fa1dc2cfd77369dc6964a6f18f6b56
usr.sbin/ospf6d: fix -Wunused-but-set-variable warnings
merge_config() sets "rchange", but doesn't use it. Comparing the
code to osfpd/ospfd.c makes me think that's an omission. Either
way it seems odd that the two code bases differ here.
rde_summary_update() is incomplete. We can simply #ifde
usr.sbin/eigrpd: fix -Wunused-but-set-variable warning
M usr.sbin/eigrpd/rde_dual.c
diff 41bbcfa017d9537de08312789d0087c674ce4732
77e83947795bf5b53aef72070d7630a825b52c1f
blob - f1ed306e1371896676cf45b26e102af5e4d77b36
blob + 9465250934a6b1a5f6d565a13d32c4c450786670
--- usr.sbin/eigrpd/rde_dua
usr.sbin/dvmrpctl: fix -Wunused-but-set-variable warning
This looks like /* not yet implemented */, but the companion functions
show_rib_detail_msg() and show_mfc_detail_msg() are equally empty.
M usr.sbin/dvmrpctl/dvmrpctl.c
diff 4bd575d8630c92f404211d2c625b200ac28213b9
41bbcfa017d9537de0831
usr.sbin/dhcpd: fix -Wunused-but-set-variable warning
I think this should be fine as strtonum() will catch any errors.
M usr.sbin/dhcpd/parse.c
diff 5ce17aab12dafb0a17452c4e0e86b29d89d83d13
4bd575d8630c92f404211d2c625b200ac28213b9
blob - 5b719219d00046e02e932796a78dc14ceddaa109
blob + 28334a4
usr.bin/mg: fix -Wunused-but-set-variable warnings
* strtonum() is only called to verify that a string is numerical, the
return value is unused.
* inlist is no longer used after the code was refactored.
OK?
M usr.bin/mg/interpreter.c
diff 6e5c342a53c05496c18849837c67b7dc05ce3792
5ce17aab12
sbin/isakmpd: fix -Wunused-but-set-variable warnings
The one in pf_key_v2.c could use an extra set of eyes, but I don't
think there are any side effects.
M sbin/isakmpd/ipsec.c
M sbin/isakmpd/pf_key_v2.c
M sbin/isakmpd/udp_encap.c
M sbin/isakmpd/x509.c
diff ce1a8a9dca08dd7e01f71dfff05f1e4f4
sbin/pfctl: fix -Wunused-but-set-variable warning
M sbin/pfctl/pfctl_optimize.c
diff 7c5dd09ecd1ff078b868c9ab52aac9754cde7761
6e5c342a53c05496c18849837c67b7dc05ce3792
blob - 1ab170a832dd183a2895774549ff93896803039a
blob + 5736a0d7b0ba04afeed855daa61fc6b5ef3894e4
--- sbin/pfctl/pfctl_optimize.c
Since the switch to LLVM 13, there are a number of compiler warnings
in base about variables that are assigned to but never used. Let's
start picking the low-hanging fruit, ok?
lib/libfuse: fix -Wunused-but-set-variable warning
M lib/libfuse/fuse_opt.c
diff 926818cffbbacfeb5685fa0f8e104986608
Klemens Nanni:
> > > Now this is clearly a "slow" path. I don't think there is any reason
> > > not to put all the code in that if (uvw_wxabort) block under the
> > > kernel lock. For now I think making access to ps_wxcounter atomic is
> > > just too fine grained.
> >
> > Right. Lock the whole
Vitaliy Makkoveev:
> Include missing "sys/refcnt.h" header to unpcb.h to fix libkvm and
> netstat(1) build. No functional changes.
I ran an amd64 package bulk build with this, four ncpu=4 machines.
No problems.
(Other than for dpb's ssh connection multiplexing, I don't think
Unix domain sockets
Christian Weisgerber:
> Here's another attempt, incorporating millert's feedback and adding
> a few more casts:
Any interest in this or not worth the churn and I should drop it?
> Index: bin/chio/parse.y
> ==
Here's another attempt, incorporating millert's feedback and adding
a few more casts:
Index: bin/chio/parse.y
===
RCS file: /cvs/src/bin/chio/parse.y,v
retrieving revision 1.23
diff -u -p -r1.23 parse.y
--- bin/chio/parse.y15 Oct
Todd C. Miller:
> On Thu, 30 Sep 2021 21:37:06 +0200, Christian Weisgerber wrote:
>
> > Unfortunately that also affects the parsebuf/pushback_buffer complex
> > used in some parser.y files.
>
> That would require a few extra casts but it is straightforward.
E.g. lik
Todd C. Miller:
> lungetc((u_char)*p);
> ...
> c = (u_char)*--p;
>
> Since we use casts sparingly, when they are present they indicate
> something you need to pay attention to. That is not the case when
> we simply change the type.
Unfortunately that also affects the parsebuf/
Christian Weisgerber:
> The oft-copied parse.y code declares some variables as "unsigned char *"
> but passes them to functions that take "char *" arguments and doesn't
> make any use of the unsigned property.
While I'm here...
> int
>
The oft-copied parse.y code declares some variables as "unsigned char *"
but passes them to functions that take "char *" arguments and doesn't
make any use of the unsigned property.
For OpenBSD's clang, -Wpointer-sign has been disabled by default,
but when that code is built elsewhere, the compile
Ingo Schwarze:
> deraadt@ recently pointed out to me in private mail that it is good
> for usability if interactive programs providing line editing
> functionality are consistent what they do with Ctrl-C, ideally
> discard the current input line and provide a fresh prompt.
>
> So i propose to do
scp: tweak documentation and error message for -3 by default
Now that the -3 option is enabled by default, flip the documentation
and an error message from "requires -3" to "blocked by -R".
OK?
diff 453220bf36dcff10addeceb44e98f71bfeddcd53
f457be8f3b007fb662dd10fb565ab79b602109f5
blob - 97226
"Theo de Raadt":
> 2) With very long names, it truncates the end of the path. This is less useful
> information. Imagine a copy operation with multiple files being transferred,
> one of them is huge and surprisingly long, but you cannot identify which one
> because all the truncated long paths ar
Damien Miller:
> Just a head-up: snaps currently contain a set of changes[1] to
> make scp(1) use the SFTP protocol by default.
> Please report any incompatibilities or bugs that you encounter here
> (tech@), to bugs@ or to openssh@.
An obvious cosmetic difference is that relative paths are pref
Visa Hankala:
> However, wouldn't it be better if the code avoided the
> situation, for example by defining ADJFREQ_MIN as the negative
> of ADJFREQ_MAX?
Indeed it would. ok naddy@
> --- kern/kern_time.c 23 Dec 2020 20:45:02 - 1.151
> +++ kern/kern_time.c 30 May 2021 15:38:09 -
>
Marc Espie:
> I would also actually be fairly happy if we changed drastically the way
> sh(1) and ksh(1) look. To me, sh(1) should be the (more or less) standard
> shell documentation, AND ksh(1) should contain the differences/extensions.
I think that is a terrible idea. Historically the tcsh(1)
Jason McIntyre:
> - i'm ok with the getopt.1 and ksh.1 parts
> - i'm not ok with the addition to sh.1
>
> no one has really given a good reason why they think it should go into
> sh.1. i've given a few why i think it should not.
My understanding is that sh.1 is a subset of ksh.1, describing the
In this auxiliary script, replace the deprecated getopt with getopts.
There is no pressing reason to do so, but let's stop perpetuating
an obsolete idiom.
ok?
Index: usr.sbin/switchd/genmap.sh
===
RCS file: /cvs/src/usr.sbin/switchd/
Marc Espie:
> Until a patch from naddy, I wasn't even aware of getopts in sh(1)
Let's start the discussion with this instead.
This puts the deprecation notice in getopt.1 in a prominent place,
and uses the same snippet in sh.1 and ksh.1.
Index: bin/ksh/ksh.1
Christian Weisgerber:
> > Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> > both amd64 and sparc64. That means the kernel lock will only be taken
> > for lower faults and some amap/anon code will now run without it.
>
> I ran an amd64 bulk bui
Martin Pieuchot:
> Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> both amd64 and sparc64. That means the kernel lock will only be taken
> for lower faults and some amap/anon code will now run without it.
>
> I'd be interested to have this tested and see how much does t
Todd C. Miller:
> I don't think your use of qlen is safe since it is initialized
> to zero. Specifically, it looks like "qp->q_text[qlen - 1]"
> would be an out of bounds read. Should qlen be initialized
> to strlen(qp->q_text) if qp->q_text != NULL?
Right. Next iteration:
Index: quiz.c
=
Alex Karle:
> Looking deeper, there is a bug in quiz(6) for datfiles with multi-line
> answers.
>
> Specifically, the following quiz.db line:
>
> foo:\
> bar
>
> Is parsed into "foo:bar\n", which made it impossible to get right (since
> the comparison was expecting a newline). T
Christian Weisgerber:
> > Make use of getline(3) in ftp(1).
> >
> > Replace fparseln(3) with getline(3). This removes the only use
> > of libutil.a(fparseln.o) from the ramdisk.
> > Replace a complicated fgetln(3) idiom with the much simpler getline(3).
>
Christian Weisgerber:
> Make use of getline(3) in ftp(1).
>
> Replace fparseln(3) with getline(3). This removes the only use
> of libutil.a(fparseln.o) from the ramdisk.
> Replace a complicated fgetln(3) idiom with the much simpler getline(3).
New diff that fixes a bug I intro
Replace fgetln(3) with getline(3).
Since getline() returns a C string, we don't need to carry around
the length separately.
OK?
Index: sbin/disklabel/editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.36
Replace fgetln(3) with getline(3).
OK?
Index: sbin/fdisk/misc.c
===
RCS file: /cvs/src/sbin/fdisk/misc.c,v
retrieving revision 1.63
diff -u -p -r1.63 misc.c
--- sbin/fdisk/misc.c 3 Jul 2019 03:24:01 - 1.63
+++ sbin/fdisk/
Fix a pointer dereference in disklabel(8).
This looks like somebody wrote *s[0] in place of (*s)[0].
Which in this case happens to be equivalent, but it still looks
wrong.
OK?
Index: sbin/disklabel/editor.c
===
RCS file: /cvs/src/sb
Replace fgetln(3) with getline(3) in sed.
The mf_fgets() part is from Johann Oskarsson for Illumos/FreeBSD.
Passes our sed regression tests.
OK?
Index: usr.bin/sed/main.c
===
RCS file: /cvs/src/usr.bin/sed/main.c,v
retrieving revis
Hiltjo Posthuma:
> > @@ -75,19 +74,8 @@ cookie_load(void)
> > if (fp == NULL)
> > err(1, "cannot open cookie file %s", cookiefile);
> > date = time(NULL);
> > - lbuf = NULL;
> > - while ((line = fgetln(fp, &len)) != NULL) {
> > - if (line[len - 1] == '\n') {
> > -
Make use of getline(3) in ftp(1).
Replace fparseln(3) with getline(3). This removes the only use
of libutil.a(fparseln.o) from the ramdisk.
Replace a complicated fgetln(3) idiom with the much simpler getline(3).
OK?
Index: distrib/special/ftp/Makefile
===
Edgar Pettijohn:
> In the BUGS section for the getopt(3) manual it mentions not using
> single digits for options. I know spamd uses -4 and -6 there are
> probably others. Should they be changed? Or is the manual mistaken?
You misunderstand. The manual warns against the use of digits to
pass num
Denis Fondras:
> This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify with
> FreeBSD and Linux.
>
> I added aliases at the end of queue.h to avoid breaking base too much. they
> will
> be removed as soon as diff 2,3,4,5,6,7 are commited.
>
> net/sniproxy has a patch to define S
Theo de Raadt:
> What is lacking in this converstation is the justification.
> Why?
Providing STAILQ in OpenBSD will simplify porting to OpenBSD.
(Reality check: There is one port affected by this.)
Switching OpenBSD to STAILQ will simplify porting from OpenBSD.
(There are three or four FreeBSD
Denis Fondras:
> This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify with
> FreeBSD and Linux.
>
> I added aliases at the end of queue.h to avoid breaking base too much. they
> will
> be removed as soon as diff 2,3,4,5,6,7 are commited.
We'll need to run a ports bulk build wit
ncurses has a configure option that adds a few more consts to its
headers by way of the NCURSES_CONST define. Starting with version
6.0, this has become the default. OpenBSD is still on ncurses 5.7,
but FreeBSD and I guess most Linux distributions have moved on.
I suggest we also enable the addit
Claudio Jeker:
> In tal_parse() use strndup() to create the tal descr instead of the more
> complex malloc, memcpy version. Result is the same but the strndup version
> is a lot nicer.
Yes, but...
> --- tal.c 11 Oct 2020 12:39:25 - 1.22
> +++ tal.c 3 Dec 2020 12:00:25 -
> @@
Mark Kettenis:
> What would the impact on ports of disabling base-gcc be on powerpc?
None.
$ cd /usr/ports
$ make ARCH=macppc MACHINE_ARCH=powerpc show=CHOSEN_COMPILER |grep -B1 base-gcc
$
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2020-10-25, Christopher Zimmermann wrote:
> this makes the xenocara bitmap fonts available for pango apps like gvim,
> too.
That sets off my alarm bell.
We used to have the problem that Firefox would sometimes pick
piss-poor bitmap fonts, because they matched a font name specified
by a webs
[Picking this up again after a month:]
Our basename(3) and dirname(3) take a const argument:
char*basename(const char *);
char*dirname(const char *);
POSIX says otherwise...
char *basename(char *path);
char *dirname(char *path);
... and explicitly says the functions may modify
This decodes the UDF ("permanently undefined") instruction in ddb's
arm64 disassembler. The particular immediate16 format appears to
be unique to this instruction.
OK? Or don't bother?
Index: arch/arm64/arm64/disasm.c
===
RCS file:
Belatedly, ARM has taken a slice of the reserved opcode space and
assigned it as a properly defined illegal instruction, udf #imm16.
(Armv8 Architecture Reference Manual, edition F.c, section C6.2.335).
Clang already knows about it.
We really should use this instead of picking something ad-hoc out
Accommodate POSIX basename(3) that takes a non-const parameter and
may modify the string buffer.
There were only two compiler warnings about discarded const, but
there are numerous instances where the code assumes non-POSIX
semantics for basename() and dirname(). Given that there is at
least a Fr
Accommodate POSIX basename(3) that takes a non-const parameter and
may modify the string buffer.
I've tried to follow the conventions of the existing code.
ok?
Index: usr.bin/ftp/fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
Accommodate POSIX basename(3) that takes a non-const parameter and
may in fact modify the string buffer.
The file is built by vmd and vmctl.
I'm uncertain if we want a truncation check here. Both in vmd and
vmctl, the path has been validated by a previous open(), but given
the code complexity, d
1 - 100 of 589 matches
Mail list logo
