Gpc

gpc@gnu.de

5400 discussions

.asm compilation problems
by Kocherlakota Harikrishna 14 Dec '00

14 Dec '00

We are in the process of porting pascal sources compatable to windows NT to Red Hat Linux . Our GPC installation is OK and we are able to compile and run some simple pascal programs. We have difficulty in compiling assembly (.asm) files which are written in MASM 5.0 for Intel processor. As we find that GPC supports AT&T syntax, Should we need to change the entire intel syntax into AT&T syntax ? . We find the command " .intel_syntax noprefix" supporting the compilation, though not for all statements. As our programs are 16 bit and GPC is a 32 bit compiler, could u please tell us if there is any tool for automatic conversion ? can you also help us in knowing how GPC (gas) interprets the keywords " STRUC " and " TEST " etc..? >From as.info We got good amount of information but we find it is not sufficient .We also had a good look at the asm sources in the gas/testsuite/ directories. thanks and regards hari

1 0

Help getting compiler to compile
by Patrick Sharp 13 Dec '00

13 Dec '00

Greetings all, I have installed the latest beta binary (gpc-19990118-egcs-1.1.1-i586-pc-linux-gnulibc1) on my Redhat system. gcc --version reports egcs-2.91.66 Any source, including the demos, that I try to compile produces the following error message: /tmp/<filename>.i:1: numeric constant with no digits /tmp/<filename>.i:1: numeric constant with no digits /tmp/<filename>.i:1: invalid #line /tmp/<filename>.i:1: warning: missing program header /tmp/<filename>.i:1: parse error at null character I've gone through the documentation and have not been able to resolve this problem. Has anyone else run into this? Thanks in advance, -Pat pat(a)communitywebs.com ---SORRY FOR THIS REPEAT MESSAGE-- Our mail server crashed and it's acting weird.

1 0

Problems with making gpc under Irix6.5
by Hans Hauska 10 Dec '00

10 Dec '00

Hi, I am trying to make a version of gpc on an Irix6.5 system with MIPS Compiler 7.3. I have built gcc (version 2.95.2) separately and it seemed OK. When trying to make pascal.install (version gpc-20001122) i run into a stop after some time. I had problems with mixing o32 and n32, as 6.5 prefers the latter, but that seems fixed. However, I have not been able to find where the error occurs. Is there someone out there with more experience and knowledge regarding SGI systems? The make stops with the following message (some lines above) there is some more before it...... "CC=cc -n32" "CROSS=" "X_CFLAGS=" "EXTRA_LIBS=" "MAYBE_TARGET_DEFAULT=" "MAYBE_USE_COLLECT2=" "SCHED_CFLAGS=" "includedir=`echo '/usr/local/include'|sed -e 's/\\$/\\\\&&/g'`" "libsubdir=`echo '/usr/local/lib/gcc-lib/mips-sgi-irix6.5/2.95.2'|sed -e 's/\\$/\\\\&&/g'`" "target_alias=mips-sgi-irix6.5" "version=2.95.2" "target_alias=mips-sgi-irix6.5" "program_transform_name=s,x,x," "program_transform_cross_name=s,^,mips-sgi-irix6.5-," "exeext=" "GCC_FOR_TARGET=./xgcc -B/usr/local/mips-sgi-irix6.5/bin/ -B./ -I/usr/local/mips-sgi-irix6.5/include" "GPC_FOR_TARGET=./xgpc -B./" "GPCSOLIBSHORTNAME=libgpc.so" "GPCSOLIBDIR=lib" "WITH_SHARED=@with_shared@" ../gpc1 echo " `cat ../stamp-objlist | sed -e 's: : :g' -e 's:../convert.o::g' -e 's:../dbxout.o::g' -e 's:../expr.o::g' -e 's:../fold-const.o::g' -e 's:../function.o::g' -e 's:../optabs.o::g' -e 's:../stor-layout.o::g' -e 's:../toplev.o::g' -e 's:../tree.o::g'` convert.o dbxout.o expr.o fold-const.o function.o optabs.o stor-layout.o toplev.o tree.o" >stamp-gbe cc -n32 -c -DIN_GCC -DGPC -g -Wall -I. -I.. -I. -I./.. -I./../config -I./../../include gpc-common.c cc ERROR parsing -Wall: bad syntax for option cc ERROR parsing -Wall: unknown flag *** Error code 2 (bu21) *** Error code 1 (bu21) Your advice is appreciated, however I am not subscribed to the mailing list. Thanks in advance Hans Hauska -- __________________________________________________________ Hans Hauska phone: +46-8-790 7341 Assoc. Prof. and fax: +46-8-790 7343 Director, Centre for geoinformatics e-mail: hans(a)geomatics.kth.se Dept of geodesy and photogrammetry personal phone (GSM): +46-70-764 8269 KTH S-100 44 Stockholm Sweden WWW address CGI: http://www.ce.kth.se/geofoto/CGI/ HH's home page: http://www.geomatics.kth.se/~hans __________________________________________________________

2 1

bounds checking
by Russ Whitaker 10 Dec '00

10 Dec '00

Hi At site gcc.gnu.org, under 'Extensions', there is a blurb on bounds checking. Included is a pointer to <www.inter.NL.net/hcc/Haj.Ten.Brugee>. (also note the gcc group *eventually* plans to go the fat-pointer method.) Downloaded a tar.gz file fromm Haj.Ten.Brugee's site. Tried to compile gcc + bounds + gpc but got an undefined reference error about half way thru stage1. However, there is a nice write-up about bounds checking, several methods to do it, and why he chode the one he did. Based on that write-up, here's a pascal example: program bounds2; type a = array[1..10] of integer; var i : integer; x,y : a; begin for i := 1 to 100 do begin x[i] := i; y[i] := i; end; for i := 1 to 20 do writeln( x[i], ' ', y[i] ); end. So my query is: why not include bounds checking for pascal source? Thanks, Russ

1 0

strange bug in test gpc20001122 / djgpp
by Maurice Lombardi 06 Dec '00

06 Dec '00

Hi After seing the message of Russ I have also run the tests for this snapshot. (djgpp v2.03 in W98 DOS box). No problem with gpctest.pas (the unmodified one). Two skipped as usual: longr2 (no long real in djgpp OK), fjf165a (no german locale OK). But six failed, whereas last time I did it (one or two month ago IIRC) none failed: fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas After cleaning everything, rebooting (W98 you know), I obtain simplified test by booting bash and running directly test_run as ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >ta i.e. on all failing test program and one successfull test program. The result is GPC-TEST-BEGIN ========================== TEST fieldw.pas: c:/djgpp/tmp\ccbq0vjj1.o: In function `pascal_main_program': fieldw.pas:11: undefined reference to `_p_writestr' fieldw.pas(.text+0x5e): undefined reference to `_p_inoutres' fieldw.pas(.text+0x66): undefined reference to `_p_check_inoutres' fieldw.pas:16: undefined reference to `_p_writestr' fieldw.pas(.text+0xb8): undefined reference to `_p_inoutres' fieldw.pas(.text+0xc0): undefined reference to `_p_check_inoutres' fieldw.pas:18: undefined reference to `_p_stdout' fieldw.pas(.text+0xe3): undefined reference to `_p_write' fieldw.pas(.text+0xec): undefined reference to `_p_inoutres' fieldw.pas(.text+0xf4): undefined reference to `_p_check_inoutres' fieldw.pas:20: undefined reference to `_p_stdout' fieldw.pas(.text+0x116): undefined reference to `_p_write' fieldw.pas(.text+0x11f): undefined reference to `_p_inoutres' fieldw.pas(.text+0x127): undefined reference to `_p_check_inoutres' fieldw.pas:22: undefined reference to `_p_atexit' fieldw.pas(.text+0x182): undefined reference to `_p_initialize' fieldw.pas(.text+0x191): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed TEST fjf101a.pas: c:/djgpp/tmp\ccbycwjj1.o: In function `pascal_main_program': fjf101a.pas:6: undefined reference to `O' fjf101a.pas:7: undefined reference to `K' fjf101a.pas(.text+0x2b): undefined reference to `init_Fjf101au' fjf101a.pas(.text+0x30): undefined reference to `init_Fjf101av' fjf101a.pas(.text+0x3d): undefined reference to `_p_atexit' fjf101a.pas(.text+0x66): undefined reference to `_p_initialize' fjf101a.pas(.text+0x75): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed <snip same for others> TEST abso1.pas: OK ========================== GPC-TEST-END All fail at link stage and this is bogus since all other test succeed to find these functions. I then played with the options by typing e.g. PFLAGS="--autobuild -g -O3 -Wall -Werror" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tb This changes nothing since there are the default PFLAGS. But I found then that things go wrong only if I have exactly _five_ PFLAGS, what they may be (I have always included --autobuild, but tried e.g. -g -g -g -g), and succeed for four or six (or any number I have tried). So I replace the fifth by -v, typing PFLAGS="--autobuild -g -O3 -Wall -v" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tb The output is: GPC-TEST-BEGIN ========================== TEST fieldw.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccaakjgj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -g -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./fieldw.pas c:/djgpp/tmp\ccbakjgj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbakjgj.i -quiet -dumpbase fieldw.pas -g -O3 -Wall -version -famtmpfile=c:/djgpp/tmp\ccaakjgj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbakjgj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbakjgj1.o c:/djgpp/tmp\ccbakjgj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbakjgj1.o -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/tmp\ccbakjgj1.o: In function `pascal_main_program': fieldw.pas:11: undefined reference to `_p_writestr' fieldw.pas(.text+0x5e): undefined reference to `_p_inoutres' fieldw.pas(.text+0x66): undefined reference to `_p_check_inoutres' fieldw.pas:16: undefined reference to `_p_writestr' fieldw.pas(.text+0xb8): undefined reference to `_p_inoutres' fieldw.pas(.text+0xc0): undefined reference to `_p_check_inoutres' fieldw.pas:18: undefined reference to `_p_stdout' fieldw.pas(.text+0xe3): undefined reference to `_p_write' fieldw.pas(.text+0xec): undefined reference to `_p_inoutres' fieldw.pas(.text+0xf4): undefined reference to `_p_check_inoutres' fieldw.pas:20: undefined reference to `_p_stdout' fieldw.pas(.text+0x116): undefined reference to `_p_write' fieldw.pas(.text+0x11f): undefined reference to `_p_inoutres' fieldw.pas(.text+0x127): undefined reference to `_p_check_inoutres' fieldw.pas:22: undefined reference to `_p_atexit' fieldw.pas(.text+0x182): undefined reference to `_p_initialize' fieldw.pas(.text+0x191): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed <snip> TEST abso1.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccayplgj -fautobuild -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -g -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./abso1.pas c:/djgpp/tmp\ccbyplgj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbyplgj.i -quiet -dumpbase abso1.pas -g -O3 -Wall -version -famtmpfile=c:/djgpp/tmp\ccayplgj -fautobuild -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbyplgj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbyplgj1.o c:/djgpp/tmp\ccbyplgj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbyplgj1.o -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/bin/stubify.exe -v a.out stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: a.out -> a.000 -> a.exe OK ========================== GPC-TEST-END On inspection, in the linking stage (collect2) -lgpc -lm are not inserted in the failing cases, whereas they do are in the successfull case. To check I type (only four PFLAGS) PFLAGS="--autobuild -g -O3 -v" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tc and the result is GPC-TEST-BEGIN ========================== TEST fieldw.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccaaqypj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -g -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./fieldw.pas c:/djgpp/tmp\ccbaqypj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbaqypj.i -quiet -dumpbase fieldw.pas -g -O3 -version -famtmpfile=c:/djgpp/tmp\ccaaqypj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbaqypj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbaqypj1.o c:/djgpp/tmp\ccbaqypj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbaqypj1.o -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/bin/stubify.exe -v a.out stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: a.out -> a.000 -> a.exe OK <snip> all other succeed and you see that -lgpc -lm are there ! I cannot say more, especially if it is only a gpc bug, of if djgpp plays a role. Hope this helps. -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 2

with statement using tags (for the gpc wish list)
by Tom Verhoeff 05 Dec '00

05 Dec '00

I would like to propose to include in gpc the "tagging feature for with statements" as found in (the now obsolete) Sun Pascal. Example: program WithTag; type Rec = record i: integer; r: real; ... end; var c, d, e: char; a: array [ char, char ] of Rec; begin readln ( c, d, e ) ; with a [ UpCase(c), d ] : x, a [ succ(d), e ] : y do begin ; y.r := sqrt ( x.i ) ; ... end { with } end. This way, you introduce shorthand names (the tags) for records. This is especially interesting when these records are of the same type (as in the example above), or when the records share field names (because then the records cannot be distinguished on the basis of the field name only). The addresses of the records in the with statement are determined once (and associated with the tag). This cannot easily be accomplished otherwise in general, especially when the records are big, and the address involves some "expensive" address calculation (indexing in multiple dimensions). When records are small, you can copy the contents to a local record variable; otherwise, you have to use explicit pointers, or work with an auxiliary procedure and parameters: procedure WithTwoRec ( const x, y: Rec ); begin ; y.r := sqrt ( x.i ) ; ... end; begin readln ( c, d, e ) ; WithTwoRec ( a [ UpCase(c), d ], a [ succ(d), e ] ) end. Cheers, Tom Verhoeff

2 1

GetUnixTime, GetCPUTime
by Tom Verhoeff 04 Dec '00

04 Dec '00

I am using gpc version 20001122 under Linux and want to call GetUnixTime and GetCPUTime. These functions are mentioned under Run Time System and appear in gpc.pas, but the compiler does not recognize them. I can use GetTimeStamp, but I would like to use the others. What do I do wrong? I have no special options selected. Example: program TimeTest; begin writeln('Test for date/time functions') ; writeln(GetUnixTime(null)) ; writeln(GetCPUTime(null)) end. $ gpc -o time-test time-test.p time-test.p: In function `pascal_main_program': time-test.p:5: undeclared identifier `Getunixtime' (first use in this routine) time-test.p:5: (Each undeclared identifier is reported only once time-test.p:5: for each routine it appears in.) time-test.p:6: undeclared identifier `Getcputime' (first use in this routine) Thanks, Tom Verhoeff

2 1

gpc1 got fatal signal 11
by Nicola Girardi 03 Dec '00

03 Dec '00

Hi GPC'ers! Before I forget: Reading specs from /usr/local/stow/gpc-CVS/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20001116, based on 2.95.2 19991024 (release) The following test program crashes GPC. Maybe my statement is not legal, but anyway the compiler should just complain, not just lie down and die. : program Test; : : type : PT1 = ^T1; : PT2 = ^T2; : : type : T1 = record : a : Integer; : b : Real; : end; : T2 = record : a : Integer; : b : Real; : end; : : begin : end. Splicing together the type definitions, the program compiles fine. So there's no real problem for me, except that I think the compiler should just complain. OTOH, I don't know if the statement was correct, either. : program Test; : : type : PT1 = ^T1; : PT2 = ^T2; : T1 = record : a : Integer; : b : Real; : end; : T2 = record : a : Integer; : b : Real; : end; : : begin : end. Greetings, -- Nicola Girardi, nikke(a)swlibero.org

2 1

latest gpc builds on i386-hurd again.
by Matthias Klose 01 Dec '00

01 Dec '00

at least for the Debian distribution ;-)

1 0

From C To Pascal, unions and variant records
by Eike Lange 01 Dec '00

01 Dec '00

Hi! Actually, I translate the Gdk (basically needed for Gtk) to Pascal and I need help with the following C-Struct: struct _GdkEventClient { ... GdkAtom message_type; gushort data_format; union { char b[20]; short s[10]; long l[5]; } data; }; How do I pass the union to a case-selector ? Eike

2 1

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