Gpc May 1999

gpc@gnu.de

25 participants
69 discussions

Re: Learning Pascal (II)
by Frank Heckenbach 14 May '99

14 May '99

J Horacio MG wrote: > As I commented earlier, my only source for Pascal programming > information for a beginner is a short course of Borland Turbo Pascal in > windoze. I too have installed the Gnu Pascal Compiler in Linux, so I > thought it would be possible to learn with the former to use latest. > > Is there any document that explains (from scratch) the very basic > differences between one and another? I hope you will excuse my lack of > knowledge, but as I said these are my very first attempts to learning > programming at all. The GPC documentation contains a chapter about most of the differences and the degree of compatibility to BP. You can type info -f gpc -n "Borland Pascal" to read it (or an equivalent in your favourite info reader, e.g. `(gpc)Borland Pascal' in the RHIDE help). > Now, from the very first basic program (I guess sort of C's "hello > world"): > > Program saludo; > Uses WinCrt; > Begin > > {1} WriteLn ('Hola Mundo'); > > End. Ken Linder $KC7RAD$ replied: > The WinCrt unit in Turbo Pascal is just a set of functions that allow a > turbo Pascal for Windows program to work in a console (DOS) type window > under Windows. In Linux/GPC this is not necessary. That's correct, but since there are some misconceptions about the (Win)Crt unit in the BP world, let me say a few words to clarify the situation: The Dos version of Borland Pascal contains a Crt unit which provides things like text colors, cursor positioning, text windows, reading of single keys (not only whole lines), etc. To accomplish that, it takes over control of Input and Output (i.e., of Read[ln], Write[ln] statements that are not explicitly applied to other files), while in programs without Crt, Input and Output go to the standard input/output of the process, which are connected to the terminal, unless redirected, e.g. `program < inputfile > outputfile'. Unfortunately, many BP programmers have the habit of using Crt in each and every program, whether or not it needs its features. However, using Crt unnecessarily has some disadvantages, e.g. that input/output of such programs can't easily be redirected, the program gets bigger -- and BP's Crt unit contains a famous bug... Now, under windoze, AFAIK, there is no terminal, and therefore standard input/output are not connected by default. That's why the windoze version of BP provides this `WinCrt' unit which emulates a terminal and provides some (but by far not all) routines of the Crt unit (e.g., no colors). Now, for GPC: Since the last release (19990118), GPC contains a CRT unit which contains all the functionality from BP's Crt unit (and more). Like BP's unit, it has to take over Input and Output to do its job. It works on all Unix systems (and especially well on Linux/x86 :-), and on DJGPP. It probably will also work on windoze (mingw) and OS/2 (EMX), but someone would have to compile the PDCurses library (which it uses internally on these platforms), and perhaps make a few little adaptions in the CRT unit, but this shouldn't be hard. (BTW, if a mingw or EMX user could do this, and forward the library binary and any changes necessary in CRT to us, we could include them in the official distribution.) Therefore, GPC will not need a `WinCrt' unit, since its CRT unit will simply work on those systems... What I said above for BP, that using Crt unnecessarily has some disadvantages, holds for GPC as well (actually even more so, since the ability to redirect input/output is more valued under Unix than under Dos). So, when porting from BP/windoze to GPC, one can simply replace `WinCrt' by `CRT'. But one should think twice if CRT is really needed at all -- one can just remove the `uses WinCrt', and if this leads to undefined identifiers, insert `uses CRT'. In principle, we could provide a WinCrt unit for GPC which is identical to CRT, but apart from the fact that that's wasted space (at least on Dos where there are no symbolic or hard links), this would often lead to unnecessary uses of CRT which should be avoided. Therefore, I'd prefer to intentionally not provide a WinCrt unit for GPC. But we should probably include a section in the documentation about this issue... Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

environ
by Frank Heckenbach 14 May '99

14 May '99

Hi, a bug report of a GPC user drew my attention to a possible problem with the `environ' libc variable (which is currently declared for Pascal as `Environment' in gpc.pas). After some research I found that Linux/libc5 (which I'm using) seems to be the only system which has environ declared in <unistd.h>. Linux/glibc declares it, but only if `_GNU_SOURCE' is defined. All the other systems I tried (DJGPP, Solaris, Irix) don't declare the variable, but still have it, i.e. when I declare it as `extern' manually, it is there. (Yeah, that's C...) Now, `environ', as the name suggests, contains the current environment variables, i.e. the ones that were set when the process started plus the ones the process set itself (by setenv() or putenv()). Another way to get at the environment is the third parameter to `main' (which GPC could access internally, that's not a problem). However, this variable only contains the environment at the start of the process. When the process does some putenv()s, the pointer gets invalid (DJGPP), or the environment pointed to just seems to be unmodified (the other systems I tested). Perhaps the DJGPP behaviour is a bug, I don't know, but in any case the parameter is not useful to get the current environment at a later time. So, does anybody know what's the matter with `environ'? Can one just declare it as `extern char **environ;' even if it's not declared in any header? Or is there another way to get at the current environment? If not, in the worst case, this would mean that the GPC RTS has do to its own environment handling, i.e. get the initial environment for the `main' parameter, and provide its own versions of getenv() and putenv() which work on a copy of that. Though it would not be terribly much work, I hope to avoid it... The following C (sorry;-) program demonstrates the effect. It will first print `environ', then the environment pointed to by the third parameter, at the start of the program (these should be identical), then do 1000 putenv()s (it can take quite a few of them to make the problem apparent ;-), then print `environ' again (which does contain the new variables on all systems I tried), and the parameter again (which does not show any changes, and under DJGPP even crashes the program). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <string.h> /* Not necessary under Linux/libc5, but doesn't hurt there, either */ extern char **environ; int main (int argc, char **argv, char **env) { char **a, b [10]; (void)argc;(void)argv; for (a = environ; *a; a++) printf ("%s ", *a); printf("\n"); for (a = env; *a; a++) printf ("%s ", *a); printf("\n"); strcpy (b, "f000=bar"); for (b [1] = '0'; b [1] <= '9'; b [1]++) for (b [2] = '0'; b [2] <= '9'; b [2]++) for (b [3] = '0'; b [3] <= '9'; b [3]++) putenv (strdup (b)); for (a = environ; *a; a++) printf ("%s ", *a); printf("\n"); fflush (stdout); for (a = env; *a; a++) printf ("%s ", *a); printf("\n"); return 0; }

1 0

Learning Pascal (II)
by J Horacio MG 14 May '99

14 May '99

As I commented earlier, my only source for Pascal programming information for a beginner is a short course of Borland Turbo Pascal in windoze. I too have installed the Gnu Pascal Compiler in Linux, so I thought it would be possible to learn with the former to use latest. Is there any document that explains (from scratch) the very basic differences between one and another? I hope you will excuse my lack of knowledge, but as I said these are my very first attempts to learning programming at all. Now, from the very first basic program (I guess sort of C's "hello world"): Program saludo; Uses WinCrt; Begin {1} WriteLn ('Hola Mundo'); End. I can only guess that the above syntax is correct both in windoze and Linux, except for the include file "WinCrt", but... how can I implement these for Unix/Linux? TIA Horacio

2 1

Re: Two GNU Pascal ideas
by Frank Heckenbach 13 May '99

13 May '99

Dr A A Olowofoyeku wrote: > Peter Gerwinski <peter(a)gerwinski.de> wrote: > > > > Sounds mostly okay - except that with Win32, a DLL does not need to > > > have the extension '.dll' (for example, Win32 device drivers are just > > > DLLs with the same interface, and with the extension '.drv' ). A > > > Win32 DLL can have any extension, or no extension at all. Thus it > > > might be that the extension will need to be specified. On the other > > > hand, I suppose that perhaps GPC can presume the extension '.dll' > > > unless another extension is suppled. However, how do you then deal > > > with a case where someone has written a DLL but does not want to give > > > it any extension? > > > > Let GPC first search for the name 'foo' as given, second for > > 'foo.dll' or 'libfoo.so' (depending on the OS) and last for > > 'libfoo.a'. > > Perhaps we are talking at cross-purposes here! The Win32 problem > will occur not a compile or link time, but at runtime, when the > program is trying to link to the DLL. I am not sure whose job it is > to search for the DLL at this point - whether it is the compiler's > job or the OS (I suspect that it is the job of the OS which should > then raise an exception if it cannot find the DLL). Indeed, it's not the compiler that searches for the libraries, but the (static or dynamic) linker. As it is now, `{$L filename.ext}' will: - pass `filename.ext' to the linker, if `.ext' is a known linker extension, currently `.o', `.a', `.so', `.lnk', - pass `-l filename' to the linker if `.ext' is missing. The linker will then search for a (static or dynamic) library called `filename' with the appropriate extension (i.e., `.a' for static and `.so' for dynamic libraries -- I suppose the windoze linker will search for `.dll' rather than `.so'), - pass a filename with any other extension to the compiler (with automake). The most common case here is `.c' to compile and link C code. So, this mechanism currently does not allow arbitrary linker extensions. We could turn it around, so that only known source extensions (`.pas', `.p', `.c', `.cc', `.i', `.S', perhaps `.f' (Fortran?) etc.) are passed to the compiler, and all other extensions to the linker. This would then only prevent a linker file with a source extension (but who would want to give a binary such an extension ;-), and without an extension (because that's reserved for `-l'). If the latter is a real issue, we might have to change the syntax for the second case (`{$L foo}' -> `-l foo'), which I'd consider unfortunate, since it's the most common one besides `{$L foo.c}'. BTW, using `-l foo' (or `{$L foo}' or later "external 'foo'") is preferable over `foo.a' (or `{$L foo.a}', or "external 'foo.dll'", etc.) for several reasons: `-l' will search the library path (`-L'), will find static or dynamic libraries, taking into account the `-static' switch, and can use the appropriate extensions (e.g. `.so' or `.dll'). Frank -- Frank Heckenbach, frank(a)fjf.gnu.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: Two GNU Pascal ideas
by Frank Heckenbach 13 May '99

13 May '99

Dr A A Olowofoyeku wrote: > > Instead of "Foobar" for an identifier `FooBar' declared in a > > unit/module `Baz', we could probably use `baz.foobar' (or > > `baz$foobar'), all lower-case, without risking name clashes with the > > libc. > > Since such routines should be calleable from programs with the > declaration "baz.foobar", it might be that the dot notation would be > preferable to the "$" notation (but of course, it might not make any > difference to the compiler which notation is used internally). Indeed, these two things are not bound to each other. In Pascal, it will be calleable as `baz.foobar' in any case (required by Extended Pascal and Borland Pascal, and the only reasonable thing, anyway, since `$' already has a different meaning in BP and GPC). > > For the external declarations, my suggestions is: > > Procedure Foo; external; (* extern void foo ( void ); *) > > > > (I.e., `external' will convert the name to lower-case, without the > > module name prefix.) > > > > Procedure FooBar; external name 'FooBar'; (* extern void FooBar ( void ); *) > > > > I've heard Delphi has something like this (`external' and `name'). > > Is it the same syntax, or what does it look like in Delphi? > > Delphi has the same notation, with the same syntax as above, used in > the context of *importing* routines from dynamic link libraries > (DLLs). Normally the DLL's name will be in-between "external" and > "name" -e.g., > > Procedure FooBar; external 'barfoo.dll' name 'FooBar'; I think we could do the same, with the 'barfoo.dll' being optional (is it optional in Delphi as well?). If it's omitted, the compiler will assume the library or object file which contains the routine to be linked by other means (e.g., other `external' statements, `{$L barfoo}' directives, or on the command line). Furthermore, I think we should drop the `.dll', i.e. just have external 'barfoo', to link `barfoo.dll' on Win32, and `barfoo.so' on Unix, or `barfoo.a' on any system. IOW, it's equivalent to `{$L barfoo}'. Also, we should allow "external 'foo.o'" to link an object file,', "external 'foo.c'" for C files etc. (which is also completely equivalent to the `{$L}' directive). > A slightly similar notation also exists for *exporting* routines from > DLLs, in which case it has to be used in a separate "EXPORTS" section > at the end of the DLL source (instead of the point where the function > is declared) - e.g., > > Library barfoo; > > Procedure foobar; > Begin > // blah, blah > End; > > Function foofoo : integer; > Begin > Result := -22; > End; > > EXPORTS > foobar name 'FooBar', > foofoo index 1 name 'FooFOO'; // index is optional > > Begin > End. > > I am not sure if (and if so, how) these should be supported by GPC. I think there should be some way to declare libraries in GPC, but we haven't made any design plans for them yet. Also I suppose they'll not be implemented too soon, since there are more urgent things to do, and it's possible (already now) to build libraries with a little bit of extra work, i.e. declare the public routines with `asmname' (later perhaps `name') directives, compile them with `-c', and build a library of them (with `ar' for static libraries and `gpc -shared' for dynamic ones). The problem I see with the syntax above is that the external name declaration is at the end. I doubt whether GPC can could with that well since AFAIK it expects to know the external name when it compiles a routine. Perhaps it could use a temporary name while compiling the routine, and declare the real external name as an alias of that temporary name later, but I'm not too sure if that's possible. If that's not possible, then perhaps a GPC library could look somewhat like a unit, i.e. library foo; interface procedure foobar; name 'FooBar'; implementation procedure foobar; begin end; end. This would not be so much different from what we have already, and therefore probably be easier to realize. > Note: > Identifiers exported in this way are case-sensitive when you want > to import the DLL functions with the "name" declaration. This is not > a Delphi thing but a Win32 thing, so GPC does not need to (and > probably should not) seek to copy that behaviour. `asmname' currently is case-sensitive, and so will `name' be. In order to interface to C code, we don't actually have another choice, because C identifiers are case-sensitive. > In any case, AFAIK, > DLLs are only relevant to OS/2 and Win32, so this may not be an issue > of serious concern. They're only called "DLL" on OS/2 and Win32, but dynamic libraries exist on any platform I know except DJGPP (and perhaps EMX for Dos?). Besides, I don't think we should make a distinction between static and dynamic libraries as far as the program directives are concerned, i.e. let "external 'foobar'" link foobar.dll, foobar.so or foobar.a, whichever is appropriate for the target system and exists (see above). In fact, one can (already now) use the `-static' switch to link the static versions of all libraries rather than the dynamic ones, without changing anything in the source. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 4

Linking problems
by Peter Gerwinski 13 May '99

13 May '99

Hi, folks! Any linker experts out there? When I `ar' together a bulk of `.o' files compiled with GPC, I get lots of undefined references between the `.o's in the `.a'. The same compilation with `--autobuild' works. Any ideas what I am doing wrong? Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 1

Re: integration of GPC into EGCS
by David Edelsohn 13 May '99

13 May '99

>>>>> Peter Gerwinski writes: Peter> This task involves changes to the EGCS backend which must Peter> be coordinated with the other EGCS developers. In earlier Peter> cases our very small suggestions were not accepted, so I do Peter> not really expect our major requirements to make it into the Peter> EGCS main line. The issue is whether something you need changed is the right way to accomodate that feature. We are trying to support all languages and compromise will be necessary. Given the broad, portable use of the compiler and common backend, changes need to be general where appropriate and consistent with maintainability. I have not seen all of the GPC changes, so I am not implying anything about their quality or correctness, just commenting on the broader goals that need to be achieved as part of incorporating GPC. David

1 0

Re: integration of GPC into EGCS
by Peter Gerwinski 13 May '99

13 May '99

Alexander V. Voinov wrote: > Are there any plans to *fully* integrate GNU Pascal into the main EGCS > source tree as is done for G77? Yes. > I.e. I mean to have GPC as a true proper > subtree of egcs as g77 is, and to find it by default in all stable and > experimental versions of egcs. For example, that moment one has > egcs-1.1.2 as a standard version, adopted by RedHat et al., but GPC is > compatible only with the 1.1.1. Of course, but this also means some work - to get GPC integrated into EGCS, (This task involves changes to the EGCS backend which must be coordinated with the other EGCS developers. In earlier cases our very small suggestions were not accepted, so I do not really expect our major requirements to make it into the EGCS main line.) - to keep track with EGCS development, - not to lose support for stable releases (gcc-2.8.1, egcs-1.1.x). Due to a big lack of human resources we currently do not feel able to perform this task - although it is on our schedule. Help welcome! Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

integration of GPC into EGCS
by Alexander V. Voinov 12 May '99

12 May '99

Dear Colleagues, Are there any plans to *fully* integrate GNU Pascal into the main EGCS source tree as is done for G77? I.e. I mean to have GPC as a true proper subtree of egcs as g77 is, and to find it by default in all stable and experimental versions of egcs. For example, that moment one has egcs-1.1.2 as a standard version, adopted by RedHat et al., but GPC is compatible only with the 1.1.1. Thank you in advance Alexander

1 0

Learning Pascal
by J Horacio MG 12 May '99

12 May '99

Greetings, I'd like to learn programming, and been asking around for recommendations. A vast majority suggested to learn C and then C++, but I've also been strongly suggested starting with a "well structured language" like Pascal before anything else. I don't fully understand the meaning of this, and would like some guidance for starting with Pascal. Actually this sounds as if C was about programming, and Pascal just a step towards it. I've tried to look for documentation both online/downloadable and books, and though I've found loads for C/C++, almost nothing for Pascal. All I have is a small course (with Borland programs) in windoze for Turbo Pascal, which means I've been forced to install windoze while my OS is Debian. I'm concerned that this Turbo Pascal course may not help me with learning Pascal with GPC... may be it can help me learning the basics? I would appreciate any suggestions, tips, pointers to docs and books,... and comments to the above. Thank You in Advanced, Horacio.

2 1

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 May 1999