Update einer Chatfunktion

[dedlfix]

Tach!

Beide Varianten müssen gewährleisten, dass Nutzdaten nicht versehentlich als Steuerdaten interpretiert werden.

Mir scheint, dass du dich hier irrst. Bei der verlinkten Variante werden beim Execute Variablennamen angegeben. Wie die Werte in die Variablen kommen ist nicht das Problem der Prepared Statements.

Sobald die Variablen aber mit Programmdaten gefüllt werden müssen, gibt es einen Schritt da findet ein Kontextwechsel statt.

Das ist aber nicht Teil des Prepared Statements. Natürlich hat man Kontextwechsel auch an anderen Stellen, wenn man Literale formulieren muss. Das sind aber andere Baustellen, selbst wenn man die Baustellen so aneinandereiht, dass die Variablenzuweisung-mit-Literal-Baustelle sich vor der Prepared-Statement-Baustelle befindet.

Ich sehe da weder ex- noch implizites Maskieren.

Mir scheint es so, als setzt du Kontextwechsel gleich mit der Notwendigkeit Daten maskieren zu müssen. Maskierung ist doch nur eine Möglichkeit einen Kontextwechsel zu behandeln, Längenangaben sind eine weitere.

Ja, das sehe ich hier wohl etwas enger. Bei aneinandergereihten Längenangabe-Nutzdaten-Paaren sehe ich keinen Kontext, in den sie eingefügt werden. Sie bilden quasi selbst den Kontext. Es sind für mich nicht zwei verschiedene Systeme, die gemischt werden, sondern nur eins.

Wie auch immer, aus praktischer Sicht spielt es keine Rolle, ob es irgendwo intern in einer Blackbox einen impliziten Kontextwechsel gibt oder nicht. Darauf hat man keinen Einfluss und kann ihn als nicht existent betrachten. Unabhängig davon sehe ich es selbstverständlich als legitim an, zu Studienzwecken die Blackbox zu öffnen. Aber das zieht keine gravierende Verhaltensänderung beim Verwenden nach sich. Besonders bei Blackboxen, deren Inhalt sich ändern kann oder unbekannt ist, darf das Innenleben nicht für die Verwendung relevant sein, da muss die Schnittstellenbeschreibung genügen.

dedlfix.