Gpc

gpc@gnu.de

5400 discussions

Re: environ
by Nick Burrett 17 May '99

17 May '99

Frank Heckenbach <frank(a)tim.gerwinski.de> writes: > 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). > > 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()). The `environ' variable only contains the array of strings of the environment at process startup. It does not change with calls to 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. The third argument to main is equivalent to the `environ' variable and should point to the same place. > 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? Yes you can just declare it as `extern char **environ'. There's no guarantee that `environ' actually exists so just declaring it extern and using it could give you linker errors. You'd have to find a solution to this, perhaps using autoconf to check for it's existence and declaring your own version if it doesn't. There isn't anything wrong with `environ', you have just misunderstood it slightly. > 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... I don't see why the GPC RTS would need to do it's own environment handling. Unless you are thinking of the extreme case where the `getenv', `setenv' and `putenv' functions are missing. Or are you thinking that a Pascal character array pointer should always point to an up-to-date environment list ? Nick.

1 0

Re: Word or Cardinal
by Frank Heckenbach 16 May '99

16 May '99

Olivier PECHEUX wrote: > I want to use the unsigned integers in GPC. If I compile: > > Program Unsigned; > Var i:Word; > Begin > For i:=1 To 10 Do Writeln(i) > End. > > I have the error: > Error:type name expected, identifier 'Word' given > > If I replace Word by Integer, that's OK. I try Cardinal insted of Word, > it does'n work. I'm using the GPC of gpc20b.zip and rhide on a windows > machine Please upgrade to a newer GPC, version 2.0 is very old. The last beta version (19990118) can be found at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/ It supports both Word and Cardinal. They're equivalent -- which one you use is up to your preference. 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

Word or Cardinal
by Olivier PECHEUX 16 May '99

16 May '99

Hi, I want to use the unsigned integers in GPC. If I compile: Program Unsigned; Var i:Word; Begin For i:=1 To 10 Do Writeln(i) End. I have the error: Error:type name expected, identifier 'Word' given If I replace Word by Integer, that's OK. I try Cardinal insted of Word, it does'n work. I'm using the GPC of gpc20b.zip and rhide on a windows machine What's wrong? Olivier. -- --------Publicite--personnelle--------------------------------------- ........ABC de la Programmation: ................http://www.multimania.com/opecheux

1 0

Re: help...
by Russ Whitaker 15 May '99

15 May '99

Qyrano writes: > Subject: help... > Date: Friday, May 14, 1999 3:25 PM > > $ gpc factorial.pas > > ld> cannot open -lgmp: No such file or directory > > (demo program factorial.pas uses units gpc and gmp....) > > Can someone help me to solve this trouble?..... > > Roberto you can download gmp from ftp://metalab.unc.edu/pub/gnu/gmp thanks Russ

1 0

Re: help...
by Frank Heckenbach 15 May '99

15 May '99

Qyrano wrote: > $ gpc factorial.pas > > ld> cannot open -lgmp: No such file or directory > > (demo program factorial.pas uses units gpc and gmp....) > > Can someone help me to solve this trouble?..... You need the GMP library, available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ You'll also need the rx library for the RegEx unit and the ncurses (Unix/terminal) or `curse' (Unix/X11, DJGPP) library for the CRT unit. There are sources and binaries for some systems. If you're using a system for which there are no binaries yet, and you compile the libraries, we'd appreciate if you upload a binary. 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

help...
by Qyrano 14 May '99

14 May '99

$ gpc factorial.pas ld> cannot open -lgmp: No such file or directory (demo program factorial.pas uses units gpc and gmp....) Can someone help me to solve this trouble?..... Roberto

1 0

Re: Relationship between GPC and GCC on Linux (Compiling)
by Frank Heckenbach 14 May '99

14 May '99

Jose Romildo Malaquias wrote: > 2. The compilation goes smoothly. Installation too. But should > I keep the files > /usr/lib/gcc-lib/i386-redhat-linux/2.8.1/{libgcc.a,spec} > or they can be safely removed (and then GPC uses the ones > from the EGCS installation)? I think they can safely be removed -- for now. Currently, as you correctly noted, it is necessary to have the same version of GCC as of GPC. In the future, we hope to relax this restriction so GPC will work with any GCC version installed. If that's a different version, there won't be libgcc.a and specs in GPC's directory, so the files from GPC should be kept. But if it's the same version, the files from GCC should probably be used. This might be a problem. Does RPM provide a way to handle such situations? > I have worked out rpm packages for the latest GPC beta. As I am not > an experienced GPC user, would somebody take a look at the spec file > and comment it. I'm not familiar with RPM specs, so I won't comment on them. Just two points: : Copyright: GPL If you want to be very precise, you could add LGPL (which holds for the run time system) here. : Url: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ http://home.pages.de/~GNU-Pascal/ is preferable. Currently, it points to the same URL, but if the former should ever change, the latter will remain the same. 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: 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

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