unsigned DWORD

[EWeiss]

Einige hier verwenden die Bass Library.
Habe mir die Mühe gemacht meinen Code nochmals zu analysieren inklusive eingeschalteter Bereichs Prüfung.

Das Problem ist folgendes.
BASS_ChannelGetData und andere Funktionen verursachen ERangeError's (manchmal) weil hier DWord unsigned (LongWord 0 bis 4294967295.) verwendet wird.
Treten also minus werte auf dann kracht es.

Die Library von Bass verschickt aber mit seinem Archiv die API Definiert wie folgt.
function BASS_ChannelGetData(handle: DWORD; buffer: Pointer; length: DWORD): DWORD;

Zitat:

But note, that BASS uses signed values, e.g. BASS_ChannelGetData() might return -1 in certain cases - see the docs.

Nun frage ich mich warum definiert man so eine Funktion bewusst falsch obwohl man ganz genau weis das hier signiert Werte als Rückgabe geliefert werden.

Also muss ich die Bereichsprüfung ausgeschaltet lassen oder gibt es vergleichbare signierte Data Typen für DWord?
Wenn nicht ist diese Library ohne ausgeschalteter Bereichsprüfung
bzw. ohne jedes einzelne Sample vorher auf negative werte zu analysieren nicht verwendbar mit Delphi.


gruss

[mensch72]

?unsigned? DWORD... es gibt bei xWORD da 100% gar kein "signed"/"unsigned"!
Ein WORD ist ein "unsigned 16BIT-Wert" und ein "DWORD" ist ein "unsigned 32BIT-Wert" und ein "QWORD" ist ein "unsigned 64BIT-Wert"... in allen Programiersprachen und in allen OS und auf allen Plattformen vom 8Bit Microcontroler bis zur 64Bit ARM/Intel CPU

Ein DWORD (unter 32Bit Delphi "cardinal") kann per Definition keinen ungültigen "Bereich" haben, da alle Werte von $00000000..$FFFFFFFF gültig und zugelassen sind.
Das "zufällig" $FFFFFFFF in 32BitDelphi auch für "-1" beim "Integer-Typ"steht und der Compiler dadurch eventuell meint ein $FFFFFFFF Cardinal/DWORD sei "out of Range", ist ein FEHLER der Bereichsprüfung durch dem Compiler!

-> mache ein Minimalbeispiel und eröffne im QC bei Emab/Idera einen Fall

[EWeiss]

unsigned bedeutet meines Erachtens das die werte im Bereich zwischen 0.. xxx + liegen.
signed werte können aber im Bereich zwischen -1.. xxx + liegen.

Oder warum denkst du das es sonst einen ERangeError mit dem Data Typ DWORD in Delphi gibt?
Dieser liegt nun mal bekanntlich im Bereich von 0 bis 4294967295.

Also nochmal vom Bass Forum..

Zitat:

A DWORD in Delphi is unsigned!

But note, that BASS uses signed values, e.g. BASS_ChannelGetData() might return -1 in certain cases - see the docs.
Guess this might cause your issue!

Und!
http://docwiki.embarcadero.com/Libra...em.Types.DWORD

Zitat:

DWORD is a 4-byte unsigned integer.

Ob ich nun versteckt sage
DWORD is a 4-byte unsigned integer.
oder
DWORD ist unsigned ist gehüpft wie gesprungen..
Das kannst du für dich definieren wie du willst ändert aber nichts an der Tatsache.

Zitat:

ist ein FEHLER der Bereichsprüfung durch dem Compiler!

Warum wurde es dann bisher nicht behoben? Wenn es denn so ist wie du sagst.
Wie gesagt es ist ein unsauberer Code wenn ich bedingt durch die Data Typen die Bereichsprüfung ausschalten muss.
Ein gefrickel ohne gleichen.

gruss

[mensch72]

Sorry das ist kein Gefrickel, das ist pure binäre Logik.

"Oder warum denkst du das es sonst einen ERangeError mit dem Data Typ DWORD in Delphi gibt?"... für negative "Integer" Werte oder Konstanten die man ohne Cast auf DWORD zuweist(obwohl die Typgröße im Speicher passt) und in 64BitDelphi macht es Sinn
(z.B. unter Delphi64Bit ist es klar, das eine = $FFFFFFFFFFFFFFFF für eine z.B. "Integer:-1" Zuweisung einen Fehler bei der Bereichsprüfung wirft, denn $FFFFFFFFFFFFFFFF ist dann nunmal größer wie der maximale $FFFFFFFF im DWORD Typ)

Sorry für die Faulheit alles in Hex zu schreiben, da es eh um das Verständnis der entsprechenden 2er Potenzen geht, ist es so sogar "klarer" worum es geht.
(in dezimal erkenne ich den Zusammenhang auch immer nicht sofort, aber das Spiel mit den Nullen&Einsen kann man sich durchaus mal BitByBit zu Gemüte führen )


BASS nutzt bei seinen DLL Deglerationen die WindowsAPI und C konforme Variante, möglichst alles vorzeichenlos Sprachen portabel mit 100% fix bestimmten Typen zu definieren.
BYTE = unsigned 8Bit 0..$FF
WORD = unsigned 16Bit 0..$FFFF
DWORD = unsigned 32Bit 0..$FFFFFFFF
QWORD = unsigned 64Bit 0..$FFFFFFFFFFFFFFFF

Mit signed Variablen mit wo möglich noch ala "Integer" variablem Wertebereich kann ich in eigenen Programmteilen leben, aber wenn es um externe Kopplungen geht sollte man wie BASS es macht sich an die üblichen Standards halten.
Wenn was in Delphi nicht passt, liegt es oft nur an "schlecht" definierten/portierten Konstanten welche z.B. als "-1" deglariert sind und bei aktivierter Bereichsprüfung eben nicht für einen DWORD Parameter verwendet werden können.

[Uwe Raabe]

Zitat von EWeiss:

Zitat:

ist ein FEHLER der Bereichsprüfung durch dem Compiler!

Warum wurde es dann bisher nicht behoben? Wenn es denn so ist wie du sagst.

Ich habe in diesem Thread noch keinen Code gesehen, der einen solchen Fehler im Compiler auslöst.

Zitat von EWeiss:

Wie gesagt es ist ein unsauberer Code wenn ich bedingt durch die Data Typen die Bereichsprüfung ausschalten muss.

Auch solchen Code habe ich hier noch nicht gesehen.

Selbst wenn die BASS-Funktion ein -1 zurückgibt, sollte ein Vergleich auf eine DWORD-Konstante mit dem Wert $FFFFFFFF das gewünschte Ergebnis bringen (für das Gegenteil hätte ich dann gerne ein konkretes Beispiel). Solange die anderen Rückgabewerte nicht über MaxInt liegen, sollte auch ein Cast auf Integer funktionieren. Eine simple Zuweisung eines DWORD auf einen Integer wird aber gelegentlich zu einem RangeError führen, aber das ist ja auch so gewollt.

Es ist natürlich schlechter Stil, wenn eine Typdeklaration ein DWORD angibt, die Dokumentation dann aber von -1 spricht. Das ist aber eindeutig die Schuld der BASS-Library. Wobei auch Microsoft in der Windows-API gerne mal einen solchen Fehlgriff verbaut hat.

[hoika]

Hallo,
warum nimmst du dann nicht einfach Integer statt DWORD?

[EWeiss]

Mit gefrickel meine ich das wenn ich die Bereichsprüfung für Bass extra ausschalten muss.
Es hatte nichts mit deiner Person zu tun. oder den Byte Werten an sich.

Zitat:

Ich habe in diesem Thread noch keinen Code gesehen, der einen solchen Fehler im Compiler auslöst.

Dieser hier!

Einfaches Beispiel.
Mit Bereichsprüfung wirft diese Funktion einen ERangeError.
Nicht bei normaler Behandlung aber wenn ich die Samples pushe über einen Equalizer.
function BASS_ChannelGetData(handle: DWORD; buffer: Pointer; length: DWORD): DWORD;

Delphi-Quellcode:

function BassDataAvailable: BOOL;
var
  BytesValid: DWORD;
begin
  result := TRUE;

  BytesValid := BASS_ChannelGetData(gnAudioChannel, nil, BASS_DATA_AVAILABLE); //<< ERangeError

  if BytesValid = DW_ERROR then
    result := FALSE;

end;

Wie du siehst ist das ne simple Sache destotrotz werden Fehler geworfen..
Ich kann die Samples natürlich einzeln analysieren und anschließend BytesValid den Wert übergeben.
Nur wo steckt der Sinn dahinter.

Und dieser hier!

Delphi-Quellcode:

      for C := 1 to 2 do
        Inc(pInteger[C]); // WaveData von TWaveData über BASS_ChannelGetData

Ich muss hier die Samples separat vorher Analysieren um den Fehler zu beheben.

Delphi-Quellcode:

      for C := 1 to 2 do
      begin
        IntI := pInteger[C];
        if (IntI > 32767) then
          IntI := 32767
        else
        if (IntI < -32768) then
          IntI := -32768;
        pInteger[C] := IntI;
      end;

gruss

[EWeiss]

Anderes Beispiel.

Delphi-Quellcode:

function BassChannelGetLevel: DWORD;
begin
  result := 0;

  if gnAudioPause = FALSE then
  begin
    if gnAudioChannel <> 0 then
      result := BASS_ChannelGetLevel(gnAudioChannel);
  end;
end;

Zitat:

stack dump:
0018e06c 7e de 56 00 de fa ed 0e - 01 00 00 00 07 00 00 00 ~.V.............
0018e07c 80 e0 18 00 7e de 56 00 - 00 76 a1 02 7e de 56 00 ....~.V..v..~.V.
0018e08c 7e de 56 00 00 00 00 00 - 60 e9 18 00 9c e0 18 00 ~.V.....`.......
0018e09c 04 00 00 00 74 43 40 00 - 00 80 00 80 90 6e 9d 02 ....tC@......n..
0018e0ac 7e de 56 00 68 e9 18 00 - ec 62 40 00 60 e9 18 00 ~.V.h....b@.`...
0018e0bc 00 00 00 00 d4 53 56 00 - 00 00 00 00 00 00 00 00 .....SV.........
0018e0cc 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e0dc 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e0ec 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e0fc 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e10c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e11c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e12c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e13c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e14c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e15c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e16c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e17c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e18c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0018e19c 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................

Zitat:

disassembling:
[...]
0056de6e 3112 call -$15bdf ($558294) ; uBass.BassChannelGetLevel
0056de73 mov esi, eax
0056de75 test esi, esi
0056de77 jns loc_56de7e
0056de79 call -$16874a ($405734) ; System.@BoundErr
0056de7e 3113 > cmp esi, -1
0056de81 jnz loc_56de85
0056de83 3114 xor esi, esi
0056de85 3116 mov edx, esi
0056de87 movzx edx, dx
0056de8a mov ecx, $80
[...]

Code:

exception class    : ERangeError
exception message  : Fehler bei Bereichsprüfung.

usw..

gruss

[Uwe Raabe]

Und wie ist gnAudioChannel deklariert?

[EWeiss]

Zitat von Uwe Raabe:

Und wie ist gnAudioChannel deklariert?

Delphi-Quellcode:

HSTREAM = DWORD; // sample stream handle
gnAudioChannel: HSTREAM; (Cardinal)

Ich habe nichts davon hier irgendwas zu erzählen
Möchte nur das es funktioniert auch mit eingeschalteter Bereichsprüfung.
Das es nicht geht sieht man ja.

Bei diesen einfachen Beispielen kann man nichts falsch machen.
Kann aber auch nichts an den Ergebnis ändern das von Bass geliefert wird.

D2010..

gruss