Same as above: undefined behaviour per C23 §7.4.1.

In the meantime, .Lb libbsdconf results in unknown library name, so please take care of it contrib/mandoc/lib.in.

I haven't reviewed the rest yet, but I'll go through them shortly and submit my reviews as well. For bsdconf.c and sysconf.c, at least, I've noticed a few things I'd like to share my notes with you. I'll get back to the rest soon again.

This beautifully addresses everything. Thanks, Kevin! Happy to see this land.

The tri-state reads beautifully, and the link_was_published guard is a neat touch.

Just opened a pull request. I'd appreciate it if you could take a look. I've verified everything I'm currently aware of passes at the moment (including the previously missed contextual bool conversion.) The LLVM libc++ tests mentioned earlier by @aokblast have also passed successfully.

Sure thing.

The ((void)0) approach works but it drops the arity check and risks silent bugs. I did this for modes prior to C++20 mainly because I wasn’t sure if there were a better way. But for C++20 and later I still believe we can craft a solid solution. I’m not available today and will likely continue tomorrow, so I’d appreciate it if you could allow me a day or two. I do my best to deliver ASAP. In the meantime, please accept my apologies for any inconvenience.

Landed: https://cgit.freebsd.org/ports/commit/?id=222d74a808b45b34716e47806ca7e4815d9cc371

Thank you so much, sir. I did not know that. I make sure to keep it in mind for future contributions. I didn't have a dedicated server for my tests; I usually used to fire up an instance and remove it right after my tests. But I will take care of it shortly, roger that.

@bofh: could you take another look, please? Let me know if there's anything I can/should improve.

This revision is landed: https://cgit.freebsd.org/ports/commit/?id=1f860c44bcb318517910740f83cc9b5dbe5c2a3c

All right, I'll keep it in mind for my next ports. Many thanks to both of you.

@fernape: Sorry, I didn't know I must take care of all architecture. Could you please guide me on how to ensure it can build fine on 12.3 i386? And if the upstream has no official release for an architecture, should I specify that architecture in the Makefile or is there any specific process to see if we can make it work? And one more question, should I only care about tier 1 platforms of the supported RELEASE versions or do we have another rule? And my sincere apologies for the oversight.

The PLIST_FILES have grown big enough that it should be moved to a separate pkg-plist file now

• editors/texworks: Move PLIST_FILES to pkg-plist

@bofh: It happens ;-D But one question, is there anything I should really change in this revision or the request is unintentionally opened?

@koobs: I tried it with LIB_DEPENDS, and it passed the tests. So yes, it works fine that way, but it wasn't impossible to specify the version. Therefore I just fixed the typo in SYNCTEX_RUN_DEPENDS.

• graphics/zathura: Fix typo in SYNCTEX_RUN_DEPENDS

• editors/texworks: Update to 0.6.7

Closed in order to continue with D34851 for the next version.

@bofh: Perfect! Sorry that I didn't notice the update. All right, so I close this revision, thanks.

In D34816#789483, @koobs wrote:

I don't understand the why/description in commit log message.

Are the patches 'no longer required' ?

• devel/vipack: Update the patch file

• devel/vipack: Update to v0.9.1, include LICENSE_FILE, use devel/git, and improve the pkg-descr

Oh, right! Thank you so much.

• www/vultr-cli: Remove spaces from the beginning of lines in pkg-descr

• sysutils/dust: Fix typo in pkg-descr

I have a few questions from Rust porters, by the way, so I can do better next time: