PureBoard

Verfasst: **12.01.2009 19:23**

Du verwendets schon wieder #PB_Ignore, lt. Hilfe -1, #PB_Ignore hat einen
gänzlich anderen Wert.
Als workaround einfach den Parameter, den Du sowieso immer falsch angibst
einfach weglassen, dann funktioniert es doch.

Verfasst: **12.01.2009 19:31**

ts-soft hat geschrieben:Du verwendets schon wieder #PB_Ignore, lt. Hilfe -1, #PB_Ignore hat einen
gänzlich anderen Wert.
Als workaround einfach den Parameter, den Du sowieso immer falsch angibst
einfach weglassen, dann funktioniert es doch.

Den WA hab ich auch so gemacht. Aber wenn ich es nicht so machen würde und nen 0 als Länge - Parameter angebe vergleicht der Befehl 0 Bytes, also nichts. Also #PB_Ignore => Vergleich bis zur 1. 0 . Unter XP läufts ja, also KEIN Bug in der Syntax/Verwendung sondern entweder Win 7 oder PB.

Willst du nicht einsehen da es ein PB oder Win 7 Bug ist?

> Du verwendets schon wieder #PB_Ignore, lt. Hilfe -1, #PB_Ignore hat einen gänzlich anderen Wert.

Was ist da für eine Aussage, versteh ich nicht

.

Verfasst: **12.01.2009 19:34**

purebasic.chm hat geschrieben:Hinweis: Wenn der 'Flags' Parameter angegeben wird, kann 'Laenge' auf -1 gesetzt werden, um die Strings zu vergleichen, bis ein Null-Zeichen gefunden wird.

Code: Alles auswählen

Debug #PB_Ignore

> Willst du nicht einsehen da es ein PB oder Win 7 Bug ist?
Ich sehe da keinen Bug, da diese Syntax nicht dokumentiert ist.

// Nachtrag:
richtige Syntax wäre z.B.

Code: Alles auswählen

Debug CompareMemoryString(Text1, @Text2, #PB_String_NoCase, -1, #PB_Ascii)

Aber dies ist für PB Strings, dieser liegt im ersten Fall IMHO nicht vor.

Verfasst: **12.01.2009 19:57**

ts mit -1 kommt aber das gleiche Ergebnis unter Win7 wie oben von mir gepostet. Und nu?

Verfasst: **12.01.2009 20:11**

DrFalo hat geschrieben:ts mit -1 kommt aber das gleiche Ergebnis unter Win7 wie oben von mir gepostet. Und nu?

Wollte ja nur drauf hinweisen, das die Syntax von Hause aus verkehrt ist.
Der Rest ist nicht dokumentiert als funktionierend. Mit PB Strings gehts ja.
Etwas was nicht dokumentiert ist, kann kein Bug sein. Der einzige Bug sind
fehlende Compilermeldungen.

Das es unter anderen Umständen, XP o.ä. funktioniert ist unerheblich,
solange es nicht als funktionierend dokumentiert ist.
Die Funktion ist eine Stringfunktion, dieser liegt IMHO nicht vor. Lediglich
Zeichen im Speicher liegen vor.

Verfasst: **12.01.2009 21:14**

Nochmals zum langsam mitlesen:

1. Hab ich in meinem ersten Post einen optionalen Parameter übersehen,
sorry, d. h. #PB_Any wäre valid, da es -1 entspricht.

2. Dieser Code sollte überall funktionieren und keine komischen Werte
ausspucken:

Code: Alles auswählen

; kompiliere als ascii-executable
Text1 = @"HaHa" 
Text2.s = "HaHa" 

Debug CompareMemoryString(Text1, @Text2, #PB_String_NoCase, -1, #PB_Ascii) ; ts-softs code
Debug CompareMemoryString(Text1, @Text2, #PB_String_NoCase)

@"Haha" ist ein Pointer zu einem nullterminierten String, ebenso
@Text2.s. Das ist die einzige Voraussetzung die diese Funktion mit
Parameter -1 verlangt.

Wenn dieser Code auf 2 Plattformen nicht das gleiche Resultat liefert,
dann ist da noch ein zusätzlicher versteckter Bug.
Könnte dieser Code von jemandem _nativ_ auf den 2 genannten
Plattformen getestet werden? Nicht auf Windows 7, denn diesen Test
würde ts-soft nicht gelten lassen.

3. @cxAlex: Wie ts-soft schrieb: #PB_Ignore darf in KEINER Weise
als Parameter für diese Funktion verwendet werden, denn es ist kein
gültiger Wert für einen Parameter.

That's it. Unglaublich wie viele Missverständnisse bei einem so kurzen
Code auftreten können

Verfasst: **12.01.2009 23:21**

k. Mein Fehler. Dachte #PB_Ignore = -1. Aber trozdem: selber Fehler mit -1, hat DrFalo ja schon auf ner Nativen Maschine bestätigt. Ich würd sagen das es n PB Bug ist den wenn die Speicher-VergleichsAPI von Win7 nicht funzen würde hätten denk ich mal ein paar mehr Programme Probleme unter Win7.

Verfasst: **13.01.2009 02:18**

Ich bin jetzt zu faul, Windows zu booten, um das selber zu testen (XP x64 nativ installiert), aber für mich schaut das defintiv danach aus, als ob on-the-fly-deklarierte Strings bei PB nicht nullterminiert wären (wäre Wünschenswert, dass das zukünftig im Handbuch klargestellt wird).

Hat schonmal einer von euch versucht, die Werte manuell in einen normalen Buffer zu schreiben (einen Versuch mit 0 am Ende des Strings und ein Versuch ohne 0 am Ende), und CompareMemoryString() da drauf loszulassen? So sollte sich doch feststellen lassen, was da abläuft.

OT: Mein Weltbild ist erschüttert. Dass ich das noch erleben muss, dass sich die grauen ASM-Eminenzen des Forums über so scheinbar triviale und primitive Dinge wie die Nullterminierung von Strings streiten... Bin mal gespannt, was Helle dazu sagt, wenn er auf den Thread hier stößt...

Verfasst: **13.01.2009 08:53**

Jo, de Code ergibt den selben Fehler, es liegt definitiv nicht an der Null Terminierung:

Code: Alles auswählen

Text1 = ?Test1
Text2 = ?Test2

Debug CompareMemoryString(Text1, Text2, #PB_String_NoCase, -1)
Debug CompareMemoryString(Text1, Text2, #PB_String_NoCase)

DataSection
  Test1:
  Data.s "HaHa"
  Data.b 0 ; 0 - Terminierung
  Test2:
  Data.s "HaHa"
  Data.b 0 ; 0 - Terminierung
EndDataSection

Verfasst: **13.01.2009 12:03**

@hardfalcon:

[...] aber für mich schaut das defintiv danach aus, als ob on-the-fly-deklarierte Strings bei PB nicht nullterminiert wären (wäre Wünschenswert, dass das zukünftig im Handbuch klargestellt wird).

Auch ich bin dafür, dass sowas ins Handbuch gehört. Es gibt bei PB
leider vieles, was nicht dokumentiert ist oder überhaupt Sinn ergibt...
Trotzdem, "Strings" sind Nullterminiert...
Ich kanns nochmals ausführen:
Konstante (oder auch "statische" genannt) Strings werden in der
Data-Section der Exe gespeichert:

Code: Alles auswählen

section '.data' writeable
pb_public PB_DEBUGGER_LineNumber
  dd     -1
pb_public PB_DEBUGGER_IncludedFiles
  dd     0
pb_public PB_DEBUGGER_FileName
  db     0
align 4
public _SYS_StaticStringStart
_SYS_StaticStringStart:
_S1: dw 104,97,108,108,111,0
_S2: dw 100,117,0

(hier mit Unicode kompiliert, deshalb dw anstelle von db)
Warum sie nicht in einer readonly Section sind, kann man Fred fragen...

Bei jeder Zuweisung eines statischen Strings in eine normale Stringvar-
iable wird der statische String zuerst kopiert. Wenn man aber @"hallo"
schreibt, wird direkt der Pointer zum statischen String, hier z. B. "_S1"
verwendet:

Code: Alles auswählen

; *p  = @"hallo"
  MOV    eax,_S1
  MOV    dword [p_p],eax
; *s = @"du"
  MOV    eax,_S2
  MOV    dword [p_s],eax

Man darf also nicht in die Pointer schreiben!

Übrigens wäre, wenn "hallo" kein "normaler" PB-String wäre, auch
ein solches Konstrukt nicht erlaubt:

Code: Alles auswählen

i.l = Len("hallo")

denn PB übergibt an Len() und jede andere Funktion mit String-Argu-
menten nicht eine Kopie des Strings, sondern nur den Pointer auf
die Stringdaten. Erst in der Funktion wird das Stringargument kopiert,
was auch der Grund ist, weshalb man aus Geschwindigkeitsgründen
nie grosse Strings als Stringparameter an Funktionen übergeben sollte...
Das sieht in ASM so aus:

Code: Alles auswählen

; i = Len("hallo")
  PUSH   dword _S1
  CALL   PB_Len_UNICODE
  ADD    esp,4
  MOV    dword [v_i],eax

Len() erwartet ja einen normalen PB-String, weshalb auch _S1 ein
normaler PB-String sein muss, weshalb "hallo" ein normaler PB-String
sein muss, weshalb "hallo" nullterminiert ist. q.e.d.

@cxAlex: Ich glaube dir sogar, dass da ev. noch ein Bug ist. Aber ts-soft
wird es nur als Bug akzeptieren, wenn du mit einer nicht-Beta von
Windows testest... Und auch nicht in VMware

PureBoard

Windows 7 x86 - CompareMemoryString Bug