How to set the thirtysecond bit?
ih8mj at fjf.gnu.de
Fri Dec 29 21:53:33 CET 2006
Bastiaan Veelo wrote:
> Thank you, Frank and others. The issue is solved, the curious may read on.
> I figured that it had something to do with the sign. The prefix - is
> logical if you think of it as a number in binary notation, but I thought
> of it as a bit field. We have a large amount of legacy code that
> compiles with the Prospero Extended Pascal compiler. I do not know why
> it does, maybe that compiler is not standard compliant in this regard.
Seems so, EP 6.1.7 says:
: An extendednumber shall denote, in conventional positional notation
: with the specified radix, a value of integertype in the closed
: interval 0 to maxint (see 22.214.171.124).
(So, no negative values.)
> That code consists of a library that stores flags in 32-bit constants.
> Then, in many utility programmes, some of these flags are ORed together
> and stored in an integer variable (although a cardinal would have been
> more appropriate).
Indeed, if the topmost bit is used. Of course, Cardinal itself is
not part of standard Pascal, so if you need this in standard code,
you might need some contortions for this bit. (However,
bit-operations such as "or" and "shl" are not standard Pascal
either, to start with.)
> In our case, the flag that is stored in the 32nd bit
> (the sign bit of an integer) never occurs alone, and therefore the
> hypothetical value of -0 is never attempted to be stored in the integer
Actually, it wouldn't be -0, as virtually every modern platform uses
two's complement, so this value would be -(MaxInt + 1) instead.
> Actually we do not have 32 flags, so we can just reorganise
> the bits and not use the 32rd one.
OK, probably easier. :-)
> Frank Heckenbach wrote:
> ... snip ...
> > Please note that in Pascal, unlike C, integers represent numbers,
> > not bit-patterns, so storing a 32-bit-pattern (with the topmost bit
> > set) in a signed integer type, which is common practice in C, is not
> > allowed in Pascal, as it would alter the numeric value.
> You have a misconception about C. Numbers are represented by
> values. The bit pattern is specified for positive and unsigned
> values, which restricts the representation to binary. However 2's
> complement, 1's complement, and sign-magnitude representation is
> allowed for negative values. What you call a "common practice" is
> in fact an error which is often not caught by the compiler.
OT, but is it really an error according to standard C, or not
explicitly forbidden? (In the latter case, the behaviour would still
be undefined, but it would be allowed for double-"errors" to cancel,
such as storing a negative value in an unsigned integer variable,
then assigning this variable to a signed variable and expecting the
original negative value there. I've seen such things in C code, of
Anyway, the moral is, if you want to use bit-patterns and need all
the bits, always use an unsigned type (such as "Cardinal" in GPC, or
"unsigned int" in C). (Not applicable to standard Pascal,
Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
More information about the Gpc