Re: [systemd-devel] Completion of error handling

2015-07-28 Thread SF Markus Elfring
 I have no understanding of Coccinelle. I do not understand what you
 are saying.

The application of a few scripts in the semantic patch language
can occasionally help to improve some software, can't it?
Now I'll try again to present more detailed source code analysis results
according to specific software metrics.

I assumed that each source file (*.c) provides only functions which
unique names.

╔╤╗
║│║
║│   incidents║
║ overview   │   │║
║│ total │ ≠ 0║
║│   │ ≠ NULL ║
╟┼───┼╢
║│   │║
║ non-empty  │   │║
║ return │ 20633 │ 15477  ║
║ statements │   │║
║│   │║
╟┼───┼╢
║│   │║
║ non-void   │  5990 │  5183  ║
║ functions  │   │║
║│   │║
╚╧═══╧╝


Does such a table indicate that there are some function implementations
left over which will provide only the return value zero (or NULL)?

A few specific examples:
* client_timeout_resend_expire
* config_parse_memory_limit
* transfer_on_log
* udev_rules_unref
* writer_free


Is this information worth for further considerations?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-27 Thread Lennart Poettering
On Sat, 25.07.15 08:11, SF Markus Elfring (elfr...@users.sourceforge.net) wrote:

I am sorry Markus, but at this point you are just wasting our time. Be
specific (i.e. by sending git patches, providing backtraces of
crashes, or actual bug reports), otherwise this is of no help. I will
now stop responding to your mails, unless you get more specific.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-26 Thread SF Markus Elfring
 No, nothing needs more discussion or attention in the context of systemd.

I disagree here. - I would appreciate if return value ignorance can be still
reduced at more source code places.

Do you distinguish any update candidates which belong to a subsystem
in this software?


 None of the above seems contain anything useful or is expected to
 contribute anything useful in the future.

More time will pass by until the adoption of higher level tools might increase.

Changes can be introduced by file formats which need some manual work.
Would it be nice if a software evolution pattern should only be specified once
and can be applied to a wide range of source files then automatically?


 This is a development mailing list, we discuss patches and actual code,
 and not vague questions like you ask.

Do any updates need a bit of consensus before big efforts will be invested.

Will any software developer (besides me) become interested to integrate
a patch in the format of an AspectC++ file or a SmPL script for example?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-25 Thread Kay Sievers
On Sat, Jul 25, 2015 at 8:11 AM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
 We accept contributions only in git-format-patch frmatted patches,
 best via github PRs.

 The higher level patch formats I'm trying to make you aware of will also
 result in file changes which can be integrated by this content management
 interface depending on your general acceptance for corresponding
 software evolution.

 Examples:
 * Scripts in the semantic patch language can be processed for occasional
   patch generation by the Coccinelle software.
   http://coccinelle.lip6.fr/papers.php

 * Aspect files could be transformed during an enhanced build process
   by the AspectC++ software.
   http://aspectc.org/Publications.php


 Would you like to give thoughts for the extension of the software 
 development
 toolbox a chance?

 I am sorry, your questions are not useful, because too generic.

 I hope that the software situation can also be improved by development 
 methodology
 and technology you are more familiar with at the moment.
 Would you like to reopen a specific bug report for example?

No, systemd does not plan to do anything here.

 https://github.com/systemd/systemd/issues/644

 Update candidates:
 * How do you think about to look at calls for functions from the application
   programming interface POSIX threads again?

 * Does the usage of file output functions need another look?

No, nothing needs more discussion or attention in the context of systemd.

None of the above seems contain anything useful or is expected to
contribute anything useful in the future. This is a development
mailing list, we discuss patches and actual code, and not vague
questions like you ask. Please stop posting this stuff or asking any
more questions like this.

Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-25 Thread SF Markus Elfring
 We accept contributions only in git-format-patch frmatted patches,
 best via github PRs.

The higher level patch formats I'm trying to make you aware of will also
result in file changes which can be integrated by this content management
interface depending on your general acceptance for corresponding
software evolution.

Examples:
* Scripts in the semantic patch language can be processed for occasional
  patch generation by the Coccinelle software.
  http://coccinelle.lip6.fr/papers.php

* Aspect files could be transformed during an enhanced build process
  by the AspectC++ software.
  http://aspectc.org/Publications.php


 Would you like to give thoughts for the extension of the software development
 toolbox a chance?
 
 I am sorry, your questions are not useful, because too generic.

I hope that the software situation can also be improved by development 
methodology
and technology you are more familiar with at the moment.
Would you like to reopen a specific bug report for example?
https://github.com/systemd/systemd/issues/644

Update candidates:
* How do you think about to look at calls for functions from the application
  programming interface POSIX threads again?

* Does the usage of file output functions need another look?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-24 Thread Lennart Poettering
On Fri, 24.07.15 15:10, SF Markus Elfring (elfr...@users.sourceforge.net) wrote:

 An analysis script can point more source code places out for
 further considerations.
 Would you like to care for corresponding open issues?

We are making heavy use of Coverity already on a daily basis, I think
we are all good there.

  I wonder also about the status of some function implementations
  which return zero (or NULL) but no other value.
  
  So, what precisely are you wondering about?
 
 How do you think about to look at places once more which can be found
 with a small script like the following with the help of the semantic
 patch language (and the Coccinelle software)?

I have no understanding of Coccinelle. I do not understand what you
are saying.

 I contributed a bit to free software. I assume that you might find a few
 of these improvements a bit useful, don't you?

Generally, please be specific, provide patches. We are much more
interested in actual technical contribution, much less in just talking
about stuff.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-24 Thread SF Markus Elfring
 I have no understanding of Coccinelle.

This software provides the tool spatch which lets you specify transformations
for C source code in a similar way you are used to already by the reuse
of unified context diffs.
http://coccinelle.lip6.fr/

I assume that you have eventually noticed specific updates on Linux source files
which were automatically generated by this technology.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/coccinelle.txt?id=refs/tags/v4.1.3


 I do not understand what you are saying.

How do you think about to try the shown small source code analysis script out
so that you can see from a generated patch directly where another look
might be useful?


 Generally, please be specific, provide patches.

I suggest to consider additional patch formats as a better preparation
for software improvements.

The Coccinelle software concentrates on the support for collateral evolutions.
A specific update suggestion can be written as a diff script.
Each diff targets only a concrete kind of software evolution.

But there are methodologies evolving which support the encapsulation
of cross-cutting concerns directly.
Such known concerns are for example:
* Logging
* Error detection and corresponding exception handling

Would further considerations be acceptable around a tool like AspectC++?
http://aspectc.org/


 We are much more interested in actual technical contribution,
 much less in just talking about stuff.

I propose to integrate higher level algorithms and procedures into
the software build process so that some manual software maintenance tasks
can be reduced.
Would you like to give thoughts for the extension of the software development
toolbox a chance?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-24 Thread Lennart Poettering
On Fri, 24.07.15 18:15, SF Markus Elfring (elfr...@users.sourceforge.net) wrote:

  Generally, please be specific, provide patches.
 
 I suggest to consider additional patch formats as a better preparation
 for software improvements.

We accept contributions only in git-format-patch frmatted patches,
best via github PRs.

If you have a patch in another format, please convert it into
git-format-patch format, and file a PR.

 I propose to integrate higher level algorithms and procedures into
 the software build process so that some manual software maintenance tasks
 can be reduced.
 Would you like to give thoughts for the extension of the software development
 toolbox a chance?

I am sorry, your questions are not useful, because too generic. Send
specific patches, be explicit. Otherwise this is not useful to us,

sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Completion of error handling

2015-07-23 Thread Lennart Poettering
On Thu, 23.07.15 08:55, SF Markus Elfring (elfr...@users.sourceforge.net) wrote:

Heya,

 I would like to continue the clarification of open issues
 around a topic like Completion of error handling.
 https://github.com/systemd/systemd/issues/644
 
 I hope that the amount of unchecked return values can be reduced
 further in affected source files by the reuse of dedicated
 software development tools.
 Which source code analysis approaches would you like to reconsider
 once more?

We are regularly checking the systemd sources with coverity and the
llvm/clang analyzer.

 I wonder also about the status of some function implementations
 which return zero (or NULL) but no other value.

So, what precisely are you wondering about?

Also, on github, you keep posting stuff that looks like you are a
bot. To prove you are not a bot, can you please tell me what five
times 15 is?

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Completion of error handling

2015-07-23 Thread SF Markus Elfring
Hello,

I would like to continue the clarification of open issues
around a topic like Completion of error handling.
https://github.com/systemd/systemd/issues/644

I hope that the amount of unchecked return values can be reduced
further in affected source files by the reuse of dedicated
software development tools.
Which source code analysis approaches would you like to reconsider
once more?


I wonder also about the status of some function implementations
which return zero (or NULL) but no other value.
Are you interested to clarify corresponding details a bit more?

Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel