Gpc July 1997

gpc@gnu.de

22 participants
111 discussions

Re: prior parameter's size depends on `Decinput'
by Frank Heckenbach 14 Jul '97

14 Jul '97

Bill Currie wrote: > I've managed to reproduce the error in a smaller file. If I comment > out the parameters (or the body of the function) in the implementation > section, the error disapears. In the real file, the ReadStr causes an > abort when the implementation paramteters are commented out (interface > decl same as always). I cut down the program a bit more to the following: unit foo; interface procedure x(y:string); implementation procedure x(y:string); begin read(y) end; end. Oddly, the bug disappears when deleting "(y:string)" in the 2nd declaration. BTW: Bill, the ReadStr is not completely the same as BP's Val. Especially, the Err parameter is not handled like in BP, but read in as a second value. --

2 1

Re: Revised Cygwin32 licensing terms
by Frank Heckenbach 13 Jul '97

13 Jul '97

Jan-Jaap van der Heijden wrote: > > The new licensing terms for Cygwin32 permits anyone to make use of Cygwin32 > > without adhering to the GPL, and without being required to make their > > sources available, provided that in so doing they are not attempting to > > directly compete with Cygnus. Doesn't this contradict the GPL? Or does it refer only to "add-ons" that are not GPLed? --

2 1

Re: RTS runtime error checks.
by Frank Heckenbach 11 Jul '97

11 Jul '97

Phil Nelson wrote: > >Would it be a violation of the standards if we were to have two RTS > >libraries (libgpc.a and libgpc_g.a), where libgpc_g.a is linked if the > >'-g' compiler switch is used, and libgpc.a (no checks) otherwise? > > I would prefer to see the checks being standard and adding a flag to > get better performance. For example, if any -O flag is used, then > use the library without the checks. I'd even prefer yet another switch. Sometimes one wants optimization with checking on, and sometimes one even wants to distribute code (i.e. without -g) with checks, namely when the code is not time-critical, but it's important that it's correct (suid root :-)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Procedural Types
by Frank Heckenbach 11 Jul '97

11 Jul '97

Peter Gerwinski wrote: > Ah - now I have it! :-) With high probability that's another shape > of a known bug: You cannot assign procedures defined in a *program* > to procedural variables (or procedural pointers, like in your example). > :-( > > [...] > > These procedures are treated as local subprocedures of the main > program which is a procedure by itself. This is the source of > a lot of trouble, also in other contexts, What's the difference? The stack frame? If so, could it be possible to create a stub for each such procedure that sets up the correct stack frame and calls the "local" global procedure? > but it is necessary to > make some nonlocal `goto's work which are required by Extended > Pascal. (No, I don't use `goto', and I don't know more about > this, sorry. If I had a test program for these nonlocal `goto's, > I could try to make the other stuff work *without* breaking `goto'; > right now I don't dare to touch this. ;-) Perhaps something like the following (just guessing): program argh; label l; procedure p; begin writeln(1); goto l; writeln(2) end; begin writeln(3); p; writeln(4); l:writeln(5) end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

prior parameter's size depends on `Decinput'
by Peter Gerwinski 11 Jul '97

11 Jul '97

According to Bill Currie: > > function DecToBin( DecInput : string ) : wrkstring; > [...] > trunkuti.pas: In function `Dectobin': > trunkuti.pas:332: prior parameter's size depends on `Decinput' > make.exe: *** [trunkuti.o] Error 1 Sorry, but I cannot reproduce the bug here. Please try to isolate the bug in a short, useless test program you can post here. Thanks for your cooperation, 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 3

Re: Revised Cygwin32 licensing terms
by Jan-Jaap van der Heijden 11 Jul '97

11 Jul '97

On Tue, 8 Jul 1997, Gordon Irlam wrote: > > The new licensing terms for Cygwin32 permits anyone to make use of Cygwin32 > without adhering to the GPL, and without being required to make their > sources available, provided that in so doing they are not attempting to > directly compete with Cygnus. The reason we decided it was necessary to > prevent the use of Cygwin32 by companies that are competing directly with > Cygnus is explained below. > > Cygnus specializes in the provision of development tools for embedded > systems. Cygnus is responsible for perhaps 80% of all on going GCC > development, and 95% of all GDB development. We commercialize our > development efforts through our GNUPro compiler tool chain. Other people and > organizations contribute to, and benefits from our work. > Translating into readable English, I read here: "You are not allowed to create competing development tools based on cygwin32" How does this affect other GNU compilers, like GNU Pascal and GNU Fortran? I created and maintain the (cygwin32 based) win32 port of GNU Pascal. We will surely try to convert the world to Pascal ;-) Will it violate the new license terms to use cygwin32? J.J. van der Heijden --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

RTS runtime error checks.
by Jan-Jaap van der Heijden 11 Jul '97

11 Jul '97

Hello, The GPC runtime library (RTS) does quite a bit of checking at runtime. The ISO standards dictate this. However, these checks slow down GPC compiled programs. Would it be a violation of the standards if we were to have two RTS libraries (libgpc.a and libgpc_g.a), where libgpc_g.a is linked if the '-g' compiler switch is used, and libgpc.a (no checks) otherwise? This would combine the best of both worlds: checks are enabled when you debug your code, while production code has optimum speed. Let me know your opinions, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

3 2

prior parameter's size depends on `Decinput'
by Bill Currie 11 Jul '97

11 Jul '97

Ok, what the heck does this mean!!!??? (gpc-970624) trunkuti.pas: In function `Dectobin': trunkuti.pas:332: prior parameter's size depends on `Decinput' make.exe: *** [trunkuti.o] Error 1 This is the offending line (I don't think I can send the whole file for as I think it's confidential) function DecToBin( DecInput : string ) : wrkstring; Ancient borland legacy code I'm trying to port to gpc (comiled with 2.0). BTW thanks for the great work, most of the problems I had using 2.0 have gone!! Bill -- Leave others their otherness.

1 0

Re: Some new features
by Frank Heckenbach 10 Jul '97

10 Jul '97

Pierre Phaneuf wrote: > Frank: you could just do an include file with all the path options, and > you just change this file... That's how I do almost every thing (compiler > options and defines in a separate "config file" which I include > everywhere). Well, I could, but I think that's a bad idea! Things like paths do not belong into the source since they're system dependent. (I know that in C it's common to have to edit some source files or makefiles before compiling, but that's one of the many things I dislike about C.) For compiler options that affect the source (most of them), it's ok for me to put them into the source, but path options I'd like to see in system dependent things like scripts, aliases and/or environment variables... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: bugs, incompatibity, function attributes
by A.A. Olowofoyeku 09 Jul '97

09 Jul '97

Pierre Phaneuf wrote: > On Wed, 2 Jul 1997, The African Chief wrote: > > > 6. All classes to have the same ultimate ancestor object. > > This is done manually (by having all your objects inherit from TObject > somewhere). In Delphi, it doesn't need to be done manually. If you write; Type FooObj = Class end; It is *exactly* the same as if you had written; Type FooObj = Class(TObject) end; > Or maybe you mean we could do this: > > var > C: class; I am not sure you can do that, or that you should be able to do it. Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief and The Great Elephant) Keele University, England (Email: laa12(a)cc.keele.ac.uk) Author of: Chief's Installer Pro v3.60 for Win16 and Win32 Homepage: http://ourworld.compuserve.com/homepages/African_Chief/

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

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 July 1997