Gpc

gpc@gnu.de

5400 discussions

Re: Bug? Variants don't overlay when they contain strings
by Frank Heckenbach 30 Dec '99

30 Dec '99

David James wrote: > Should the different variants in a variant record overlay in the same > memory? > > Previous Pascals I have used have guaranteed this, and I've got > low-level code that relies on this. > > [...] > > (I know the variants are not the same length, and they are intended > not to be.) As you assumed in your latter mail, this is intentional so the discriminants are not overwritten, and they can be properly initialized in the first place. Consider: record case Boolean of False: (s1 : String (42)); True: (s2 : String (99)); end; If the strings would overlay, in particular their disriminants would occupy the same place in memory. How should it be initialized? Either way, it would be wrong for at least one of the variants... So, after a discussion in comp.lang.pascal.ansi-iso where this topic came up concerning file variables (which also require some automatic initialization and finalization), we decided to do this in GPC for all types with automatic initialization and finalization (currently files and schemata, in the future this might also be Delphi compatible classes and user-defined initialized and finalized types), since the standard does not guarantee variants to overlay, anyway... There are two ways in GPC to get guaranteed overlaying (both non-standard, of course, since the standard does not assume anything about internal representations; both BP compatible), `absolute' declarations and variable type casts. E.g., in order to overlay a byte array to a variable v: var b: array [1 .. SizeOf (v)] of Byte absolute v; or type t = array [1 .. SizeOf (v)] of Byte; then `t (v)' can be used as a byte array overlayed to v. Russ Whitaker wrote: > You have more than an overlay problem. In standard pascal you expect ic[ 1 > ] to align > with the first character position of s and thus one character to the left > is the length of s. > Thus ic[0] is the length of s. This holds for UCSD/BP strings (which GPC does not yet implement, but that's planned). The only strings Standard Pascal knows are arrays of char without any length value. > Two different kinds of strings with the same name - string - does make a > bit of confusion. Perhaps the > oldstyle strings could be renamed "short string" ?? ( didn't think > changing the spelling to "stwing" > would fly ) When we implement the short strings, we'll have to do such a distinction. Our current planning goes like this: string (n): string schema (EP compatible) string [n]: short string (UCSD/BP compatible, where n must be <= 255) string: dependent on flags, by default undiscriminated schema, but in BP mode (or with a special switch) short string of capacity 255 (UCSD/BP compatible). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Bug? Variants don't overlay when they contain strings
by Russ Whitaker 29 Dec '99

29 Dec '99

Hi David James wrote: > Subject: Bug? Variants don't overlay when they contain strings > Date: Tuesday, December 28, 1999 11:25 AM > > Should the different variants in a variant record overlay in the same > memory? > > Previous Pascals I have used have guaranteed this, and I've got > low-level code that relies on this. > > The simple example below shows that this is not true for GPC - the version > as reported by gpc -v is: > Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs > gpc version 19991030, based on 2.95.2 19991024 (release) > > The output from the program is: > > addr of i is: -1073742896 > addr of s is: -1073742760 > addr of ic is: -1073742668 > > program daj15(input,output); > type trec = record > case integer of > 1:(i:array [1..34] of integer); > 2:(s:string(80)); > 3:(ic:packed array[0..79] of char); > end; > > var r:trec; > > procedure sub(r:trec); > begin > writeln('addr of i is: ',integer(addr(r.i)):1); > writeln('addr of s is: ',integer(addr(r.s)):1); > writeln('addr of ic is: ',integer(addr(r.ic)):1); > end; as an aside, if you change the cast "integer" to "cardinal" the output will be a positive number > > begin > sub(r); > end. > > If the string s is removed from the record, then the same address is > reported for i and ic. > You have more than an overlay problem. In standard pascal you expect ic[ 1 ] to align with the first character position of s and thus one character to the left is the length of s. Thus ic[0] is the length of s. In extended pascal there is 8 bytes to the left of the first charactor position makingt ic[ 0 ] useless So you end up leaving s out of Trec but what you can do is index s like an array[ 1..CAPACITY] and use Setlength when you need to. Two different kinds of strings with the same name - string - does make a bit of confusion. Perhaps the oldstyle strings could be renamed "short string" ?? ( didn't think changing the spelling to "stwing" would fly ) Russ <russwhit(a)mind.net>

1 0

Re: Bug? Variants don't overlay when they contain strings
by david＠tcs01.demon.co.uk 29 Dec '99

29 Dec '99

In message <199912292231.OAA17912(a)ego.mind.net> "Russ Whitaker" writes: > Hi > David James wrote: > > Subject: Bug? Variants don't overlay when they contain strings > > > > Should the different variants in a variant record overlay in the same > > memory? > > > > You have more than an overlay problem. In standard pascal you expect ic[ 1 > ] to align > with the first character position of s and thus one character to the left > is the length of s. > Thus ic[0] is the length of s. > > In extended pascal there is 8 bytes to the left of the first charactor > position makingt ic[ 0 ] useless > So you end up leaving s out of Trec but what you can do is index s like an > array[ 1..CAPACITY] > and use Setlength when you need to. In this artificially simple example, yes; however my real-life example is much more complicated, some of the variants are themselves records which contain strings, the aim was to get a byte array which was overlaid on all the variants (which is then sent over a network connection to another machine where an identical variant record receives bytes into the byte array and then uses the appropriate variant). I can work around the problem (by throwing away the variant record, keeping the individual variants and copying them to the byte array as needed). My question is still: should variants overlay in memory? I think I understand why they don't (I assume it's so that the string capacities do not get smashed by the other variants), but it's a nasty feature that could do to be highlighted in the documentation (maybe it is, but I haven't found it). -- David James mailto:david@tcs01.demon.co.uk

1 0

using Crt unit
by Matija Papec 28 Dec '99

28 Dec '99

Hello all! I would like to hear someone who does not have problems using Crt unit on Linux. On Mandrake6.1 (distribution very similar to RedHat), gpc says the following: ---- gpc -c -g --automake /home/mpapec/pas/dumy.pas -o ./dumy.o /tmp/cc8xNyqX.s: Assembler messages: /tmp/cc8xNyqX.s:6193: Error: Symbol `Initexec' can not be both weak and common /tmp/cc8xNyqX.s:6193: Error: Symbol `Doneexec' can not be both weak and common gpc1: gpc exited with status 1 crt.pas:345: `/usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/crtc.c' could not be compiled ---- and these are problematical lines: --file:crtc.c-- /* Assign the Dos unit's variables to the following routines to be called before and after Exec. If Dos is not used, create dummies here. */ void (*Initexec)() __attribute__((weak)); void (*Doneexec)() __attribute__((weak)); ---- What should be putted here? TIA :)

2 1

UNSUBSCRIBE
by Claude Roy 28 Dec '99

28 Dec '99

croy(a)osiris.com Claude Roy President Osiris inc. croy(a)osiris.com http://www.osiris.com

1 0

UNSUBSCRIBE
by Ed Way 28 Dec '99

28 Dec '99

1 0

Bug? Variants don't overlay when they contain strings
by david＠tcs01.demon.co.uk 28 Dec '99

28 Dec '99

Should the different variants in a variant record overlay in the same memory? Previous Pascals I have used have guaranteed this, and I've got low-level code that relies on this. The simple example below shows that this is not true for GPC - the version as reported by gpc -v is: Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 19991030, based on 2.95.2 19991024 (release) The output from the program is: addr of i is: -1073742896 addr of s is: -1073742760 addr of ic is: -1073742668 program daj15(input,output); type trec = record case integer of 1:(i:array [1..34] of integer); 2:(s:string(80)); 3:(ic:packed array[0..79] of char); end; var r:trec; procedure sub(r:trec); begin writeln('addr of i is: ',integer(addr(r.i)):1); writeln('addr of s is: ',integer(addr(r.s)):1); writeln('addr of ic is: ',integer(addr(r.ic)):1); end; begin sub(r); end. If the string s is removed from the record, then the same address is reported for i and ic. (I know the variants are not the same length, and they are intended not to be.) -- David James mailto:david@tcs01.demon.co.uk

1 0

compiling gpc units
by Dr A Olowofoyeku 24 Dec '99

24 Dec '99

Hi all I have been following the threads on compiling the GPC units for a while. A simple solution is an empty program that USEs all the units - build that program, and all the units are built automatically. Here is my version; {**********************************************************************} {**********************************************************************} {************** A program to build the main GPC units *****************} {*************** run 'gpc --autobuild -O2 build.pas' *****************} {**********************************************************************} {**********************************************************************} Program Build; USES crt, dos, dosunix, gmp, gpc, gpcutil, heapmon, overlay, pipe, ports, printer, regex, strings, system, trap, turbo3, windos; Begin End. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.21.1 for Win32 http://ourworld.compuserve.com/homepages/African_Chief/chief521.zip

1 0

Re: could not compile crt.pas
by Frank Heckenbach 23 Dec '99

23 Dec '99

Mason Ip wrote: > I wrote: > > BTW, this little script could build all the units (except > gpc-bp.pas for BP, not for GPC). > > > /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> cat > build_units > > #!/bin/sh > > for file in `ls *.pas` > > do > > gpc -c $file > > done > > Oooop... forgot to say : > Run this script twice; the first run build those units without > dependancy on the others; the second run build the remainder. Dirty and > quick :) I think you can just use `--automake' in this script to avoid the problem... BTW, ls is not really needed, just `for file in *.pas' will do. Well, in fact, you can even do `gpc --automake -c *.pas', I just tried it... :-) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

RE: could not compile crt.pas
by Mason Ip 23 Dec '99

23 Dec '99

I wrote: > BTW, this little script could build all the units (except gpc-bp.pas for BP, not for GPC). > /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> cat build_units > #!/bin/sh > for file in `ls *.pas` > do > gpc -c $file > done Oooop... forgot to say : Run this script twice; the first run build those units without dependancy on the others; the second run build the remainder. Dirty and quick :)

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