XProfan

Deutsch

Ich habe mir gerade 5 Stunden läng an der doch recht einfachen API CreateFileMapping die Zähne ausgebissen - bis ich folgendes entdeckt habe:
Kompilieren Markieren Separieren

PRINT ($40000000+$80000000) Das ist der richtige Wert für die API...
Print ($80000000 | $40000000) Den Wert will die API nicht...
PRINT ""
PRINT 4*16^7
PRINT $40000000
PRINT ""
PRINT 8*16^7
PRINT $80000000
PRINT ""
PRINT 2*$40000000
PRINT $80000000
Waitinput

Was läuft da schief? Profanbug? Habe Profan 7.5...

01.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Zwischenablage01.png	4 kB

Hochgeladen:	01.04.2005

Ladeanzahl:
		Herunterladen

01.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Interessant, hat also nichts mit meiner älteren Profanversion zu tun. Einen Großteil drer Werte kann ich mir erklären, nicht aber den Unterschied zwischen dem ersten und dem zweiten Wert. Folgendes ist auch noch interessant:
Kompilieren Markieren Separieren

Print ($80000000 | $40000000) Den Wert will die API nicht...
Print @or($80000000,$40000000) Das wäre auch richtig...
Waitinput

Ich denke mal, das kann für jeden, der mit der Windows-API arbeitet, eine Große Falle werden!

[...]

01.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Ich würde sagen das schreit nach ner
Kompilieren Markieren Separieren

Def ApiConformLong(1) val(translate$(substr$(str$(@&(1)),1,"."),"-",""))

UFFBT2648WUAA0D343S0V93Z.bmp	80 kB

Hochgeladen:	01.04.2005

Ladeanzahl:
		Herunterladen

01.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Irrtum!
Der negative Wert ist der korrekte Wert für die APIs.
APIs mit | zu addieren führt unter Umständen zu ganz drastischen Fehlern bei der Addition von Flag!!! Auch @or liefert den korrekten Wert, nicht aber das allgemeinübliche |, das eigentlich Fehler durch Doppeltaddition vermeiden sollte.

Das schreit eher (denke ich) nach einem Profan Bugfix!!!

01.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Frank
Abbing

Hi,

ein eindeutiger Profanbug. Jetzt weiss ich auch, warum meine Fehlersuche vor einigen Wochen ebenfalls zu einer Odysee wurde... Hast du Roland schon angemailt?

01.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Hallo Frank...

Ich habe da die interne Profan Typenumwandlung in Verdacht. Ich wollte erst mal nachprüfen, ob der Bug in neueren Versionen nicht schon behoben ist. Im Profan Forum habe die Geschichte ebenfalls gemailt - Roland angeschrieben habe ich noch nicht. Würdest du das übernehmen wenn er nicht reagiert?

01.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Frank
Abbing

Hi,

dein Posting ist wohl untergegangen. Habs nochmal an passender Stelle eingesetzt.

02.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Besten Dank. Hatte grad das gleiche vor und habe noch einen Satz dazugeschrieben.

02.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Hallo,

das Problem mit dem Operator | (OR) bei Flags habe ich überprüft und für die nächste Profan-Version gelöst!
Es tritt nur auf, wenn das Ergebnis den Longint-Bereich nach oben überschreiten würde, also größer als 7FFF FFFF ist. (LongInt geht von -8000 0000 bis +7FFF FFFF.) Dann geht das vorderste Bit (das bei der Wiedergabe des Wertes mit PRINT als negatives Vorzeichen gewertet wird) verloren.

Wie gesagt: In der nächsten XProfan 9 Subscriptionslieferung wird es korrekt funktionieren!

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

02.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Hallo Roland...

Besten Dank.
Da manche APIs, u.a. CreateFile, mit solchen großen (negativen) Flags arbeiten, wäre das auch sonst eine böse Fehlerquelle.

02.04.2005 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Ah lol jetzt hab auch ich verstanden - worum es geht.