Gpc

gpc@gnu.de

5400 discussions

Re: [BUG] GPC - a char killer?
by Peter Gerwinski 11 Apr '97

11 Apr '97

According to Sven Engelhardt: The compiled program "eats up" the first char if standard input is not a terminal. This is because when `Input' is `reset' at startup, the first char is read in to `Input's file buffer variable. If you would `read' the char rather than `getchar'ring it, you would get it. To work around, use the `eoln' function to check whether a char has been read in like this: > program test1(input,output); > > function getchar:integer; C; > > var k:integer; > > begin if not eoln ( Input ) then k:= ord ( Input^ ) else > k:=getchar; > while (k<>-1) do > begin > writeln(k); > k:=getchar; > end; > end. To fix this bug (?) it would be necessary to rewrite parts of the RTS, but I am not sure whether we should do that because I can imagine that GPC's behaviour is as the ISO Standard requires. (But I am not in the position to judge that. ;-) 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/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Compiler switches (was: Configuration files)
by Peter Gerwinski 09 Apr '97

09 Apr '97

According to Frank Heckenbach: > Peter Gerwinski wrote: > > I am already doing this (in a portable way) for the AutoMake mechanism. > > There is an "internal" option `--amtmpfile=cc123456.gpc' which passes > > the name of a file containing the names of the `.o' files to be linked > > to the `gpc' driver program. > Sounds good! Is this a way to use compiler options (like -o, -l, .o files, > .c files) in the source? Yes, in principle. `.o' files *are* already passed that way. There might be some technical problems when generalizing this, but we will see ... Greetings, 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Configuration files (was: Standard compatibility)
by Frank Heckenbach 09 Apr '97

09 Apr '97

Peter Gerwinski wrote: > I am already doing this (in a portable way) for the AutoMake mechanism. > There is an "internal" option `--amtmpfile=cc123456.gpc' which passes > the name of a file containing the names of the `.o' files to be linked > to the `gpc' driver program. Sounds good! Is this a way to use compiler options (like -o, -l, .o files, .c files) in the source? > > If every option (except those like $R,$I,$S,$Q(?) that would be the same like > > BP's) would be at least 2 letters, this would avoid name clashes. > > Sounds reasonable. However I like the (*$W-*) ... (*$W+*) option as > a quick way to disable/enable warnings locally. (Sometimes one may > want to ignore a certain warning.) To have only (*$no-warnings*) > ... (*$warnings*) would be a little drawback ... No objections from me. BP doesn't have a $W option (except Windoze stack frame for Windoze platform, but I don't care very much about that), and $W for warnings sounds general enough to justify a one-letter switch. > > I'm not sure what this has got to do with it. Anyway, I think the biggest > > problem would be to collect all the options into one record (which might be > > quite hard if they're scattered among many modules now). Then, pushing and > > popping would reduce to storing/restoring this record to/from a (LIFO) stack. > > Please look at `toplev.c', `gpc-options.h', and `gpc-decl.c' to get an > overview. Seems like a lot of work... :-( -- 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

BP compatibility
by The African Chief 08 Apr '97

08 Apr '97

Hi all! Here are some more suggestions on Borland compatibility. The following code does not compile in GPC; Program Blah; type pChar = CString; { or ^Char} Procedure DoThis(aThis : pChar); Begin {blah, blah}; End; Begin DoThis ('This is the day!'); End. The compiler does not accept the parameter as being valid (you have to declare a pChar variable and all). This code would compile under Borland. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

GPC fails set comprare
by Jan-Jaap van der Heijden 08 Apr '97

08 Apr '97

Hello, Consider this little program: -------------------------------------------------------------- program main(input,output); var o, z: set of 1..15; begin o := [1]; z := []; if o < z then writeln('o < z'); if o <= z then writeln('o <= z'); if o = z then writeln('o = z'); if o <> z then writeln('o <> z'); if o >= z then writeln('o >= z'); if o > z then writeln('o > z'); if z < o then writeln('z < o'); if z <= o then writeln('z <= o'); if z = o then writeln('z = o'); if z <> o then writeln('z <> o'); if z >= o then writeln('z >= o'); if z > o then writeln('z > o'); if o < o then writeln('o < o'); if o <= o then writeln('o <= o'); if o = o then writeln('o = o'); if o <> o then writeln('o <> o'); if o >= o then writeln('o >= o'); if o > o then writeln('o > o'); if z < z then writeln('z < z'); if z <= z then writeln('z <= z'); if z = z then writeln('z = z'); if z <> z then writeln('z <> z'); if z >= z then writeln('z >= z'); if z > z then writeln('z > z'); end. -------------------------------------------------------------- GPC fails to compile this: t19.p: In function Program_Main': t19.p:7: invalid operands to binary < t19.p:17: invalid operands to binary > t19.p:19: invalid operands to binary < t19.p:29: invalid operands to binary > t19.p:31: invalid operands to binary < t19.p:41: invalid operands to binary > t19.p:43: invalid operands to binary < t19.p:53: invalid operands to binary > ISO 7185 sec. 6.7.1 suggests that this should work. The correct output should be: o <> z o >= z o > z z < o z <= o z <> o o <= o o = o o >= o z <= z z = z z >= z Greetings, JanJaap --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum

1 0

Re: Configuration files (was: Standard compatibility)
by Peter Gerwinski 07 Apr '97

07 Apr '97

According to Frank Heckenbach: > > So, if it get this right, one needs a way to pass data (in this case, strings) > back from a child process to the parent process. I don't know very much about > the available means of process communication, but isn't there any (portable) > way to do so? Perhaps a temp file, or can it be done easier? I am already doing this (in a portable way) for the AutoMake mechanism. There is an "internal" option `--amtmpfile=cc123456.gpc' which passes the name of a file containing the names of the `.o' files to be linked to the `gpc' driver program. > If every option (except those like $R,$I,$S,$Q(?) that would be the same like > BP's) would be at least 2 letters, this would avoid name clashes. Sounds reasonable. However I like the (*$W-*) ... (*$W+*) option as a quick way to disable/enable warnings locally. (Sometimes one may want to ignore a certain warning.) To have only (*$no-warnings*) ... (*$warnings*) would be a little drawback ... At least I will make GPC warn about incompatible compiler switches when invoked with `--borland-pascal'. (It already does with `--pedantic.) > BTW: The first input file name sounds a bit strange to me. Rather, it should > be the main program, I think. But it's probably not so easy to implement. That's the reason. This is handled by the `gcc' driver program which does not read the source. But we might be able to solve this with the `--amtmpfile' mechanism ... > I don't know how field widths are handled, but I would suppose (and I think > that's how BP does it) that the compiler would pass the given field width, > or if omitted, the (current) default field width to the write routine. They are handled differently in gpc-970401, but I just wanted to change GPC to use the method above. > [...] > > Anyway, this was only an example, compiler options in the source and local > options would be a plus anyway. I agree. I will look at this. (* I should set up a list of things I wanted to look at. A *long* list. ;*) > I'm not sure what this has got to do with it. Anyway, I think the biggest > problem would be to collect all the options into one record (which might be > quite hard if they're scattered among many modules now). Then, pushing and > popping would reduce to storing/restoring this record to/from a (LIFO) stack. Please look at `toplev.c', `gpc-options.h', and `gpc-decl.c' to get an overview. Greetings, 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Binary files.
by Peter Gerwinski 07 Apr '97

07 Apr '97

According to Berend De Schouwer: > > I'd like to read bytes from a file, so I looked at some of the examples. > I found an assign(file of byte...). Cool. It doesn't seem to > work to great tho... How big does it read? Are you sure its just 1 byte? Yes. See below for an example program which I just tested to work - with the alpha version gpc-970401. > How big is a byte anyway? 8 bits. :-) > Looking at the examples and the info file, > I get confused. Is an integer 16bit or 32bit? 32. > What happens with > type byte=0..255; It will take 4 bytes. :-( Sorry - this is a known bug. > I tried defining them like in the info file (using > __short__, etc.) but it doesn't compile. When I use the example's stuff > it does compile. See below for something which does compile. > Hmmm... I am converting some stuff from borland, and some from fpk, > so I would like to know how to get 8, 16 and 32 bit signed and unsinged > integers. I don't mind doing a search/replace on the source, but I do > need to know how big each thing is. The alpha version gpc-970401 has the following built-in types: Byte unsigned 8 bits ByteInt signed 8 bits ShortWord unsigned 16 bits ShortInt signed 16 bits Word unsigned 32 bits Integer signed 32 bits LongWord unsigned 64 bits LongInt signed 64 bits Single = ShortReal 32 Bits Double = Real 64 Bits Extended = LongReal 80 Bits on the PC, maybe 128 elsewhere However there is one known problem with these types: You cannot `write' or `writeln' them to text file. (Binary files are okay.) If you writeln ( a [ 7 ] ); with `a' being an array of bytes, you might get some very strange result because `writeln' outputs the integer consisting of `a [ 7 ]' and the following three bytes. To work around, cast these types to their base type: writeln ( Integer ( a [ 7 ] ) ); (The same holds for an `Extended' which you must cast to `Real' in order to `writeln' it.) > AND how to apply them properly to files ;) I hope the example below helps you. If you want to upgrade to gpc-970401, the URL is ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ Greetings, 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- test.pas ------------------------------------------------------------- {OK} (* This program will read its own source and output 'OK'. *) Program Test; Type ByteInt = __byte__ Integer; Byte = __unsigned__ ByteInt; ByteFile = file of Byte; Var F: ByteFile; C: Char; Procedure Assign ( Var T: ByteFile; Name: String ); Var B: BindingType; begin (* Assign *) unbind ( T ); B:= binding ( T ); B.Name:= Name; bind ( T, B ); B:= binding ( T ); end (* Assign *); begin Assign ( F, 'test.pas' ); reset ( F ); read ( F, C ); read ( F, C ); write ( C ); read ( F, C ); writeln ( C ); close ( F ); end.

1 0

Re: Configuration files (was: Standard compatibility)
by Frank Heckenbach 07 Apr '97

07 Apr '97

Peter Gerwinski wrote: > > Does this also include the "-o ..." option? In this case, this "problem" > > would also be solved by putting "{$o destname}" into the main program. > > That's problematic because the `-o' option is handled by the `gpc' driver > program, not by the `gpc-cpp' preprocessor or the `gpc1' compiler which > read the source. So, if it get this right, one needs a way to pass data (in this case, strings) back from a child process to the parent process. I don't know very much about the available means of process communication, but isn't there any (portable) way to do so? Perhaps a temp file, or can it be done easier? > > BTW: Are compiler options case sensitive? Otherwise there would be a possible > > confusion with BP's "{$O filename}" for overlays. > > GPC's compiler options are not intended to be compatible to Borland > Pascal's ones (except perhaps the most "basic" ones like $R, $I, $S > which are compatible between UCSD and Borland). These options are > too system-specific; especially the "overlay" option makes no sense > for GPC. I didn't expect them to be compatible. Of course, that wouldn't make much sense. But it might be better to avoid name clashes, so that ported BP programs woudln't accidentally acces gpc options (e.g. a BP program foo that declares an overlay {$O bar} should not be compiled to bar with gpc (if {$O ...} would be implemented). > But an `o' option (output file name) would crash with `O' > (optimization), so these options should be replaced by long names, > e.g. (*$output-file-name *) and (*$optimize *). If every option (except those like $R,$I,$S,$Q(?) that would be the same like BP's) would be at least 2 letters, this would avoid name clashes. > Here I agree. BTW, EMX derives the name of the output file name from > that of the first input file name. Fine for EMX users... BTW: The first input file name sounds a bit strange to me. Rather, it should be the main program, I think. But it's probably not so easy to implement. > > In such a way that they can be changed at any point in the source, like in > > this (extreme and not very sensible) example: > > write({$field-widths=0,0,0}a,{$field-widths}b) > > This requires additional work due to the method how field widths are > handled by the run time system. It would be easier to make the default > field widths variables accessible to your program, e.g. if you write > > Var > DefaultIntegerWidth: asmname 'default_int_width' Integer; > DefaultRealWidth: asmname 'default_real_width' Integer; > DefaultBooleanWidth: asmname 'default_bool_width' Integer; > > Then you can save their values in local variables and restore them > later ... I don't know how field widths are handled, but I would suppose (and I think that's how BP does it) that the compiler would pass the given field width, or if omitted, the (current) default field width to the write routine. >From this, I would think that default fields widths don't need to be runtime variables, only internal variables of the compiler. > (* Why don't you want to compile your whole program with -O2? Because it's quite slow! Sorry to say that, but gpc is not so fast that I can neglect this issue completely, being a poor 486 user... > I would not release an unoptimized program as "production version". No, but I'm writing programs mostly for my own use, that I have to compile often (and therefore fast), and that have to run fast (but this always concerns only quite small portions os the code). In 5-10 years, this will not be an issue any more, but for now... Anyway, this was only an example, compiler options in the source and local options would be a plus anyway. > > This example also shows that it can be desirable to "push" and "pop" options. > > It would be better to write e.g. (tentative syntax): > > [...] > This would be relatively hard to implement. I will not do that in > the near future, but I wouldn't mind if somebody else would take care > of that. ;-) But we must ensure that this will not break existing > features of the preprocessor. Also remember that (*$foo*) can also be > written as #foo <eol> ... I'm not sure what this has got to do with it. Anyway, I think the biggest problem would be to collect all the options into one record (which might be quite hard if they're scattered among many modules now). Then, pushing and popping would reduce to storing/restoring this record to/from a (LIFO) stack. > > I installed just the > > necessary DJGPP stuff, do I need some more packages for symlinks? And do > > symlinks also work for executables, or only for files accessed from within > > DJGPP programs? > > Vice versa, they seem to work *only* for executables ... (?) Oh, I see, you mean the stubs. I thought you were talking about "real" symlinks, like e.g. symlinks with Linux' UMSDOS file system that don't really fit to DOS. -- 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: Standard Compatibility [was: Re: New Alpha]
by Frank Heckenbach 07 Apr '97

07 Apr '97

Nils Bokermann wrote: > I don't like the idea of a local (user) configuration file as GPC.CFG or > .gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler > which is a borland like compiler for standard, might there be a compile-time > switch? Let's consider something like > ./configure --try-to-be-a-borland-compiler or > ./configure --use-standard-pascal. I think, hardcoded options would be about the worst solution. Besides the reasons given by Jan-Jaap and Peter, consider compilers on multi-user systems. If e.g. in a school or university, different teachers used different language standards, their classes would need different compilers... :-( Personally, I think options that describe the source (e.g. language dialect, extended syntax, field widths) should be put into the source. Other people don't seem to like this idea, but anyway, there will be enough ways by using config files, aliases, scripts and/or environment variables, that should all be possible (more or less easy) on any system. > > - Naming the program gpc, spc, epc and bpc seems like a sensible way for > > Un*x, but on systems that don't support either hard or symbolic links > > (aka DOS), it would mean 4 separate binaries - probably not a good solution > > there (although those DOS users who want to do only Borland style could > > rename gpc.exe to bpc.exe). So this could be one, but not the only, way to > > choose the defaults. > > Isn't there a way by making *.BAT-Files in dos? That is something like a > shell-script, isn't it? Yes, that's right. Also, modern DOSes have something like aliases. Though they're not the same as symlinks, they can be used for this purpose. > Ok, I can imagine that Makefiles are a bit complicatet... And (hopefully) unnecessary for Pascal... :-) > As there a _too_ many programs which put there .foobar-File to my > home-directory I don't like the *.CFG or .foobarrc idea. If gpc whould be as > kind as it should, there should be a system-wide rc-file (That's ok to me) and > there _might_ be a users rc-file. But the user has to make it _manually_. I agree. I also don't like yet another config file in the home directory. > But GPC should _not_ rely on the system-wide rc-file, so that I (for my system) > can remove it an GPC does run. > > The system-wide file should IMHO also be installed manually (By the Sysadmin of > course). Also agreed, since on big sites, a global config file wouldn't make much sense anyway, since different users would want different preferences. -- 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

Binary files.
by Berend De Schouwer 07 Apr '97

07 Apr '97

Hi Sorry if this was handled in a FAQ, but I haven't found it. I'd like to read bytes from a file, so I looked at some of the examples. I found an assign(file of byte...). Cool. It doesn't seem to work to great tho... How big does it read? Are you sure its just 1 byte? How big is a byte anyway? Looking at the examples and the info file, I get confused. Is an integer 16bit or 32bit? What happens with type byte=0..255; I tried defining them like in the info file (using __short__, etc.) but it doesn't compile. When I use the example's stuff it does compile. Hmmm... I am converting some stuff from borland, and some from fpk, so I would like to know how to get 8, 16 and 32 bit signed and unsinged integers. I don't mind doing a search/replace on the source, but I do need to know how big each thing is. AND how to apply them properly to files ;) Cheers Berend.

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