Mailinglist Archive: yast-devel (31 mails)

< Previous Next >
Re: [yast-devel] Again: 98% of "undefined method" errors have nothing to do with static typing
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Wed, 13 Dec 2017 11:11:41 +0100
  • Message-id: <20171213111141.7d97c5bc@linux-vvcf.privatesite>
V Wed, 13 Dec 2017 10:54:48 +0100
Jiri Srain <jsrain@xxxxxxx> napsáno:

On 13.12.2017 10:35, Josef Reidinger wrote:
V Wed, 13 Dec 2017 10:31:32 +0100
Arvin Schnell <aschnell@xxxxxxxx> napsáno:

On Wed, Dec 13, 2017 at 10:14:42AM +0100, Josef Reidinger wrote:
V Wed, 13 Dec 2017 09:47:13 +0100
Arvin Schnell <aschnell@xxxxxxxx> napsáno:

On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa
This is probably the less useful mail ever, since it just goes
over a topic that has been explained over and over and still
pops us in almost every single meeting.

Let me say it again: 98% of the "undefined method `xxx' for
nil:NilClass" errors are NOT related AT ALL to Ruby being
dynamically typed and would NOT be prevented by the usage of a
statically typed language.

I think you are mixing static typing and static code analysis.

ciao Arvin

Well, it is a bit related as static code analysis strength is
related to rigidness of language. And actually even c++ have quite
weak static code analysis.

Not only the compiler can do static code analysis. Other tools do
much more, e.g. coverity.

ciao Arvin

How does coverity or other handle pointers in C++? I think it is
similar kind of issue as ruby have for static analysis. Any pointer
can be NULL or invalid address and similar in ruby anything can be
nil. I know that mvidner trying rubylint and it was quite tricky.
So if coverity can deal with such issue, we can check how it is
done and can check is someone try similar approach for ruby and it
can really helps us.

In C++, you can follow the approach which Michael did when developing
libzypp: Only use plain pointers for the minimum time needed to
convert them to various kinds of smart pointers which the boost
library offered. This policy somehow mitigated the problem with


In fact it does not help always. E.g. now with libstorage-ng is there
autoptr, but still we get segfaults when device graph is changed as
these autoptr is set to NULL and create segfaults. So as long as
program can have object that is no longer valid, you have problem to
statically detect it as it means you have to understand code flow to
decide if object is valid or not, which is really hard task for
analyzer. As long as all objects are valid for its whole lifetime and
no-one holds it after it is not valid it helps. BTW libzypp use quite
heavily Null object pattern exactly to not return nil and instead this
null object.

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups