In D9849#203598, @mat wrote:

When there are a few trivial fixes to be done, I say so, and I approve the review, so that you can commit it with the few changes I pointed out without having to restart the review process.

Is it okay?
Ready to commit from your points of view?

Fix two points that @mat told :)

Fix some portlint warnings

At first, Thanks for your great work __/|\__
Technically I'm not right person to talk deeply about this.
But for helping to reduce amount of works for next reviewer (and also for you ;D),
Some style(9) points:
use the form:

type
name()
{
}

instead of

type
name() {
}

Thanks :-)

As I pointed before, seems fine for me (From MySQL points of view).
except that MY_DBDIR part ;-)

In D9427#195667, @lifanov wrote:

They don't really share code. They come from different tarballs, etc.
One is a shared library that gets loaded into the other but both have independent releases and updates.

In D9427#195662, @lifanov wrote:

The WSREP patch enables pluggable replication engine replacements. Galera is one implementation of such an engine.
After this lands, the next step is to update databases/galera to the latest.

Maybe it's a bit late to say, but, anyone checked databases/galera ?
Isn't it related to our work?

Okay, seems fine for me.
Thanks.

Okay, For me only 2 points left.
1- My comments on rc-script and cmake.
2- CONFLICTS part (which needs the naming before it)
The rest seems okay for me.

In D9427#194754, @matthew wrote:

This looks to duplicate a lot of the mysql56-server port. Should it be a slave port of that one?

In D9199#194109, @lifanov wrote:

Looks good to me! I'm waiting for Matthew to take a look.

Okay, Looks good to me.
Thanks :-)

I already worked on a patch and tested it,
Would you please check it too?

As i pointed before, I agree with changing return statement too (that's why i updated old D7224)
So all are sensible IMO 😄.

I don't have permission to update diff on revision to do this (if you're agree with changing return statement), so i updated D7224 😁😅 to keep a reference for last changes.

Well, I think second one (returning -1 and setting errno) is more compatible with what most of FreeBSD libc is coded than current one.
I guess it'd be better if we change the current one [noting that return value is not checked]

In D7427#154518, @kib wrote:

In D7427#154514, @mokhi64_gmail.com wrote:

I used ENOMEM value as a convention i respected always when i code, i have no insist on it as the return value is not being checked.

This is not the question. ENOMEM is the reasonable error to return in this case, but there are more than one way to return an error. The question was about the later and not about the former.

In D7427#154489, @kib wrote:

I still have one question about the patch.

The __cxa_thread_atexit() signature specifies int as the return value. You return errno as error indicator, similar to the modern POSIX conventions, while typical unix tradition is to return -1 and set errno. Glibs never returns an error, in similar situation of failed malloc() it segfaults. Judging from the code generated by clang, the error returned is ignored.

Is there a spec for __cxa_thread_atexit() anywhere ? Is it allowed to return an error, and if yes, in which way (POSIX/Unix) must it be done ?

Thanks for cleaning up code using cb_walk() idea.

Thanks @brnrd ;)

In D6087#129620, @kib wrote:

In D6087#129603, @mokhi64_gmail.com wrote:

In D6087#129590, @cem wrote:

This seems wrong to me. TAILQ_INSERT_TAIL should do the right thing on empty lists.

I personally expected that from TAILQ_INSERT_TAIL, but as far as i followed it, it's doing *(head)->tqh_last = (elm);
which assumes tqh_last != NULL without no clear reason.

tqh_last is not NULL for initialized tailq.

Maybe we should do something for TAILQ_INSERT_TAIL, but till then this seems fixes it.

In D6087#129593, @kib wrote:

In D6087#129590, @cem wrote:

This seems wrong to me. TAILQ_INSERT_TAIL should do the right thing on empty lists. If it doesn't already, that's where the fix should go, I think.

TAILQ_INSERT_TAIL handles empty queues just fine.

If the fault is real, the debugging data, i.e. at least the backtrace (from libthr compiled with -g) and dump of the curthread content are due.

In D6087#129593, @kib wrote:

In D6087#129590, @cem wrote:

This seems wrong to me. TAILQ_INSERT_TAIL should do the right thing on empty lists. If it doesn't already, that's where the fix should go, I think.

TAILQ_INSERT_TAIL handles empty queues just fine.

If the fault is real, the debugging data, i.e. at least the backtrace (from libthr compiled with -g) and dump of the curthread content are due.

In D6087#129590, @cem wrote:

This seems wrong to me. TAILQ_INSERT_TAIL should do the right thing on empty lists.

Correcting castings and their warnings (as expected to be).

Style (9) related issues (mixing declarations and initialization) fixed.

Sorry for delay in doing "$cond != 0"
I didn't see your comments in my mail_box.
BTW, Done as you told :)

Updating D5132: Handle security concerns in sys/dev about out of bound and initilized stack vars

Updating D4980: Avoid C++ namespace pollution from POSIX headers

related Bugzilla issues:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206755
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206754

Updating D5095: Fixing kbd.c bug 'OGIO_KEYMAP command does not restore priority level'

related bugzilla issue:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206678

i don't know how to close it.
please close it, when you saw it.

It's worng reveision, opened by my fault, sorry :(

Updating D4980: Avoid C++ namespace pollution from POSIX headers

Updating D4980: Avoid C++ namespace pollution from POSIX headers

AFAIK, turning these macro-wrappers into functions, makes CC resolve symbols in compile/link-time.

Organizing comments about __fileno_mt() inside stdio.h and fileno.c
After fixing infinite loop.

Updating D4980: Avoid C++ namespace pollution from POSIX headers

Updating D4980: Avoid C++ namespace pollution from POSIX headers

Updating D4980: Avoid C++ namespace pollution from POSIX headers