AnsiString mit fester Länge

[nicodex]

Zitat von GPRSNerd:

Ich habe an der Logik der Original-Funktion nix geändert [...]

Was nicht bedeutet, dass der Originalcode fehlerfrei sein muss

Zitat von GPRSNerd:

Es handelt sich laut Definition der Funktion um die Umwandlung von Unsigned 32bit Integers...

Es sieht so aus, als ob beabsichtigt wird, einen 4-Byte Integer in ein 4-Byte ACII-(Tag-)String zu konvertiren. Allerdings macht der Code nicht das, was beabsichtigt zu sein scheint (weil string[4] aus 5 Bytes besteht: Buffer[0] ist die Länge und Buffer[1..4] sind die Zeichen).

edit:

Delphi-Quellcode:

type
  TFourCC = record
    case Integer of
      1: (AsAnsi: array [0..3] of AnsiChar);
      4: (AsLong: LongInt);
  end;

function tEndInd.Put32s(AData: LongInt): AnsiString;
var
  FourCC: TFourCC;
begin
  FourCC.AsLong := AData;
  if MotorolaOrder then  // SwapLong(AData)
    FourCC.AsLong := (Swap(LoWord(AData)) shl 16) or Swap(HiWord(AData))
  else
    FourCC.AsLong := AData;
  Result := FourCC.AsAnsi;
end;

[Benmik]

Es sieht so aus, als hätte ich doch nicht deine, sondern eine alte Unit erwischt, obwohl auch ich das vorher noch einmal geprüft hatte. Ist mir natürlich peinlich, verstehe es aber selbst nicht ganz. Tschuldigung.

[wp_xxyyzz]

Hallo Benmik,

nachdem du dich offenbar gut mit dEXIF auskennst:

Um mein Programm, das dEXIF verwendet, auf Speicherlecks zu testen, habe ich heute mal FastMM4 an den Anfang der uses-Liste des Projekts gesetzt und bin über eine Unmenge von Meldungen über Speicher-Lecks gestolpert, die allesamt von dEXIF herrühren. Auch das mit dEXIF mitgelieferte DExView verhält sich ähnlich.

Ist dir das auch schon aufgefallen, bzw. hast du vielleicht einige dieser Speicherlecks schon beseitigt?

Gruß
Werner

[wp_xxyyzz]

Seltsam, mit MemCheck werden keine Speickerlecks gefunden. Aber es war mir ohnehin schon aufgefallen, dass FastMM4 immer wieder harmlose Stringoperationen bemängelt hat.

[himitsu]

FastMM, MemCheck und Co. können aber auch nicht alle SpeicherLeaks finden ... vorallem fast alle die, welche nicht über den Speichermanager laufen, fallen nicht auf.


hab hier grad irgendwie den Überblick verloren ... wo/welche ist denn nun eigentlich eine aktuelle Version dieser Datei?

[add]
hab auch mal etwas gespielt

Delphi-Quellcode:

function tEndInd.Put32s(AData: LongInt): AnsiString;
begin
  SetLength(Result, 4);
  if MotorolaOrder then begin
    asm
      mov eax, &AData
      bswap eax
      mov edx, &Result
      mov edx, [edx]
      mov [edx], eax
    end;
  end else PLongInt(@Result[1])^ := aData;
end;

function tEndInd.Put32s(AData: LongInt): AnsiString;
begin
  SetLength(Result, 4);
  if MotorolaOrder then 
    PLongInt(@Result[1])^ := SwapLong(AData) 
  else PLongInt(@Result[1])^ := aData;
end;

via Pointer-Variable;

Delphi-Quellcode:

function tEndInd.Put32s(AData: LongInt): AnsiString;
var P: PLongInt;
begin
  SetLength(Result, 4);
  P := @Result[1];
  if MotorolaOrder then begin
    asm
      mov eax, &AData
      bswap eax
      mov edx, &P
      mov [edx], eax
    end;
  end else P^ := aData;
end;

function tEndInd.Put32s(AData: LongInt): AnsiString;
var P: PLongInt;
begin
  SetLength(Result, 4);
  P := @Result[1];
  if MotorolaOrder then 
    P^ := SwapLong(AData) 
  else P^ := aData;
end;

[Benmik]

Nachdem ich kein solcher Delphi-Crack bin wie himitsu (danke an die Wertschätzung von wp_xxyyzz, leider nicht ganz berechtigt ), habe ich nochmal ein bisschen nachgeforscht, und beim Entwicklerforum einen Link auf einen Artikel von Embarcadero gefunden, der für mich etwas Licht ins Dunkel gebracht hat, und vielleicht dem einen oder anderen (der über Google herkommt?) nützlich sein kann. Man kann mich steinigen, aber die Tatsache, dass der Compiler hinter meinem Rücken einen Haufen Verrenkungen treibt (die natürlich als "magic" bezeichnet werden), war mir so unbekannt.

Delphi in a Unicode World Part I
Delphi in a Unicode World Part II
Delphi in a Unicode World Part III

Ich würde himitsu gern fragen, ob man mit seinem Code jetzt tatsächlich den in dEXIF ersetzen kann. Mir kommt es merkwürdig vor, dass in der ganzen Zeit nie eine Fehlfunktion des Codes resultiert oder jedenfalls nicht bemerkt worden sein soll. Leider ist mir der Unterschied zwischen den beiden Varianten nicht klar, und vor allem nicht, warum die Vorschläge jeweils als Doppelwhopper aufgeführt sind (Zeile 1 / Zeile 15, beispielsweise). Für etwas Aufklärung wäre ich dankbar.
(Mit der Dialogkomponente bin ich übrigens sehr zufrieden, leider hat der Autor sie noch nicht bei Torry aktualisiert).

Danke

Benmik

[GPRSNerd]

Es ist aber kein Wunder, dass die vermeintlichen Fehler in der Funktion nicht aufgefallen sind! Sie werden nirgendwo benutzt! Die Korrekturen haben also nur einen gewissen akademischen Wert.

[BlueStarHH]

Zitat von GPRSNerd:

Here we go! Angehängt sind die Units dEXIF 1.03d portiert nach Delphi 2009.
Die Portierung ist eine reine Umstellung auf explizite ANSIStrings, Unicode geht nicht!

Falls jemandem noch Probleme auffallen sollten, bitte melden, so dass wir alle davon profitieren können.

Danke für die Portiertung. Leider ist mir ein Fehler aufgefallen, dessen Ursache ich nicht erkenne: Unter Delphi 5 werden zum einem Bild alle vorhandenen Infos zu "Maker Specific Data" ausgegeben. Bei D2009 mit den neuen Units fehlt sehr viel.

So lasse ich die "Maker Specific Data" ausgeben:

Delphi-Quellcode:

if ImgData.HasEXIF and ImgData.ExifObj.msAvailable then
begin
  // verbose data is only available in the trace strings
  ImgData.ExifObj.ResetIterator;
  while ImgData.ExifObj.IterateFoundTags(CustomEXIF, Item) do
    Memo(Item.Desc, Item.Data);
end;

Im Anhang das Originalbild mit den EXIF-Daten und die beide Ausgaben als Bildschirmfoto.