Emil Jerabek wrote:
On Wed, Apr 21, 2004 at 02:30:18AM -0400, CBFalconer wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
AFAIKS intended operation is a shift. So `shl 4' is a high-level specification and `* $10' buys nothing. I can understand that uglyfication to `* 16' gives more portable code, but the unit uses shifts anyway.
Except, if you look at ISO 10206, there is no mention of any operator 'shl'. I don't believe $10 is mentioned either. Which, to my mind, leaves '* 16'.
The ISO 10206 equivalent of $10 is 16#10 (base#digits in general), which is a bit more typing, but IMHO it is much cleaner than the Borland syntax.
Note that I wasn't talking about standard compliance. The unit isn't anyway, because it uses shifts elsewhere (if that's what Waldek meant when pointing this out, that's true), and types of fixed size etc. (*)
I won't object if you replace `$' with `16#' (throughout). (IMHO, it's more general, but not necessarily cleaner (whatever this means) -- at least this BP syntax doesn't conflict with anything, such as the horrific BP `^A' char constants.)
(And while we're at it, I fail to see how `&h10' is preferable -- it introduces a new character just like `$', and it needs another letter. And I don't like suffix specifiers as in `10h' because they make it more difficult to parse the number, both for computers and humans, when reading left to right.)
(*) For a theoretical exercise on whether it's possible to implement MD5 in Classic/Extended Pascal (CP and EP for short):
- Shifts (with variable right argument) are difficult in CP, though possible with a loop or so, but inefficient. In EP you could use `* 2 pow n' etc. which could be as efficient as a shift with a compiler that optimizes this construct better than GPC currently does.
- The macros can, of course, be expanded, leaving the code just a bit longer and perhaps less readable.
- There are no types with fixed sizes. Of course, if you reduce anything to standard operations, it doesn't hurt if the type is bigger than you need. But you need to ensure that `Integer' has at least 32 bits. The standard doesn't guarantee this, but at least allows you verify whether it does (which should fail if MaxInt is smaller):
type Dummy = 2147483647 .. MaxInt;
(Well, actually MD5 uses unsigned types, so we'd need MaxInt >= 2^32 - 1. I didn't check if it could be done with signed type -2^31 .. 2^31 - 1, but since the standards prescribe a symmetrical integer range, we'd require MaxInt >= 2^31. This means, in both cases GPC would fail this check on 32 bit platforms.)
- But the main problem is how to access the buffer (a block of bytes). Of course, you could declare it, say, as a conformant array of `Byte' (assuming that `Byte' has a suitable declaration). This way you might be able to write MD5 in standard Pascal, but in fact you just shift the problem to the user (who, in standard Pascal, could not even declare `Byte' suitably, since `0 .. 255' is not guaranteed to occupy one byte -- nothing of this sort is guaranteed by the standards, of course).
Frank