April 1997 - Gpc

Re: CStrings
by Frank Heckenbach 28 Apr '97

28 Apr '97

Peter Gerwinski wrote: > I encountered some problems with Procedures accepting `CString' > parameters. When passing a string constant to such a parameter, GPC > does *not* automatically add a "chr ( 0 )" terminator. > > Should it do? And if so, in which cases? We always can explicitly write > "foo ( 'bar'#0 );" instead of just "foo ( 'bar' );", so I tend to let > things like they are ... I think it should automatically add a #0 terminator. After all, a "CString" without terminator is somewhat undefined. In which cases? I think always when a string constant is given where a "CString" value is expected, whether for a parameter, or a variable initializer. E.g. the following should work as expected: var numbers:array[1..3] of cstring value (1:'one';2:'two';3:'three'); or in BP syntax: const numbers:array[1..3] of pchar=('one','two','three'); Many of my programs rely on this. -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.](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: Legal Change in GPC ?
by Peter Gerwinski 28 Apr '97

28 Apr '97

According to Christian Wendt: > > I wondered how to implement the ability to change colours and write text > to Standard output - but I think it's nearly impossible to do this within > a Unit - the C - Textcolor doesn't work with the fprintf function that is > used in the RTS... Nevertheless I did this. :-) Please have a look at the BPcompat package, available in the `contrib' subdirectory of the GPC distribution. > I wondered wether it would be legal (in sense of > portability and compability...) to change the RTS : Textcolor works if you > check wether the file passed to writeln is Stdout - when it is you use > cprintf (or putch instead of fwrite). You are right that this is a problem we must think about. In this case I think it increases portability and compatibility to do the changes because otherwise it is impossible to get colors under DOS whereas you can have them with Linux or any other system which provides colors as terminal escape sequences, e.g. according to ANSI. > The question is - would it be legal to do such - you could put in a > variable (smth like "GPC_ConsoleOutput") to switch in on/off ? In the BPcompat package or in newer Alpha releases of GPC, this variable exists and is called `p_directvideo', available as `DirectVideo' if you do `uses CRT'. If it is `true', `writeln' is performed through `cprintf', otherwise through `printf'. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: CStrings
by The African Chief 28 Apr '97

28 Apr '97

On Sun, 27 Apr 1997 17:34:47 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >Hello, > >I encountered some problems with Procedures accepting `CString' >parameters. When passing a string constant to such a parameter, GPC >does *not* automatically add a "chr ( 0 )" terminator. > >Should it do? I personally think so. >And if so, in which cases? "In all cases", I would venture to say. > We always can explicitly write "foo ( 'bar'#0 );" instead >of just "foo ( 'bar' );", so I tend to let things like they are ... The string constant parameter is something that thinks it is (or is pretending to be) a CString. Since CStrings end with a Chr(0), it is probably best to make the string constant do so automatically - otherwise, its pretensions would be found out very quickly. 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

Re: CStrings
by Berend de Boer 28 Apr '97

28 Apr '97

You wrote: >I encountered some problems with Procedures accepting `CString' >parameters. When passing a string constant to such a parameter, GPC >does *not* automatically add a "chr ( 0 )" terminator. I think it should. Much less confusing, probably more portable and in Extended Pascal #0 is not recognized, so means a few characters more typing pain. Another solution, whith less performance impact would be to always add a chr(0) to a string constant at compile time. I think I favor this approach. The length returned should be the length minus chr(0) but the chr(0) should be there. Groetjes, Berend.

1 0

Legal Change in GPC ?
by C.WENDT＠CHATEAU.cl.sub.de 28 Apr '97

28 Apr '97

Am 25.04.97 konnte ich meine Finger einfach nicht von der Tastatur fernhalten... Folgendes kam dabei heraus: Hallo! I wondered how to implement the ability to change colours and write text to Standard output - but I think it's nearly impossible to do this within a Unit - the C - Textcolor doesn't work with the fprintf function that is used in the RTS... I wondered wether it would be legal (in sense of portability and compability...) to change the RTS : Textcolor works if you check wether the file passed to writeln is Stdout - when it is you use cprintf (or putch instead of fwrite). The question is - would it be legal to do such - you could put in a variable (smth like "GPC_ConsoleOutput") to switch in on/off ? Chris --- HomeBox : Chateau - 08677 911940(V.34) 911941(ISDN) ## CrossPoint v3.11 ##

1 0

passing pointers, GPC documentation
by Peter Gerwinski 27 Apr '97

27 Apr '97

According to skye: > > Yes, I can get that to work but what still fails is when gBuffer is > allocated using new(): > [...] > ScreenBlit( gBuffer); (* crashes in the movedata() from the std C lib *) Again: How did you declare the "ScreenBlit" procedure? > Now I'm not too sure how memory allocation works under pascal. Is this > right? I don't have many examples to got from and they all work something > like this. would this be the same as this in C: > > char* gBuffer; > gBuffer = malloc(320*200); > free(gBuffer); Yes. > now I haven't seen GetMem before. The examples I'm using just use the > method i've shown above. Does GetMem work like malloc() where I can specify > the amount at runtime? (this would be nice). Yes. `GetMem' is a Borland Pascal extension: GetMem ( gBuffer, 320 * 200 ); FreeMem ( gBuffer, 320 * 200 ); GPC also allows the following: gBuffer:= GetMem ( 320 * 200 ); FreeMem ( gBuffer ); (* 2. parameter is optional in GPC *) > Also, isn't there a limit to the amount of static variable memory I can use > (DS)? No. > I don't want to have to fidle with my compiler options to increase > it. If I have a static array that is 64k there is potental for probles way > down the road, esp. if I have other large static structres. Feel free to allocate static structures of 1MB or above. This is one reason why I am using GPC rather than BP for scientific programs. (-: > Sorry about the basic Pascal questions. It is strange switching from C/C++ > to Pascal without documentation. I keep trying to do something one way and > find out after much frustration that is done another in Pascal. I have only > a few Pascal DOCS I have found online and they all use TP. Are there any > using GPC? AFAIK, the only existing GPC documentation is our info documentation and the GPC FAQ. You can find both in your GPC distribution, or online at http://home.pages.de/~GNU-Pascal/gpc-doc.html http://home.pages.de/~GNU-Pascal/gpc-faq.html If anybody wants to help to create more documentation, I suggest the following: Collect all this information from this list, e.g. the `GetMem' stuff above, put it into a reasonable structure, and add it to the GNU Texinfo documentation. If you have any questions, be sure that I will help you. Like this, the reference will be made available as on-line help, e.g. with Ctrl+F1 when using the RHIDE. I am starting to do this *now* by writing something about Integer types. It is appended below, so you have an example what I am speaking of and would like to recieve. If you have more ideas, e.g. to write something about `writeln', just do it and post it here! 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- @node Integer @subsection Integer @cindex Integer types GNU Pascal supports the following Integer types: @table @samp @item ByteInt signed 8-bit integer type, @samp{-128..128} @item Byte unsigned 8-bit integer type, @samp{0..255} @item ShortInt signed 16-bit integer type, @samp{-32768..32767} @item ShortWord unsigned 16-bit integer type, @samp{0..65535} @item Integer signed 32-bit integer type, @samp{-2147483648..2147483647} @item Word unsigned 32-bit integer type, @samp{0..4294967295} @item LongInt signed 64-bit integer type, @samp{-9223372036854775808..9223372036854775807} @item LongWord unsigned 64-bit integer type, @samp{0..18446744073709551615} @end table ISO Pascal defines only @samp{Integer}; the other types are GNU extensions. Some of these types (@samp{Byte}, @samp{ShortInt}, @samp{Word}, and @samp{LongInt}) are available in Borland Pascal, too, but have a different size there. For sake of compatibility to Borland Pascal, @samp{LongInt} can also be called @samp{Comp}. On the i386 processor family, operations with @samp{Integer} usually work faster than operations with shorter integer types like @samp{ShortInt} or @samp{ByteInt}. @strong{Known bug:} At the moment, GPC's run time library is not able to @samp{write} or @samp{writeln} integer types longer than @samp{Integer}. @c ---------------------------------------------------------------------------- @node LongInt @subsection LongInt @samp{LongInt} is GPC's signed 64-bit integer type, @samp{-9223372036854775808..9223372036854775807}. For sake of compatibility to Borland Pascal, @samp{LongInt} can also be called @samp{Comp}. @xref{Integer} @xref{LongWord} @xref{Comp} @c ---------------------------------------------------------------------------- @node LongWord @subsection LongWord @samp{ByteInt} is GPC's unsigned unsigned 64-bit integer type, @samp{0..18446744073709551615}. @xref{Integer} @xref{LongInt} @c ============================================================================

1 0

Re: Modifying string length?
by Peter Gerwinski 27 Apr '97

27 Apr '97

According to Frank Heckenbach: > > Is there a way to change a string's length directly? AFAIK, there isn't. Use the `SubStr' function (like BP's `copy' function) to shorten a string, and the `+' operator to make it longer. And of course you can take a pointer to the string, cast it to a pointer to a record the fields of which you can manipulate like you wish ... > BTW: Are the TP string routines (e.g. Insert, Delete) already ported to gpc? The African Chief is working on this. (-: It will probably be released soon. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha: EMX run time library broken?
by Kevin A. Foss 27 Apr '97

27 Apr '97

On Wed, 23 Apr 1997 21:47:37 +0200 (MET DST), Peter Gerwinski wrote: >I was reported that the EMX run time library of the latest alpha GPC >(gpc-970420) is broken: Not even `hello.pas' can be linked. > >Since I cannot reproduce the error on my own system (I can link even >more complicated EMX programs here ... :-) I ask whether somebody else >has observed the same problem. Perhaps there is a bug which only shows >up in some configurations ... Well I was the one who reported the above problem to Peter and after messing around for 5 days trying to apply the patches, compile it myself, using gdb to trace the source, I have found the problem: I'm a moron. I found I had an older version of the gpc executables in my path before the newer versions, but I was putting the library in the correct place. [For various reasons, I don't like putting anything except the EMX distribution in the \EMX directory tree.] So when I tried to compile hello.pas, the old 2.0 executables were trying to use the new runtime library from the latest alpha and things didn't go well. So, my apologies to Peter and to anyone else who might have wasted time looking for a fix to this problem. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

CStrings
by Peter Gerwinski 27 Apr '97

27 Apr '97

Hello, I encountered some problems with Procedures accepting `CString' parameters. When passing a string constant to such a parameter, GPC does *not* automatically add a "chr ( 0 )" terminator. Should it do? And if so, in which cases? We always can explicitly write "foo ( 'bar'#0 );" instead of just "foo ( 'bar' );", so I tend to let things like they are ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: errors when passing pointers from a unit
by Peter Gerwinski 27 Apr '97

27 Apr '97

According to skye: > > var > gBuffer"^mode13VideoBuffer; You mean: gBuffer: ^mode13VideoBuffer;-). > [...] > All my graphic functions draw to this buffer. To get it to the screen I > have a procedre that calls an external C function: > procedure gUpdate; > begin > screenblit( gBuffer); > end; How is this C function declared in the Pascal program? As "Procedure ScreenBlit ( gBuffer: Pointer ); C;"? Then it should work. > [...] > This only crashes when I pass it a pointer from my unit. I can do the exact > same allocation from the main program file and it will work OK. This I don't understand. You mean that you are using a statically allocated video buffer in the Pascal program and passing a pointer to it to the C program? The following should work: Program Whatever; Type mode13VideoBuffer = array [ 1 .. 320 * 200 ] of Byte; mode13VideoBufferPtr = ^mode13VideoBuffer; Var gBuffer: mode13VideoBuffer; (* NOT a pointer to it *) Procedure ScreenBlit ( Buffer: mode13VideoBufferPtr ); C; begin ScreenBlit ( @gBuffer ); end. > Am I getting confused on how pointers work in C and how they work in Pascal > (I thought that they were pretty much the same except for type checking Yes, they are. > and "true" dynamic allocation)? What's that? What's "false" with `New' and `GetMem'? :-) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

2 1