Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   FreePascal (https://www.delphipraxis.net/74-freepascal/)
-   -   Typisierte vs. Untypisierte Konstante (https://www.delphipraxis.net/135671-typisierte-vs-untypisierte-konstante.html)

jaenicke 16. Jun 2009 07:37

Re: Typisierte vs. Untypisierte Konstante
 
Ich würde generell keine Nullzeichen in Strings verwenden.
Aber solange keine Arrays mit den damit verbundenen Umwandlungen verwendet werden, sollte es ja klappen.

Wenn die Arrays notwendig sind, bleiben wohl nur direkte Speicheroperationen um damit zu arbeiten. Aber wozu sind die denn nötig, gibt es da einen zwingenden Grund?

FAlter 16. Jun 2009 08:22

Re: Typisierte vs. Untypisierte Konstante
 
Hi,

es handelt sich um MagicBytes am Anfang einer Datei. Daran soll festgestellt werden, ob es sich um die richtige Datei handelt - es ist unwahrscheinlich, das eine andere Art von Datei mit dieser Buchstabensequenz gefolgt von drei #0-Zeichen beginnt. Und wir kennen ja alle die Dateien, die mit MZ, PNG, JFIF, TIFF, MTrk, PKZIP, EXIF oder einer ähnlichen Sequenz beginnen. Dies ist durchaus üblich. Und manchmal die einzige Möglichkeit den Typ eines Streams festzustellen (z. B. in RCDATA Ressourcen oder bei Wiederhergestellten Sequenzen gelöschter Dateien oder bei Dateien mit falscher oder ganz ohne Erweiterung).

Das #0 gehört in diesem Fall bewusst zu den MagicBytes dazu.. Ich möchte in jedem Fall sicherstellen, dass die 8 Bytes komplett übereinstimmen. Und ich hatte nicht erwartet dass ein statisches Array zum Vergleich in irgendwas umgewandelt wird. Hätte ich Array[0..7] of Byte gewählt dann dürfte es ja auch kein Problem geben wenn dort 0 vorkommt. Prinzipiell könnte ich mir auch den entsprechenden Int64 ausrechnen und mit diesem Vergleichen nur ich will lesbaren Code und da bietet sich ein statisches Array of AnsiChar halt an. Oder auch nicht wie sich gezeigt hat.

Gruß
Felix

jaenicke 16. Jun 2009 08:36

Re: Typisierte vs. Untypisierte Konstante
 
Ja, aber was machst du denn mit Arrays? Warum keine normalen ShortStrings? (Strings gehen zwar auch, würden aber bei falscher Länge keinen Fehler produzieren.)

Da wird korrekt verglichen, da die Länge nicht erst bestimmt wird wie bei der Umwandlung aus dem Array.
Delphi-Quellcode:
const
  a: String[10] = 'Test'#0#0#0#0#0#0;
var
  b: String[10] = 'Test'#0#0#0#0#0#1;
  c: String[10] = 'Test'#0#0#0#0#0#0;
  d: String;
begin
  Writeln(a = b);
  Writeln(a = c);
  d := b;
  Writeln(a = d);
  d := c;
  Writeln(a = d);
ergibt (zumindest in Delphi) korrekterweise
Code:
FALSE
TRUE
FALSE
TRUE
Und es wird die Länge auch korrekt mit 10 im Vergleich benutzt.

FAlter 16. Jun 2009 09:02

Re: Typisierte vs. Untypisierte Konstante
 
Hi,

wenn ich einen String[8] in ein packed record packe, dann enthält dieser auch noch ein Längenbyte, was falsch ist. In der Datei ist vorne kein #8 für die Längenangabe, einfach die 8 Zeichen. Oder ich müsste die MagicBytes einzeln einlesen, ich will aber lieber den ganzen Header in einem Rutsch einlesen. Klar wäre move auch noch ne Möglichkeit. Ich wollte es halt nur einfacher machen.

Gruß
Felix

jaenicke 16. Jun 2009 09:38

Re: Typisierte vs. Untypisierte Konstante
 
Ach so meinst du das. Dann bleibt dir nur die Typisierung oder ein Vergleich des Speichers:
Delphi-Quellcode:
program Project196;

{$APPTYPE CONSOLE}

uses
  SysUtils;

const
  const1 = 'HALLO'#0#0#0;
  const2: array[0..7] of AnsiChar = 'HALLO'#0#0#0;
var
  foo: array[0..7] of AnsiChar;
begin
  foo := const1;
  if Length(const1) = Length(foo) then
    WriteLn(CompareMem(@foo, PChar(const1), Length(foo)))
  else
    WriteLn('Fehlerhafte Länge der Signatur!');
  WriteLn(CompareMem(@foo, @const2, Length(foo)));
end.
So klappt der Vergleich, aber durch die fehlende Typisierung sollte wie hier im Beispiel eine falsche Länge der Konstante ggf. abgefangen werden.


Alle Zeitangaben in WEZ +1. Es ist jetzt 23:47 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz