why are you moving the member?
it doesn't matter in this case, but generally it's better to have the bigger members first, concentrating in particular on equal size (and sizeof(QString) == sizeof(void*)).
all other things being equal, prefer no change to reduce the diff size.

space on wrong side of amp

you're removing that without replacement. that makes me think that the patch is still non-atomic.

put spaces around binary operators

using strncpy() after an explicit length check is relatively pointless (unless the trailing zero padding is important).
but the operation can be optimized by using memcpy().

you still need to address that *somehow* ;)

the correct length is pathSize + 1

I just feel like the job of SocketAddress should be to create the address structure and not perform any file operation. Removal of the socket file should be handled by file ioslave or FdReceiver.

that's a valid concern, but doing that belongs into a separate patch which does the complementary change (as far as necessary) atomically, and explains it properly in the commit message.

this actually constructs a qbytearray. that should be probably explicit.

a better approach would be moving the class' interface to qbytearray (or actually qstring) as well, to unify the API. but that's again a separate refactoring.

you're removing the auto-prefixing with /tmp/. if that is intentional, you need to atomically adjust the callers, as otherwise you're changing behavior.

i now noticed that you removed that branch, thus removing the use of linux' abstract address space. that also calls for a justification.
did you research the git history to find out why it was introduced in the first place?

you now have a buffer overflow on linux. you need to split the conditional.

The problem here is the API. Why is it using std::string in the first place?

The idea was to use std c++ and avoid qt throughout the class because the code will be executed with elevated privileges.

In that case I don't understand why SocketAddress takes a QByteArray and not a std::string.... Because ossi suggested it to unify the API and avoid one conversion to std::string in fdereceiver? But then we have two contradictory goals, we need to decide whether we use Qt or not in fdsender and therefore in SocketAddress. Since one is not supposed to use Qt API without a QCoreApplication instance, and since it's not recommented to run Qt code as root, I think your original idea made sense, no Qt in fdsender nor in SocketAddress.

i can get behind the idea of keeping SocketAddress and FdSender qt-free. it's ugly that FdReceiver stands out, but it would be way harder to make that one qt-free due to its use of the event loop.