Gpc

gpc@gnu.de

5400 discussions

None
by chris＠bockermann.ping.de 16 Nov '97

16 Nov '97

Subject: variant records and packed arrays To: gpc(a)hut.fi Date: Sun, 16 Nov 1997 13:12:13 +0100 (MET) From: "Christian Bockermann" <chris(a)bockermann.ping.de> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1971 Hello everyone ! I have a little question concerning variant records and packed arrays. In schoolwe wrote a little program with a declaration part like this : var x : RECORD CASE Boolean OF False :( rec:Record name : String[3]; number : integer; end); true :( field:packed array [0..47] of boolean ); end; The consequence was that the record (rec) and the array (field) were settled in the same area in memory. So this area could be interpreted as a field of bits or a record of a string an an integer variable. This was done on a Mac with Think Pascal :-(, but I'm unable to do something like this on my Linux-Box. The rest of my program looks like this : procedure print_out; var i :integer; begin write('binary decoding :'); for i:=0 to 47 do begin if x.field[i] then write('1') else write('0'); if i MOD 8 = 7 then write (' '); end; end; begin x.rec.name:='AB'; x.rec.number:=9; writeln(x.rec.name, x.rec.number); print_out; end. So I expected the output to be 1.) the binary decoding of the length of the string, like 00000010 2,3.) binary decoding of the ascii-code of the characters in the string, like 01000001 01000010 4.) some 8 random bits 01010101 or something similar... 5.) the 16-bit decoding of the integer variable, like 00000000 00001001 The output I get is : 1.) 2.) 3.) 4.) 5.) 6.) binary decoding :00000000 00000000 00000000 00000001 10000000 00000000 Does anybody know, what I did wrong ? Is it possible in another way to access and change some bits of a string of any other variable with the use of GPC ? If anybody can help ... THANKS a lot !! -- Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key) -- Bis denn, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

`case' statments: `default' and `others'
by Peter Gerwinski 15 Nov '97

15 Nov '97

Hello, everybody! I am currently fixing the bug with `otherwise' in `case' statements. While the ISO 10206 Extended Pascal standard wants case foo of (* 1 *) bar: writeln ( 'foobar!' ); otherwise write ( 'The answer is: ' ); writeln ( answer ); end (* case *); GPC implemented case foo of (* 2 *) bar: writeln ( 'foobar!' ); otherwise: begin write ( 'The answer is: ' ); writeln ( answer ); end (* otherwise *); end (* case *); which is simply wrong. Okay - when I fix it, does anybody want to keep an optional colon after `otherwise'? Or after `else' in the Borland syntax? (I would prefer if *not*.) I also found `default' and `others' as synonyms for `otherwise' which I would like to remove. May I? Or are they needed for compatibility with some Pascal compiler I am not aware of? If so, what is the syntax? Example 1 or 2 above? While I am on it, what about removing `&' as an address operator and to keep only the BP-compatible `@'? Please post your opinions here. Thanks, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Re: probs compiling current beta GPC
by Peter Gerwinski 15 Nov '97

15 Nov '97

According to Clyde Meli: > > Now I attempted to compile the beta but I ran into problems again, this time > with parse.y (I've recompiled bison again - version 1.25 - from what I tried > to check I found it should be the latest version) and using the new > parse.h which you gave me. Now I got the following errors: > [...] > parse.y:752: warning: implicit declaration of function `pedwarn' > parse.y:755: warning: implicit declaration of function `initialize_module' > parse.y:756: `current_module' undeclared (first use this function) This looks for me as if your `parse.c' does not include the correct header files. Maybe your `bison' behaves different than mine and stores `#include's in `parse.h' rather than `parse.c', so my version of `parse.h' does not work with your `parse.c'? To proceed, I suggest to `mv' away `parse.c' and my `parse.h' and to reconstruct both with your `bison'. Also check which files your `parse.c' does `#include'. Hope this helps a little, :-/ Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Type conversions
by Peter Gerwinski 15 Nov '97

15 Nov '97

According to Hans Ecke: > > I think I was a little bit lazy in my question. Of course I meant: What is > the schema of type conversion between the members of the ordinal,real and > string type familys. I.e. what happens internally and what does the > compiler ... This is a nontrivial question. The complete answer is the function `convert_for_assignment()' in the GPC source file `gpc-typeck.c'. When passing parameters, other conversions are made, see the function `convert_arguments()', also in `gpc-typeck.c'. Just a few general guidelines: - Strings are truncated, where necessary. - According to Extended Pascal, char variables may get a string value assigned :-( which results in the assignment of the first character or a space in case of the empty string. (GPC warns about this.;-) - If you assign a value to a variable of a compatible, but shorter type, *no* run-time checks are currently done to ensure that the result will fit in the variable. This is planned for gpc-2.2. > ... if there are lines like > > var i:integer; > l:longint; > > r:real; > e:extended; > > s:string(255); > p:pchar; > begin > i:=l; Silently truncated; overflows are not caught. > e:=r; Works without problem. (`Extended' may also be called `LongReal'.) > p:=s; This works if you enable extended syntax (*$X+*). Then the pointer will point to the first character in the string; the capacity and the length of the string are ignored. Please not that GPC does *not* (yet!;-) automatically append a `chr ( 0 )' to the string. > end. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Type problem
by Peter Gerwinski 15 Nov '97

15 Nov '97

According to Jim Brander: > > The cygwin32 version of gpc > gives "invalid operands to binary = " > for comparison of types in following test program. The compiled CygWin32 version of GPC is a little behind the current (beta) state, sorry. The program works well with more recent versions of GPC. Until a recent CygWin32-GPC will be available, maybe an explicit type cast will help? I know that older versions of GPC have problems with subranges of enumerated types ... Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Bug report
by Frank Heckenbach 15 Nov '97

15 Nov '97

Krzysztof Gozdziewski wrote: > I have found a strange behaviour of the gpc compiler, > when reading real numbers, having the form > x.xxe+00 > They are converted to 0. > > [...] > > /home/chris/Gravity>gpc --version > 2.0(2.7.2.1) GPC 2.0 is quite an old version (almost a year old now...). I recently rewrote the reading of real numbers completely, and with my code, your example works fine. The new code is not yet present in the latest beta version in GPC, but will be there in the next version to appear. It will be announced here in the list, not too far in the future, I think. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Bug report
by Krzysztof Gozdziewski 15 Nov '97

15 Nov '97

Hello! I have found a strange behaviour of the gpc compiler, when reading real numbers, having the form x.xxe+00 They are converted to 0. The sample session follows. Thanks. Krzysztof Gozdziewski /home/chris/Gravity>uname -a Linux ecia 2.0.30 #2 Sat Sep 27 15:42:44 MET DST 1997 i486 /home/chris/Gravity>gpc --version 2.0(2.7.2.1) /home/chris/Gravity>more test.p program testbug; var a : real; begin writeln('Enter 1.0e+00 to reproduce the error'); readln( a ); writeln( 'a = ', a ); end. /home/chris/Gravity>gpc test.p /home/chris/Gravity>a.out Enter 1.0e+00 to reproduce the error 1.0e+00 a = 2.1883084e-314 /home/chris/Gravity>a.out Enter 1.0e+00 to reproduce the error 2 a = 2.0000000e+00 -- ^-^ ~ Krzysztof Gozdziewski (o o) ~ Torun Centre for Astronomy =*= ~ Gagarina 11, PL-87-100 Torun, POLAND (m_m) ~ http://www.astri.uni.torun.pl/~chris

1 0

Type problem
by Jim Brander 15 Nov '97

15 Nov '97

Many thanks for directions to obtaining cygwin version of gpc. The cygwin32 version of gpc gives "invalid operands to binary = " for comparison of types in following test program. program testtype; type logstate1= (nyk1,uke1,error1,false_p1,true_p1); array_record1 = record state1: logstate1; actual : real; end; type info_array1 = array[0..100] of array_record1; var pinfo:info_array1; begin if (pinfo[3].state1 = nyk1) then pinfo[3].state1 := nyk1; if (pinfo[3].actual = 123.0) then pinfo[3].actual := 456.0; end. Regards Jim Brander

1 0

Type conversions (was: 2 suggestions about Units)
by Peter Gerwinski 14 Nov '97

14 Nov '97

According to Hans Ecke: > > [...] > > A last question: What is the schema of the automatic type-conversion? Is > there a global schema for converting between ordinal,real and string types > or is it only done from case to case? What do you mean by "automatic type-conversion" between ordinal, real, and string types? Assignments like "ordinal:= real" or "string:= integer" are - of course - simply illegal in Pascal. You can assign an integer to a real, but not vice versa. Am I missing something? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Variant records, my bad =B)...
by Orlando Llanes 13 Nov '97

13 Nov '97

A short time ago, I said that there was a quirk in BP's SizeOf when it comes to variant records. I haven't tested it in GPC, tho I'm sure it works the same. But I digress, the point is that when I saw the CASE ... structure in other Pascal programs, it must've reported a bigger size because one of the field blocks was bigger than the rest. Hence my calling it a quirk, but as it turns out, it's not a quirk, so I will now go boot myself in the rear now :P See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

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