Gpc

gpc@gnu.de

5400 discussions

Bug report
by C.WENDT＠CHATEAU.line.org 24 Jun '97

24 Jun '97

Am 24.06.97 konnte ich meine Finger einfach nicht von der Tastatur fernhalten... Folgendes kam dabei heraus: Hallo Gpc! Look at the source: program Bug; type tvect=record x,y,z:real; end; operator + (a,b:tVect) r:tVect; begin r.x:=a.x+b.x; r.y:=a.y+b.y; r.z:=a.z+b.z; end; {BTW - here it warns "return value not assigned" - GCC relict?} type tNotOK=array[1..5] of tvect; (* tIsOk=array[1..5] of record p:tvect end;*) var a,b:tvect; prob:tNotOk; r:tvect; begin r:=a+b; {works fine} r:=b+prob[1]; {doesn't :-(} a:=prob[1];r:=a+b; {Does} end. Chris --- HomeBox : Chateau - +49(0)8677 911940(V.34) 911941(ISDN) *! New Address - C.Wendt(a)chateau.line.org !* ## CrossPoint v3.11 ##

1 0

Re: Word types...
by Frank Heckenbach 23 Jun '97

23 Jun '97

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

2 1

Re: :-) ARRAYS BUG; preparing next GPC ...
by Peter Gerwinski 22 Jun '97

22 Jun '97

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]

1 0

Re: :-) ARRAYS BUG
by Bernhard Tschirren 22 Jun '97

22 Jun '97

>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/

1 0

Re: Word types...
by Peter Gerwinski 22 Jun '97

22 Jun '97

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]

1 0

Re: :-) ARRAYS BUG
by Peter Gerwinski 22 Jun '97

22 Jun '97

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]

1 0

Re: Ignoring function return values
by Frank Heckenbach 21 Jun '97

21 Jun '97

Peter Gerwinski wrote: > Perhaps `--ignore-function-return'? or `--ignore-function-results'? -- 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

1 0

Re: Word types: Suggestion
by Frank Heckenbach 21 Jun '97

21 Jun '97

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

1 0

:-) ARRAYS BUG
by Bernhard Tschirren 21 Jun '97

21 Jun '97

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/

1 0

Re: Initialized record fields
by Peter Gerwinski 21 Jun '97

21 Jun '97

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]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc