Fixes

[socketpair]

Please review my fixes.

1. One of the most dubious is "ROUTE_DIFF result was not used in some place in route_compare". I don't know what author mean, but this is difinitely the bug.
2. nl_recv() refactored. Please review.

[socketpair]

I thought that nf-log and ULOG are synonims. Why? because ULOG uses constant named NETLINK_NFLOG. But ULOG is deprecated in favour NF-LOG, which you already have implemented. My system still use ugly ULOG.

[socketpair]

I have done refactoring of my changes. Please check.

The last thing is to refine situation with this comment:

This changes the behavior of this function which is not acceptable. Code may exist which relies on the
NL_SOCK_PASSCRED flag to trigger the receiving of creds. We want the flag to trigger the receiving and
the result pointer to trigger returning it to the caller.

The caller may always provide a result pointer but may want to fine control receiving of creds with the flag.

The state before my changes and after described in this table:

| NL_SOCK_PASSCRED  | creds |  credentials requested? | pointer filled ?  |
|                   |       |   BEFORE   |    AFTER   |  BEFORE |  AFTER  | 
+-------------------+-------+----------------------------------------------    
|     FALSE         | NULL  |     NO     |     NO     |    NO   |   NO    |
|     FALSE         |   *   |     NO     |     NO     |    NO(!)| AS NULL |
|     TRUE          | NULL  |     YES(!) |     NO     |    NO   |   NO    |
|     TRUE          |   *   |     YES    |     YES    |   YES   |   YES   |

The exclamation mark mean wrong behaviour by my opinion. I undestand, that in theory, flags should be independent. But in practice (IMHO), some cases looks bad. So

1. receiving credentials and not passing them to caller may gain security problems/fd leak.
2. If caller pass creds, but forgot to set flag, caller may start (by his mistake) to use data at that pointer.
3. If caller want to control receiving of creds, why not to require to pass NULL as creds if NL_SOCK_PASSCRED is OFF. If this breaks some existing programs, I consider this is due to bug in library. Suppose piece of code in such program:

struct ucred * creds;
nl_recv(..., &creds);
if ( sock & NL_SOCK_PASSCRED)
    handle_creds();

In my opinion, it should be changed to this:

struct ucred * creds;
nl_recv(..., sock & NL_SOCK_PASSCRED ? &creds:NULL);
if ( sock & NL_SOCK_PASSCRED)
    handle_creds();

What you think about new behaviour?

My opinion, that either such beaviour should be documented, or error code returned in middle-cases of that table.

[tgraf]

I think the new creds behaviour is fine. I regard the code example you outline as a possible regression source as unlikely and consider it a bug in the application. If creds is set but the flag is not, creds shall not be requested.

[socketpair]

As you think, should middle-cases of the table generate error code (instead of my behaviour)? It is minor question, but library should be clear against this.

[tgraf]

I merged the branch that was mentioned in the email. I don't want to rebase my tree as that would force everyone to re-clone their trees. Please submit a new patches for anything that was merged incorrectly.