[ClusterLabs] Antw: Re: Antw: Re: No Cluster fun (split brain)

[Ulrich Windl]

>>> Jan Friesse <jfriesse at redhat.com> schrieb am 20.05.2015 um 13:24 in
Nachricht
<555C6F01.4000904 at redhat.com>:
> Ulrich,
> 
> Ulrich Windl napsal(a):
>>>>> Jan Pokorný<jpokorny at redhat.com> schrieb am 19.05.2015 um 20:38 in
>> Nachricht
>> <20150519183855.GK7411 at redhat.com>:
>>> On 19/05/15 17:50 +0200, Ulrich Windl wrote:
>>>> Now if the corosync guys would add comments to their C-code or at
>>>> least would respond to inquiried to their advertised mailing list...
>>>
>>> As I haven't found any posting of yours in dedicated corosync ML,
>>> I suppose you are already referring to this very one per
>>> "the advertisement":
>> 
>> I only found the "discuss" mailing list, and I tried to subscribe, but
never
>> got anything since then. I also think I send a message to "discuss" a few 
> days
>> after subscribing, but still I got back nothing...
> 
> That's weird. There is really no mail from you on ML (even not in
> pending for approval). Also you are really not in membership list.

I found I had sent a message at " 15.05.2015 um 10:56 (MESZ)" to the list
anyway.

> 
> So I've just tried (successfully) subscribe coro ML. Manual: Go to
> http://lists.corosync.org/mailman/listinfo/discuss, put your email
> address to "Your email address:" field, click subscribe. You should get
> email from discuss-request at corosync.org with subject "confirm
> [0-9[a-f]*". Then just click on the link in the email and you should be
> subscribed. If email doesn't arrived to you, please check your spam
> folder or your mail server log if message was not trowed.
> 
> Also you've wrote directly to me and I've replied you giving you two
> options where to send patches. ML or github pull (so use this option if
> ML doesn't work for you).

OK, some recent desaster prevented me to do any of the work I wanted to...

> 
>> 
>>> http://lists.corosync.org/pipermail/discuss/2015-February/003464.html 
>>>
>>> FWIW, adding comments to the code after-the-fact is something highly
>>> unlikely unless you want to take a part in that.  You have the
>> 
>> Guessing from the code of a routine what the routine is probably meant to
do
>> is close to impossible, like guessing what the return codes try to say.
>> 
>> To give others an impression how the typical code looks like, I pick a 
> random
>> routine from exec/coroparse.c (There really are no comments before that
>> routine):
>> ---snip---
>> static char *strchr_rs (const char *haystack, int byte)
>> {
>>         const char *end_address = strchr (haystack, byte);
>>         if (end_address) {
>>                 end_address += 1; /* skip past { or = */
>>                 end_address += strspn (end_address, " \t");
>>         }
>> 
>>         return ((char *) end_address);
>> }
>> ---
>> 
> 
> I strongly believe somebody who knows what strchr does is able to find
> out quite quickly what strchr_rs does.

You completely miss the idea of "procedural abstraction": If routines
(procedures and functions) are to used as building blocks (black boxes) by
anybody else rather than the original author (maybe it's even true for the
author after a year or two), these routines should have a description of what
they are supposed to do.
Note: "supposed to do", not "do": If the implemenatation is wrong, you'll
never find out otherwise.

So "strchr_rs()" is described with the following comment:
/* Cast signed int `byte' to a char to find that character in string
`haystack'; if found add one to the address where `byte' was found  and then
adds the number of spaces and TAB characters found at that address before it is
returned. If `bytes' was not found return NULL */

So you can see that the description is longer than the actual code, not
meaning that the comment is bad, but probably the code is. Also the comment
inside "/* skip past { or = */" is nonsense, because any character is skipped.

OK, just an example...