Gpc

gpc@gnu.de

5400 discussions

Re: corrections for GPC 19980830 (SunOS|BSD)
by Frank Heckenbach 02 Nov '98

02 Nov '98

Kevin A. Foss wrote: > Yes, it is hard to say what would be "correct" for the system. The C > standard however does require a minimum of 32767, so setting it to that > should be safe or you could even set it to INT_MAX I suppose (which > -should- be defined in limits.h.) Not in general. Under Solaris, INT_MAX is $7fffffff, but RAND_MAX is only 32767. But when you say 32767 is the required minimum, I can use that if RAND_MAX isn't defined. This gives 15 random bits with one rand() call, so a 64 bit random number requires 5 rand() calls which is at least not *terribly* inefficient... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: corrections for GPC 19980830 (SunOS|BSD)
by Kevin A. Foss 01 Nov '98

01 Nov '98

On Sun, 1 Nov 1998 18:30:46 +0100, Frank Heckenbach wrote: >Harald A. Irmer wrote: >> 3.RAND_MAX (p/rts/random.c) is not known to SunOS, neither to gcc, set for my >> purpose #define RAND_MAX 32767 > >Hmmm... according to my rand() manpage, it's part of ISO, but anyway... The problem here stems from the fact that SunOS does not normally come with an ANSI C compiler. (I ran into these problems several years ago back when I used a SunOS in college -- although not with gpc which I never tried as Sun's Pascal compiler isn't too bad.) On some systems there are compliant headers in /usr/5include but not in /usr/include. Basically the latter is for the "BSD environment" [icky.] and the former is for the "SysV environment" [the ANSI C we all love.] Unfortunately I never played around enough to figure out how to get SysV as the default :( The original poster put "BSD" in the header so if he wants that environment he should be prepared for the problem that this is going to cause trying to compile ANSI C code. To be honest I thought gcc came with scripts to 'fix' the SunOS headers -- but I don't have a source tree handy to check the READMEs. A Sun FAQ I found on dejanews recommends running 'fixincludes' after installing GCC but that is with the precompiled binaries. >Or to say it differently: how do you know that 32767 is correct for >SunOS? Does SunOS document it? (As a general fact or only for SunOS?) Or >is it written in some header in some way? Yes, it is hard to say what would be "correct" for the system. The C standard however does require a minimum of 32767, so setting it to that should be safe or you could even set it to INT_MAX I suppose (which -should- be defined in limits.h.) -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

Re: corrections for GPC 19980830 (SunOS|BSD)
by Frank Heckenbach 01 Nov '98

01 Nov '98

Harald A. Irmer wrote: > 2.`memmove' in run-time-system is Sys5ish, replace by memcpy (in memory.h), at > least please set conditions, #ifdef Sys5 memmove ... > memmove is in GNU C++ The run time system already uses memcpy, not memmove (memmove was still mentioned in a comment and a #define, but it wasn't used anymore, so I removed it). memmove is used in rts.c which is actually part of the compiler, not the RTS, for the Move function. But using memcpy here would be wrong, because according to the memcpy manpage, the source and destination areas may not overlap, but they may overlap for Move. So, I implemented _p_move in rts/move.pas. Peter, can you use that in rts.c instead of memmove? > 3.RAND_MAX (p/rts/random.c) is not known to SunOS, neither to gcc, set for my > purpose #define RAND_MAX 32767 Hmmm... according to my rand() manpage, it's part of ISO, but anyway... I inserted: #ifndef RAND_MAX #define RAND_MAX 32767 #endif But is that safe? I'm applying a modulo (RAND_MAX + 1) to the numbers returned by rand(), so it wouldn't hurt much if RAND_MAX is chosen too small. (Theoretically I could set it to 1, to be safe, but that would be quite inefficient, because then rand() would be called for every bit needed.) Or to say it differently: how do you know that 32767 is correct for SunOS? Does SunOS document it? (As a general fact or only for SunOS?) Or is it written in some header in some way? Peter Gerwinski wrote: > > 5.p/gpi-hash.c needs <sys/stdtypes.h> (size_t) > > I do not have <sys/stdtypes.h> here (under Linux). Is there any > portable way to include it? (AutoConf experts around here?) Perhaps <sys/stdtypes.h> is included in some other, more common, system header in SunOS, so we can include that one? Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

date format problem with GPC 19980830
by Harald A. Irmer 31 Oct '98

31 Oct '98

hi folks, the main Makefile contains a date command option SunOs does not understand: (neither /bin/date nor /5bin/date) p/gpc_date: date '+%h %e %Y' > $@ gives: date '+%h %e %Y' > p/gpc_date date: bad format character - e make: *** [p/gpc_date] Error 64 (found out what was meant by using DEC Unix 4.0d and correct it in my version, - I'll send a patch later) Yours, Harald A. Irmer / hirmer(a)gwdg.de Biomed. NMR-Forschungs GmbH am MPI f"ur biophys. Chemie Am Fa"sberg 11 / D-37077 G"ottingen Tel. +49-551-201-1042 / Fax +49-551-201-1307

2 2

Unsubscribe
by George C. Jackson III 31 Oct '98

31 Oct '98

I keep sending requests to gpc-request(a)hut.fi but to no avail. Please unsubscribe me from the list ..thanks. csgcj(a)olemiss.edu ------------------------------------------------------------------ George C. Jackson Systems Programmer III csgcj(a)olemiss.edu University of Mississippi Powers Hall 317 (601) 232-1075 ------------------------------------------------------------------

1 0

small omissions in GPC 971001
by Harald A. Irmer 29 Oct '98

29 Oct '98

hi folks, the last version of GPC I could get was 971001. It did not compile with Sun cc (SunOs 4.1.4/sun4m) Had to write: make *CC=gcc* LANGUAGES=pascal `SEEK_SET' was unknown in gpc-lex.c: #include <unistd.d> `size_t' was unknown in gpi-hash.h: #include <sys/stdtypes.h> Yours, Harald Artur Irmer Harald A. Irmer / hirmer(a)gwdg.de Biomed. NMR-Forschungs GmbH am MPI f"ur biophys. Chemie Am Fa"sberg 11 / D-37077 G"ottingen Tel. +49-551-201-1042 / Fax +49-551-201-1307

2 1

Re: More GPC bugs ???
by Frank Heckenbach 27 Oct '98

27 Oct '98

Thamm, Russell wrote: > The three following files show two apparent bugs: > > 1) The compiler seems to get confused between a standard procedure and an > object > method with the same name. Yes, that's true. I came across this problem as well recently. > 2) Types declared in other units are still problematical. Comment out > procedure aaa > in unit 1. Now the main program fails to compile: > > Error Incompatible type for argument 2 of Twoobj_Bbb. Hmpf... this problem was fixed for schema, pointer and record types, but apparently not for enum types. :-( I added it to the bug list. Anyway, Peter is working on a new GPI format which will hopefully get rid of this kind of bugs (there are a few more of them) altogether... > I can't even seem to find a workaround for this (apart from abandoning the > user-defined type). Perhaps some type-casting to Integer and back will help, but it's not nice... Perhaps it's better, until the bug is fixed, to turn the enum type into an integer: type RRtype = Integer; const rr_one = 0; rr_two = 1; ... Not very nice, either, but then there's ugliness only in one place -- but of course, you lose some degree of type-safety... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

More GPC bugs ???
by Thamm, Russell 26 Oct '98

26 Oct '98

The three following files show two apparent bugs: 1) The compiler seems to get confused between a standard procedure and an object method with the same name. In unit 1, the compiler confuses OneObj.aaa with aaa. So unit two fails to compile: Error Too many arguments to function Oneobj_Aaa. If I comment out the procedure declaration for aaa, the compiler error disappears too. 2) Types declared in other units are still problematical. Comment out procedure aaa in unit 1. Now the main program fails to compile: Error Incompatible type for argument 2 of Twoobj_Bbb. I can't even seem to find a workaround for this (apart from abandoning the user-defined type). I am using the latest BETA. (30/08/98). Russell Thamm {--------------------------------------------------------------------------- -------------------------------} Unit one; INTERFACE TYPE RRtype = (rr_one,rr_two,rr_three,rr_four); OneObj = OBJECT a : Integer; procedure aaa(r : RRType); end; procedure aaa; IMPLEMENTATION procedure OneObj.aaa(r : RRType); begin end; procedure aaa; begin end; END. {--------------------------------------------} unit two; interface uses one; type TwoObj = OBJECT MyOne : OneObj; procedure bbb(r : RRType); end; implementation procedure TwoObj.bbb(r : RRtype); begin MyOne.aaa(r); end; end. {-----------------------------------------------------------------} program crap; uses one,two; var MyTwo : TwoObj; begin MyTwo.bbb(rr_one); end.

1 0

subscribe
by Nicholas Geovanis 19 Oct '98

19 Oct '98

subscribe hello Please subscribe me to the Gnu Pascal mailing list. Thanks. <---------------------------------------------------------------------------> "I believe that we are in the most serious | Nick Geovanis financial crisis since World War II." | IT Computing Svcs -- William McDonough, President | Northwestern Univ New York Federal Reserve Bank, 10/6/98 V n-geovanis(a)nwu.edu

1 0

where do I get gnu pascal?
by Hamish Short 18 Oct '98

18 Oct '98

I hae been trying to get gpc for installation on a Sun solaris system here in Marseille for our students. Unfortunately kampi is not responding to ping, and there is no other computer I can find withh gpc on it... the machine sunsite.ic.ac.uk does not have gpc in the advertised directory gnu/pascal. Is there a problem here? best wishes hamish short

3 2

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