DevIo Bug

[vbs]

Ich hoffe, es zählt als offizielle Quelle, aber das Wiki (https://wiki.fhem.de/wiki/DevIo) sagt eindeutig:
"$callback: Der Name (als Zeichenkette) oder die Referenz auf eine Modulfunktion, welche aufgerufen werden soll um evtl. Fehlermeldunge..."

Die Variante mit String wird sogar als erstes erwähnt. Aber wie gesagt: ich mache alles mit, wenn ihr mir sagt, dass das nicht mehr so sein soll.

[rudolfkoenig]

@vbs: Ich habe z.Zt. noch keine ueberzeugende/ausrechende Argumente (und damit auch keine Plaene), um strings / Funktionsnamen zu untersagen.
An bestimmten Stellen, wie InternalTimer waere das kontraproduktiv, weil man damit DiagnoseFunktionen wie fhemdebug timerList sinnlos werden.
Man koennte evtl. die Funktionalitaet von timerList auch ohne funktionsNamen implementieren, ich sehe aber keine Vorteile, nur den Aufwand.

@CoolTux: eine CodeReferenz wird nicht "erwartet", nur use strict besteht darauf. Es wird irgendetwas erwartet, was man als Funktion aufrufen kann.

[CoolTux]

Danke Rudi für die Info.

[noansi]

Hallo Rudolf,

in DevIoTS habe ich die Änderungen auch mal alle eingepflegt, da mangels Funktionsnutzung $anser auch rein geflutscht war. Nebenbei ist mir darüber fhemFork mit den DevIo_CloseDev aufgefallen, was ich auch gleich mit berücksichtigt habe.

An bestimmten Stellen, wie InternalTimer waere das kontraproduktiv, weil man damit DiagnoseFunktionen wie fhemdebug timerList sinnlos werden.
Man koennte evtl. die Funktionalitaet von timerList auch ohne funktionsNamen implementieren, ich sehe aber keine Vorteile, nur den Aufwand.

Hier mal ein Vorschlag für fhemdebug_timerList (der auch 97_timerTS.pm berücksichtigt  ), da auch bei Timern Funktionsreferenzen statt Funktionsnamen möglich sind (und ich es auch so nutze) und es schön ist, deren Namen zu sehen:

Code Auswählen Erweitern

sub
fhemdebug_timerList($)
{
  my ($param) = @_;
  my @res;

  my $tt;
  my $cv;
  my $tfnm;
  for my $h (@intAtA) {
    $tt = $h->{TRIGGERTIME};
    if (ref($h->{FN}) ne "") {
      $cv = svref_2object($h->{FN});
      $tfnm = $cv->GV->NAME; # get function name
    }
    else {
      $tfnm = $h->{FN}; # just function string/name
    }
    push(@res, sprintf("%s.%05d %s%s",
      FmtDateTime($tt), int(($tt-int($tt))*100000), $tfnm,
      $h->{STACKTRACE} ? $h->{STACKTRACE} : ""));
  }
  if (defined(@intAtTS)) { # for 97_timerTS.pm
    for my $h (@intAtTS) {
      $tt = $h->{TRIGGERTIME};
      if (ref($h->{FN}) ne "") {
        $cv = svref_2object($h->{FN});
        $tfnm = $cv->GV->NAME; # get function name
      }
      else {
        $tfnm = $h->{FN}; # just function string/name
      }
      push(@res, sprintf("%s.%05d %s%s",
        FmtDateTime($tt), int(($tt-int($tt))*100000), $tfnm,
        $h->{STACKTRACE} ? $h->{STACKTRACE} : ""));
    }
  }
  return join("\n", @res);
}


Perl Internals Kenner könnten die Performance Unterschiede zwischen Funktionsnamen und Funktionsreferenzen aufzeichnen.

Gruß, Ansgar.

[rudolfkoenig]

Dane fuer den Hinweis, ich habe timerList mit svref_2object erweitert.

[RichardCZ]

@vbs: Ich habe z.Zt. noch keine ueberzeugende/ausrechende Argumente (und damit auch keine Plaene), um strings / Funktionsnamen zu untersagen.

Wobei sich die Frage stellt ob die Argumente objektiv nicht überzeugend waren, oder Du sie nur nicht als solche erkannt hast.
Insbesondere wenn sie von "Unfehlbaren" kommen. Pffff. Nicht mit uns.

Das Schlüsselwort lautet Symbolic Reference

PBP Seite 230 - 231 "Never use symbolic references"  (*)

Das ist eine ziemlich nicht-relativierende Aussage.

Häte man die Fahrradkette

$hash->{DefFn}    = \&Meinetwegen_Define;

statt

$hash->{DefFn}    = "Meinetwegen_Define";

genommen, dann hätte man auch nicht diesen ganzen Sotter mit no warnings 'refs';

Überdies hoffe ich, dass in der Diskussion nicht der Anfang vergessen wird: dass nämlich der fehlende "use strict" einen ziemlichen Hammer-Bug kaschiert hat. Jahrelang?



(*) Ich danke aber für die Gelegenheit mir diese 2 Seiten nun nochmal durchgelesen haben zu können und wünsche jedem genug Englischverständnis um Conways Seitenhiebe zu erfassen.

[noansi]

Hallo Richard,

nämlich der fehlende "use strict" einen ziemlichen Hammer-Bug kaschiert hat. Jahrelang?

$anser: Nein, Monatelang. Seit Mai 2019. Aber auch das spricht für "use strict" im regulären Code.
$r == "": existierte etwa 5 1/2 Jahre lang.

Rudolf hat das auch (in diesem Fall zu schnell) eingesehen, denn es steht ja nun im Code drin, mit eben den anderen Fixes und notwendigen Ausnahmen, um es kompatibel zu halten (weil und obwohl es wegen des überhasteten "use strict" über alles richtig gerummst hat).

Aus meiner Sicht mehr zu kritisieren, ist die Existenz/Notwendigkeit der Funktion "DevIo_TimeoutRead" an sich.
Denn dieses busy-waiting auf irgendwas vom Device ist Gift für die Koexistenz mit anderen Instanzen von Modulen.
Für den timeout müsste mindestens eine (scharfe) Begrenzung rein, damit nutzende Modulentwickler gezwungen werden, sich was besseres, als die Nutzung dieser Funktion auszudenken, wenn eine Antwort vom Device länger als ein paar wenige ms dauern kann.
So gesehen sind solche fies versteckten Bugs in solchen unliebsamen Funktionen sogar positiv, denn der geneigte Nutzer wird vielleicht doch direkt einen besseren Pfad suchen, statt die Bugs in der Funktion zu suchen und zu beheben. 

Nicht umsonst sind Module (eher Debugging Hilfen), wie 98_apptime.pm und 98_freezemon.pm mal entstanden, um u.a. busy-waiting Probleme mit anderen Modulen aufzudecken.
Und bei apptime lag der Fokus darauf, die Ungenauigkeiten und Rechenzeiten von FHEM Timern sichtbar zu machen und nicht darauf, einfach und narrensicher nutzbar zu sein.
Und apptime klinkt sich, mangels anderer Möglichkeiten, "schmutzig" aber pragmatisch durch Überschreiben von FHEM Systemfunktionen ins System ein, was eine Deiner Fragen eventuell beantwortet.

Vielen Dank für so manchen erklärenden Hinweis zu Perl. Das weckt Erinnerungen an viele Stunden des Grübelns über unerklärliches Verhalten von Perl Code. Und da kommen sicher noch einige hinzu, denn manchmal kann man gar nicht so krumm denken, wie Perl teilweise gestrickt ist.

Kannst Du eventuell was zu "Perl Internals Kenner könnten die Performance Unterschiede zwischen Funktionsnamen und Funktionsreferenzen aufzeichnen" beitragen?
Ich suche auch gerne (am liebsten technisch und nicht nur empirisch begründete) Mikrosekunden aber auch gerne Speicherplatz für das Eichhörnchen.

Gruß, Ansgar.

[KernSani]

Und apptime klinkt sich, mangels anderer Möglichkeiten, "schmutzig" aber pragmatisch durch Überschreiben von FHEM Systemfunktionen ins System ein

Freezemon ist genauso schmutzig nur noch extensiver :-D


Gesendet von iPhone mit Tapatalk

[noansi]

Hallo Richard,

ok, ich weiß, es gehört nicht ganz hierher, aber hier habe ich Schreibrechte.

Du wendest hier https://forum.fhem.de/index.php/topic,109584.msg1039610.html#msg1039610 kompromisslos  return undef; -> return;  an, getreu PBP.

Wie prüfst Du automatisiert den Kontext in der Funktionsnutzung über den gesamten FHEM Code, um nicht auf so was https://perlmaven.com/how-to-return-undef-from-a-function unter "When implicit return breaks our code" reinzufallen?
Nicht, dass ich ein konkretes Beispiel in den FHEM Modulen wüßte, wo das zum tragen kommt. Aber genau diese Unsicherheit ist bedenkenswert, zumal noch wesentlich schwerer zu diagnostizierende Fehler rauskommen könnten, wie in diesem Thread?

Gruß, Ansgar.

[volschin]

Da ich im Developer Forum keine Schreibrechte habe, aber beruflich IT-Projekte mache, möchte ich hier mal sagen, dass ich es wohltuend finde, dass solche Diskussionen zur Codequalität, Sicherheit und entsprechende Maßnahmen jetzt endlich mal wahrnehmbar vorangetrieben werden. Die Denkweise, Hauptsache die Funktionalität ist für den User da, ist in den Zeiten von Angriffen über vernetzte Systeme nun mal leider von vorgestern. Fast jeder von uns nutzt irgendwo in seiner Installation einen Service aus dem Internet, der Daten bereitstellt oder auch mehr.

Danke und bitte nicht nachlassen. 

[rudolfkoenig]

Bitte keine Nebelkerzen: keiner wird wegen "no strict ref" oder perl WARNING Zugriff auf eine FHEM Installation kriegen, und Sicherheitsprobleme wurden auch bisher nicht mit hoher Prioritaet behandelt.

[volschin]

Da hofft man was Nettes zu sagen und wird gleich des Werfens von Nebelkerzen bezichtigt. Thats the old way. 

Und die Sicherheit einer Anwendung besteht nicht darin, dass ich mich um Sicherheitprobleme nach ihrem offenbar werden kümmere. Ich gehe mal davon aus, dass Dir das "nicht" aus Versehen in den zweiten Halbsatz reingerutscht ist. 

[rudolfkoenig]

Und die Sicherheit einer Anwendung besteht nicht darin, dass ich mich um Sicherheitprobleme nach ihrem offenbar werden kümmere.

Das ist auch eine Unterstellung. CSRF habe ich eingefuehrt und viele Stunden Support geleistet, ohne dass jemand deswegen je ein Problem gemeldet hat. Das staendige Nerven von nicht gesetzten Passwort, oder das vereinfachte Umschalten auf HTTPS kam auch nicht, weil es eine Meldung gab. Das Pruefen auf non-local IP waere wegen den neuen Vorschlaegen auch nicht eher gekommen.

Ich erwaehne das, damit bei einem unbedarften Leser nicht der Eindruck entsteht, dass Sicherheitsaspekte bis jetzt vernachlaessigt wurden.

[volschin]

Rudolf, Du willst mich anscheinend falsch verstehen. Was ich sagen wollte war: Du hast von Sicherheitsproblemen geschrieben, Sicherheit beginnt für mich bei der Umsetzung von Coding Best Practices, die sich Leute mal ausgedacht haben um Anwendungen stabiler und sicherer zu machen. Und daher ist es schön, dass jetzt mal mit Perl::Critic draufgeschaut wird und zumindest die Sachen mit hoher Severity angegangen werden.

[rudolfkoenig]

Sicherheit beginnt für mich bei der Umsetzung von Coding Best Practices

Stimmt, wir haben dann eine unterschiedliche Vorstellung von Sicherheit.
Vermutlich stammt deine Vorstellung daher, dass z.Bsp. im C mit Verwendung von snprintf bestimmte Sicherheitsprobleme vermieden werden koennen.
Mir ist nicht bekannt, dass perlcritic Fehler dieser Klasse findet.