The African Chief wrote:
> long longint {now = integer}
> unsigned long longword {now = word}
The problem with this one is that (at least on the common platforms),
"long" is the same as "int", and I'd expect (as probably many ex-BP
programmers do) LongInt to be longer than Integer. In fact, some of my
programs rely on this.
> long long comp {now = longint, or comp}
> unsigned long long compword (now = longword}
Why "Comp"? What does "Comp" mean at all? -- I really don't know,
perhaps I could look it up in one of the 11 BP books... :-|
However, I don't think "Comp" is reasonable name for any integer
type, except for BP compatibility ("Comp" = "compatibility type" ;-).
> However, since the above will most likely break a lot of existing
> code, perhaps GPC should have built-in data types that mean
> *exactly* the same thing as they mean in GCC
Seems necessary. (I didn't like how C messed up their integer types,
now we're getting the same problems... :-( -- I hope we find a good
solution finally!)
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
According to Bernhard Tschirren:
>
> Its high time you release another alpha! I have GPC970510, the latest
> release. My GPC does NOT compile A^[(I)]?!? It aborts with the following
> error messages: [...]
Ah - I see. gpc-970510 misinterpretes `^[' as a control character.
It is already fixed in my current development version. Sorry,
I should have checked it with gpc-970510 before replying ... #-)
To work around this, insert a blank between the `^' and the `['.
> So, when is the next release coming? :-)
Either as soon as I have fixed all pending bugs and I find a day without
new bug reports, or else when I give up fixing them. ;-)
Seriously, I am now putting in the Integer types discussed during the
last days, and I have two pending bugs: casts of structured types and
duplicate field identifieres. In addition, due to major changes in the
structure of GPC's source, there are some problems with DJGPP and EMX
we must solve before the release. :-( Everything else planned for the
first post-2.0 GPC beta release is finished now. :-)
Thanks for your patience,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]
>Where is the bug??? My version of GPC compiles it.
>
>In case you think that `A^[(I)]' would be illegal: It isn't. :-)
>`(I)' is an expression in parentheses which means the same as just `I'.
>
Its high time you release another alpha! I have GPC970510, the latest
release. My GPC does NOT compile A^[(I)]?!? It aborts with the following
error messages:
bug01.pas: In function `program_Funnybug':
bug01.pas:14: warning: expression used as a statement - value is ignored
bug01.pas:14: parse error before `^'
bug01.pas:14: missing semicolon
bug01.pas:14: warning: expression used as a statement - value is ignored
bug01.pas:14: missing semicolon
bug01.pas:14: missing semicolon
bug01.pas:14: missing semicolon
bug01.pas:14: missing semicolon
STRANGE!
So, when is the next release coming? :-)
Cya L8r
________________________
| _) | | e-mail: bernie(a)icenet.com.au
|___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au
www: www.geocities.com/CollegePark/Quad/8070/
According to Frank Heckenbach:
>
> And something I just noticed concerning "Word" (this is addressed more
> to Peter ;-) :
>
> A "machine word" in the sense of assembly language actually describes
> the *size* of data and not whether it's signed or unsigned, doesn't it?
> (Data in asm are neither signed nor unsigned per se, it depends on which
> operations are used on them.) So from the original meaning (in PC real
> mode) "Word = 16 bits", Borland made "Word = 16 bits unsigned", and now
> you seem to be making "Word = unsigned" out of it...
Now you have got me! (-:
Okay, so GPC will have `FooInt' for signed, `FooCard' for unsigned integer
types, and `FooWord' for types where we don't care about signedness (and
which are in fact unsigned).
These are many Integer types for GPC - much more than in BP. So let's hope
that this will lead to clear programming, not to confusion ...
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]
According to Bernhard Tschirren:
>
> This is the -best- bug that I have ever found! :-) Take a look at the code
> below...
>
> Program
> FunnyBug;
> Type
> PArray = ^TArray;
> TArray = Array[0..255] Of Integer;
> Var
> I : Integer;
> A : PArray;
> Begin
> New(A);
> For I := 0 To 255 Do
> Begin
> A^[I] := 10;
> A^[(I)] := 10; { :-) }
> End;
> Dispose(A);
> End.
>
> Hehehe. I LOVE GPC's parser...
>
> Good Luck
Where is the bug??? My version of GPC compiles it.
In case you think that `A^[(I)]' would be illegal: It isn't. :-)
`(I)' is an expression in parentheses which means the same as just `I'.
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]
Peter Gerwinski wrote:
> Discussion of #1: Compatibility to BP.
>
> - GPC is *not* intended to be a drop-in replacement for BP.
> Compatibility is desireable as long as we don't have to pay a high
> price for it. We want to preserve the "spirit" of BP in GPC, not
> its "letters". What we do is to "write BP, as it should have been",
> not "rewrite BP, exactly as it is".
>
> - GPC is a 32-bit compiler. Maybe we will extend it to 64 bits, some day,
> but we won't restrict it to 16 bits.
>
> That's why `Word' etc. are as they are, and why I think they should
> not change.
Agreed. And if someone wants to redeclare them for
"100% silver plate compatibility", this is no problem to do.
(Like in the Chief's system unit with -D_Borland_16_Bit_.)
The only question is if *in*this*special*case* also Integer should be
redeclared to 16 bits. (I know this is quite unusual, but since this
mode is *only* for using existing BP programs without (ideally any)
changes, these programs are likely to expect integer to be 16 bit.)
> Round parentheses are easiest to implement, but their syntax interferes
> with Schemata.
Would this a problem? It's very unlikely that someone would declare a
schema called "Integer", isn't it? Such an "Integer(n)" could be a special
built-in schema (special in that the "n" is not stored in the variable).
> Square brackets come into mind, but they interfere with
> UCSD's "long integers".
<off-topic> Are these UCSD "long integers" of arbitrary size, or limited to
subtypes of regular integer types? </off-topic>
> While the remaining two possibilities are certainly the most `Pascalish'
> ones, they are not 100% clear: What size has `packed $1000..$10FF'?
> Although 8 bits would be sufficient, GPC would allocate 13 bits.
This is a strange case, indeed! How are they handled currently in packed
record. Testing seems to show to it's 13 bits in fact.
(* The results are a bit strange. The following program gives "1299" !?!
program x;
type y=packed array [1..800] of $1000..$10ff;
begin
writeln(sizeof(y))
end. *)
I think it's ok like this. After all, if it's really for a system call
or so, what sense would it make to interpret the values as $10xy if they
were only stored as $xy? As a rule, one might say that the internal
representation of a subrange always includes 0.
> Outside
> of packed arrays and records, they would be rounded to the next unit the
> machine can access, usually 8 bits, but it can also be 16 or 32 bits.
Can not all machines address 1 byte? I.e., is "Byte" on some machines bigger
than 1 byte (internally)? This gives real problems with binary files,
doesn't it? How do such machines read single bytes from files at all?
> Despite of the disadvantage sketched above, I think that `packed 0..$FF'
> is the way to go. Authors of libraries are encouraged to define their own
> types using this mechanism.
>
> To have `LongestInt' as - currently - a synonym for `LongInt' cannot
> hurt. If one day there will be something longer than `LongInt', we
> can name it `LongLongInt' (because it might be superseeded again by
> `LongLongLongInt'), but `LongestInt' will always remain the longest one.
Fine! :-)
> Discussion of #3: Compatibility to GCC.
>
> I can guarantee that the above GPC <--> GCC compatibility rules for
> `ShortInt' etc. will not change. Then the only needed thing is something
> which is guaranteed to be the same as `long' in GCC, even if `int' is
> not the same as `long'. Since we are aiming towards the top, C's `long'
> is just "medium" for us. ;-) Thus I propose the names `MedInt' and
> `MedWord'.
Why not! If it's documented, headers should be "easy" to convert then!
> Summary and Proposal:
>
> Let all GPC integer types like they are, and add `MedFoo' and
> `LongestFoo':
If you don't mind, please also add {Short,Med,Long,Longest}Card[inal].
> Okay like this? Or better keep `Integer ( 8 )' (or `Integer < 8 >',
Why not, additionally!
("Integer(n)" is easier to read than "Packed 0..1 shl n-1".)
> or `Integer : 8' like bit-fields in C,
"a:Integer:8" would look strange to me.
> or `Integer * 1' like in FORTRAN?)
Would also look strange to me. "Integer * 2" I would understand as "twice
the size of an integer", if at all...
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
This is the -best- bug that I have ever found! :-) Take a look at the code
below...
Program
FunnyBug;
Type
PArray = ^TArray;
TArray = Array[0..255] Of Integer;
Var
I : Integer;
A : PArray;
Begin
New(A);
For I := 0 To 255 Do
Begin
A^[I] := 10;
A^[(I)] := 10; { :-) }
End;
Dispose(A);
End.
Hehehe. I LOVE GPC's parser...
Good Luck
________________________
| _) | | e-mail: bernie(a)icenet.com.au
|___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au
www: www.geocities.com/CollegePark/Quad/8070/
According to A.A. Olowofoyeku:
>
> [...] I *need* to be able to do
> something like;
>
> Type r = record
> foo : integer value 24;
> bar : char value 'B';
> end;
The syntax
Type
R = record
foo: Integer;
bar: char;
end (* R *) value ( foo: 24; bar : 'B' );
is intended to yield what you expect.
But it seems to be broken at the moment,
so please be patient ...
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]
The African Chief wrote:
> >The problem with this one is that (at least on the common platforms),
> >"long" is the same as "int", and I'd expect (as probably many ex-BP
> >programmers do) LongInt to be longer than Integer. In fact, some of my
> >programs rely on this.
>
> Yes. But in BP, "integer" is 16-bit and "longint" is 32-bit.
> Surely, if your programs rely on "longint" to be bigger than
> "integer", they also expect "integer" to be 16-bit?
Not necessarily.
> If GCC's
> "long" is 32-bit and GPC's "longint" is 64-bit - what does that
> say about compatibility of data structures?
E.g., that LongIntVar=LongInt(IntVar)*IntVar works always without
overflowing, or that you can type cast a LongInt into a record of two
Integers.
> This is from the BPW help file;
>
> "Note: The comp type is a 64-bit integer. It holds only integral
> values within the range (-2 63 + 1) to (2 63 - 1)."
I know that (except that I think it should be -2^63, not "+1").
What I don't understand is the strange name "Comp" -- which I still
can't make any sense of in connection with integer data types.
And something I just noticed concerning "Word" (this is addressed more
to Peter ;-) :
A "machine word" in the sense of assembly language actually describes
the *size* of data and not whether it's signed or unsigned, doesn't it?
(Data in asm are neither signed nor unsigned per se, it depends on which
operations are used on them.) So from the original meaning (in PC real
mode) "Word = 16 bits", Borland made "Word = 16 bits unsigned", and now
you seem to be making "Word = unsigned" out of it...
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm