alanc: That reminds me of the 30 year old bug in FreeBSD's ctags I found the other day.

Due to a missing break statement, -v implies -x, but it is not documented in the man page: github.com/freebsd/freebsd-src/blob/main/usr.bin/ctags/ctags.c#L132

In this case, the error command still has code to avoid llib-port, which was a variant of llib-libc used to "check portability to the IBM and GCOS dialects of C."

so it appears github.com/illumos/illumos-gate/blo…/sgs/error/common/error.h#L165-L172 lived ~40 years longer than github.com/dspinellis/unix-history-…t-Development/usr/old/lib/llib-port did

I've not kept track of how many 30-year-old bugs I've found in X11

These days, I am starting to find 15 to 20 year old bugs in ZFS from doing static analysis.

Speaking of which, why are there no Xorg server scans on coverity when I search for them?

ryao: I don't know if Coverity currently scans it as part of their public FOSS scans - they did long ago (back when I found blogs.oracle.com/solaris/post/security-hole-in-xorg-6970 with it), but we broke their setup when we converted from imake to automake and I don't think they ever repaired that

but Red Hat has been fixing bugs in X they found with Coverity, so it must be running somewhere, just may be on their side, not Coverity's

alanc: Coverity lets individual projects register and run scans. They do not do scans on projects' behalfs anymore as far as I know.

Since it is not in the public scans, I assume that Redhat is doing private scans.

That being said, OpenZFS was doing Coverity scans for many years, but there were a few hundred outstanding reports that were not properly triaged until I started handling things last year. Now we are down to 39 outstanding reports: scan.coverity.com/projects/openzfs-zfs

I would be suspicious of whether Redhat is actually handling all reports or if they are doing what OpenZFS used to do until I volunteered to take over handling of Coverity scans.

Not that I am opposed to help, but help comes so rarely.

There was a slow drip of about ~10 patches per year for a while until I started aggressively reviewing the reports. Of course, finding a volunteer to do this requires that there be reports to read in the first place.

OpenZFS has probably had over 100 patches in the past 6 months from my review of static analyzer reports.

Many of the patches are to silence bad reports, but they found a few serious things too.

is it possible debug 32bit app by mdb64bit ? right now we need mdb32bit

igork mdb is started via isaexec - so you get 64bit version up, but I think it will switch to 32-bit for 32-bit targets. I may be wrong, however;)

i just want remove 32bit mdb and use 64bit only, but it failed with debug 32bit apps

Well, then you're not going to be able to debug 32-bit apps.

But it sounds like you've deleted all the 32-bit binaries anyway, so I assume that will be fine!

I fell into that trap in Tribblix, deleting all the 32-bit isaexec'ed binaries wholesale, and having to put mdb back

ptribble: if you've done those properly, care to upstream them?

Oh, that's not done properly, this is postprocessing during conversion to SVR4 packages

Although it would be easier for me if it were done properly

I just haven't had the time, on my side of things.

I've done it "eh"

if you have time before I do, I'd appreciate it though

[illumos-gate] 15469 Spelling mistakes in the manual -- Peter Tribble <peter.tribble⊙gc>