Re: if EthType < StrToInt('$05DC') then EthType := 0; // does'nt work!!
From: Kris Leech (krisleech_at_email.com)
Date: Fri, 3 Sep 2004 09:35:19 +0000 (UTC)
Thanks that clears a lot up.
The little end problem was something else. It had to do with protocol
specs, some values are little end first and some are normal. Bizzare but
Its all down to the protocol specs - some values are normal word (8
bytes) some are odd like 6 bytes MAC addresses and 6 bits flags.
With the intel thing thought i know why hex can come out differently to
what you expect when converted to decimal - because they are backwards.
Thanks all, Kris.
Rob Kennedy wrote:
> Kris Leech wrote:
>> so i should have:
>> if IntToHex(EthType,2) < '$05DC' then ....
> No. Leave strings out of it entirely. Strings have nothing to do with it.
> In another thread, you mentioned that using htons solved your problem. I
> think you should actually call ntohs since you seem to be receiving data
> form the network and using it on the host, so you should convert from
> network byte order to host byte order. (Ntohs and htons really both do
> the same things, but their names are meaningful, and using the right
> name aids in understanding what the code is doing.)
>> Will this not compaire the two values on a string level instead of a
>> integer level?
> It will be a string comparison. You'd be asking whether the string
> representation of EthType's value in hexidecimal format comes before the
> string "$05DC" alphabetically. (Besides, IntToHex's return value does
> not include the leading "$" character.)
>> My understanding is that hex values are strings - is this incorrect?
> Yes. Hex values are simply another way of representing a number in a
> human-readable form. For example, the following all represent the same
> ochenta y siete
> four score and seven
> The Delphi compiler understands two of those formats, 87 and $57.
> Hexidecimal is a convenient way of writing numbers when you want to
> split the data byte-wise (or even bit-wise, with a bit of extra
> thinking), but it does not change the value of the number.
> With the number $0800, the most significant byte is $08 and the least
> significant byte is $00. When we write numbers, the most significant
> figures are always on the left. However, on Intel platforms, that is not
> how the numbers are actually stored in memory. Intel stores numbers in
> "little-endian" format, so when reading a number from a sequence of
> bytes, you'll read the least significant byte first: $00, then $08.
> But the sequence of bytes you're reading didn't come from an Intel
> platform. It came from the network, so you need to call ntohs to
> re-order them before using them on your Intel machine. (You'd actually
> call ntohs no matter what platform you're using; each platform's
> implementation of that function knows what to do to put the bytes in the
> right order. Sometimes, no re-ordering is necessary, in which case the
> function just returns its input as-is, but it's still a good idea to
> call the function.)
> When people say they want to "convert a number to hex" or vice versa,
> they're usually talking about a string representation of a number in
> hexidecimal format. For that, there are IntToHex and StrToInt. But the
> result of IntToHex is a *string*, not a number, and so the compiler
> treats it as such. The contents of the string have no inherent numerical
> meaning; they're just characters.