Remix-Warnung - Keine Sichtbarkeit angegeben, Verletzung von Checks-Effects-Interaction-Pattern, Funktionszustandsveränderlichkeit kann auf rein beschränkt werden - Kann ignoriert werden?

Im Algemeinen

Sie können den Code laufen lassen und dabei die Compiler-Warnungen ignorieren, aber es ist immer gut, dies nicht zu tun. Compiler-Warnungen warnen Sie meistens vor etwas, das einen Fehler in Ihrem Code verursachen könnte. Im Vergleich zu Compilerfehlern besteht der Unterschied darin, dass Ihr Code syntaktisch korrekt ist und daher kompiliert werden kann, aber zu Problemen führen kann, insbesondere wenn jemand versucht, etwas zu tun, was Sie von anderen nicht erwarten.

Compiler-Warnungen weisen auf Dinge hin, die Probleme verursachen oder unbeabsichtigte Auswirkungen haben könnten, die dem Programmierer nicht bewusst waren.

Eine gute Lektüre dazu finden Sie hier , und Sie können sich auch auf diese Frage beziehen . Lesen Sie vor allem die Sicherheitsüberlegungen in Solidity-Dokumentation. Das kann Ihr Leben retten!

Wie auch immer, der Compiler ist nicht so intelligent wie Sie und behauptet, was ihm in Note:folgenden Anweisungen fehlt:

Hinweis: Modifikatoren werden derzeit von dieser statischen Analyse nicht berücksichtigt.

Manchmal weisen diese Hinweise darauf hin, dass Sie diese Warnungen ignorieren können.

Beispiel

Eine Fehlerwarnung, die Sie erwähnt haben, ist:

browser/TestContract 8.sol:15:3 Warnung: Keine Sichtbarkeit angegeben. Standardmäßig auf "öffentlich":

Nehmen wir an, Sie haben function A(uint val) {}. Sie möchten, dass es aufgrund einiger vorheriger Validierungen, die Sie durchführen müssen, nur innerhalb des Vertrags verwendet wird (Dies ist nur ein Beispiel ;)). Und wenn die Funktion ohne Validierung aufgerufen wird, kann dies zu einigen unerwünschten Ausführungen führen. Und die einzige Verwendung function Abesteht darin, es innerhalb einiger anderer Funktionen innerhalb des Vertrags zu verwenden.

pragma solidity ^0.4.0;

contract Example {


    function A(uint val) {
       //do something with val 
    }

    function B(uint val){
        //validation of val
        A(val);
    }

}

Wenn Sie jetzt den Vertrag wie oben beibehalten, da function A()er standardmäßig auch auf öffentlich eingestellt ist, kann jeder, der Ihren Vertrag verwendet, ihn function Amit jedem beliebigen uintWert verwenden, und das kann zu Problemen führen. Aber wenn Sie den Zugriffsmodifikator von function Aals deklariert privatehatten, wird dieses Problem nicht auftreten, da function Anicht öffentlich zugegriffen werden kann. Und da Ihre Anforderung auch darin besteht, function Adie anderen Funktionen innerhalb des Vertrages zu nutzen, ist Ihr Ziel auch erreicht.

Wenn kein Zugriffsmodifikator deklariert wird, geht der Compiler davon aus, dass eine Funktion öffentlich ist, und warnt Sie, dass er die Funktion öffentlich macht, und fordert Sie auf, zu prüfen, ob sie wirklich öffentlich sein sollte. Im obigen Fall erhalten Sie Warnungen bezüglich der Funktionen und der Einstellung function Aauf privat, und function Bum öffentlich zu sein, werden die Warnungen entfernt, da der Compiler jetzt weiß, dass Sie absichtlich function Böffentlich und function Aprivat machen.

pragma solidity ^0.4.0;

contract Example {


    function A(uint val) private {
       //do something with val 
    }

    function B(uint val)public {
        //validation of val
        A(val);
    }

}

Die Warnung bezüglich function Bder Veröffentlichung ist eine Art Warnung, die Sie getrost ignorieren können, da Ihre Absicht auch dieselbe ist, aber die Warnung bezüglich function Aist etwas, das Sie wirklich berücksichtigen sollten.

Was ich vorschlage ,

• Ignorieren Sie die Warnung nicht, sondern gehen Sie sie durch und prüfen Sie, ob sie wirklich wichtig sind, wie Sie erwarten, dass sich der Code verhält, und versuchen Sie, sie zu lösen.

• Versuchen Sie, die neueste Compiler-Version (atm 0.4.17) zu verwenden, da neuere stabile Versionen tendenziell weniger Fehler und mehr Funktionen haben (daher werden neue Warnungen generiert).

Einige Einblicke in einige andere Warnungen, die Sie erhalten

browser/TestContract 8.sol:100:3 Warnung: Die Veränderbarkeit des Funktionszustands kann auf rein beschränkt werden

Sie können sich auf diese Antwort und diese Frage bezüglich der Einführung von viewund Typfunktionen beziehen pure.

Potentielle Verletzung des Checks-Effects-Interaction-Musters in TestContract.testFunction(address):

Dies liegt daran, dass Sie nicht dem Muster von Checks-Effects-Interactions folgen, wie es hier in der Dokumentation beschrieben wird. Sehen Sie sich die Funktion an, die diese Warnung erhält, und befolgen Sie das in der Dokumentation definierte Muster, um die Warnung zu vermeiden.

Und gemäß dem Code, der in dem von Ihnen geposteten Link zu finden ist, closeSale()sollte die Warnung wahrscheinlich darauf zurückzuführen sein, dass der Compiler davon ausgeht, dass die Möglichkeit eines erneuten Eintritts besteht , da Sie das Member-Ereignis LogSaleClosed(uint256 issuedSupply, uint256 restrictedTokens)nach Interaktionen mit dem Token-Vertrag aufrufen.

Was ich vorschlagen kann, ist, dieses Ereignis im Vertrag zu haben token. Sie können hier die Re-Entrancy-Schwachstelle sehen. Es heißt nur, wenn der schlechte Code es einem anderen Vertrag ermöglicht, mehrmals Geld abzuheben, weil sie die Zustandsvariablenanteile nach dem Senden der Transaktion ändern, was einige Zeit dauern kann, sodass der andere Vertrag dieselbe Funktion mehrmals aufruft, da der msg.senderWert bis dahin ungleich Null bleibt Die Transaktion wird ausgeführt. Wenn Sie dort den guten Code sehen, setzen Sie ihn zuerst shares[msg.sender]auf Null. Da Sie derjenige sind, der dies entwickelt hat, kennen Sie den Fluss der erwarteten Ereignisse und können sicher sein, dass kein erneuter Eintritt auftritt. Sie können ihn sicher ignorieren.

Test.transferFrom(address,address,uint256): Sollte potenziell konstant sein, ist es aber nicht. Hinweis: Modifikatoren werden derzeit von dieser statischen Analyse nicht berücksichtigt.

Was konstant bedeutet, ist, dass es den Zustand nicht ändern würde. Das heißt, es wird keine Zustandsvariable geändert. Normalerweise werden diese Funktionen als konstante Funktionen bezeichnet und mit dem Schlüsselwort Konstante definiert. Sie können dies lesen .

Wenn Ihre Funktionen also keine Statusvariablen ändern, können Sie sie als konstant deklarieren. Solidity erinnert Sie daran.

browser/TestContract 8.sol:100:3 Warnung: Die Veränderbarkeit des Funktionszustands kann auf rein beschränkt werden

Antwort: Funktionen können als rein deklariert werden, in diesem Fall versprechen sie, den Status nicht zu lesen oder zu ändern.

. http://solidity.readthedocs.io/en/develop/contracts.html#pure-functions