April 1999 - Gpc

Re: move-string bug?
by Frank Heckenbach 10 Apr '99

10 Apr '99

Russ Whitaker wrote: > hi Frank > is this a miss-use of move, a bug, or something that has already been > fixed? The former. The capacity is stored internally as the first field of a string, so if you move to "temp", you'll overwrite temp's capacity. What you can do (and that's about the only case where a "move" seems acceptable besides low-level stuff) is to move the characters of a string, like the following: program astrings; var srcstr : string(255); temp : string(120); begin srcstr := 'abcdefghi'; writeln( srcstr.capacity, ' ', length(srcstr), ' ', srcstr); writeln( temp.capacity ); move( srcstr [1], temp [1], length(srcstr)); writeln( temp.capacity, ' ', length(temp), ' ', temp); {$X+} SetLength (temp, length (srcstr)); {$X-} writeln( temp.capacity, ' ', length(temp), ' ', temp); end. However, as you see in this program, to modify the length of a string, you need `SetLength', and this requires extended syntax, so I don't really recommend this method. It's usually easier to use the existing string operations (in this case, of course, a simple `:=' assignment would do, but I assume you have something more complicated in mind -- if you don't know how to achieve it with the string operations, be welcome to ask). 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

move-string bug?
by Russ Whitaker 10 Apr '99

10 Apr '99

hi Frank is this a miss-use of move, a bug, or something that has already been fixed? gpc version 19990118, based on gcc-2.8.1 program as follows: program astrings; { show string bug } var srcstr : string(255); temp : string(120); begin srcstr := 'abcdefghi'; writeln( srcstr.capacity, ' ', length(srcstr), ' ', srcstr); writeln( temp.capacity ); move( srcstr, temp, length(srcstr)); writeln( temp.capacity, ' ', length(temp), ' ', temp); move( srcstr, temp, length(srcstr)+8); writeln( temp.capacity, ' ', length(temp), ' ', temp); end. Output is as follows: 255 9 abcdefghi 120 255 9 a 255 9 abcdefghi thanks, russ

1 0

Re: Free Vision (was File names, DPMI, and Turbo Vision for GPC)
by The African Chief 05 Apr '99

05 Apr '99

Marius Gedminas wrote: [...] > >The port of Free Vision to GPC is currently being worked on. > >Be welcome to join the project, so it will become usable sooner. > > I cannot promise much due to lack of free time, but it's already been > some time since I last inspected Free Vision. Is there a home page for > it now? Not that I know of - but you can get the latest versions from the FPC home page. I have ported the Objects unit to GPC (well, at least until the problem with "New'ing" pointer to files under the EGCS-based GPC compilers for Linux and Win32 are solved). I do not have the energy, time, or even the knowhow to port the other FV units (especially those with asm code in them) to GPC, so others will have to take on that task on (IIRC Peter is looking into doing this - am I right, Peter?). AFAICS the FV license terms are not GPL compatible and there may be other copyright issues that will make the ported FV Objects unit not distributable with GPC. If anyone is interested, I can make a copy of my current "development" version available (perhaps on my homepage). -- Best regards, Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.0 for Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

2 1

Re: File names (was: File names, DPMI, and Turbo Vision for GPC)
by Frank Heckenbach 04 Apr '99

04 Apr '99

Marius Gedminas wrote: > On Sat, Apr 03, 1999 at 12:29:12PM +0200, Peter Gerwinski wrote: > >Don't we need an additional variable `CasePreserving' then which > >is false on FAT but true on VFAT filesystems? > > What would it be used for? I don't think we need it. Actually, one can't rely on file names being stored unmodified at all. E.g., Dos (without LFN) will strip a trailing `.', except in `.' and `..', and anything beyond the 8+3 limitation, anyway. So, one must not rely on finding the file name as one stores it. All one can expect (I hope, at least) is that one can access the file by the same file name one used for storing (i.e., it will be modified the same way...) If one wants to canonicalize a file name, one can try `FExpand'... > >Even worse: This needn't be a constant for one OS but depends > >on the path you are accessing. A file on a FAT filesystem > >mounted under Linux has LFN=CaseSensitive=CasePreserving=false. > > I really think there is no need to go into that level of details. Other > Linux programs do not care for this, why should programs compiled with > GPC be an exception? I agree. I don't think a Linux user mounting a FAT FS with a file `foo' would expect it to show up when expanding `F*' (better mount it umsdos, anyway ;-). 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: bugs under DOS/DJGPP
by Frank Heckenbach 03 Apr '99

03 Apr '99

Maurice Lombardi wrote: > Hi all > I have found a couple of small bugs in the last beta > gpc-19990118.i386-pc-djgppv201.zip > when using LFN=n 8.3 limitation in DOS 6.2 > > The problem comes from the fact that in this situation DOS makes > uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an > odd behavior displayed by the following short program: > > program ff; > uses dos; > var F:SearchRec; > begin > FindFirst('ff.pas',Anyfile,F); > writeln('l ',DosError); > FindFirst('FF.PAS',Anyfile,F); > writeln('u ',DosError); > end. > > DJGPP answers > l 0 > u 18 > i.e. it does NOT recognize the UPPERCASE filename, finding only the > lowercase one. > > In the same situation BP answers > l 0 > u 0 > i.e. it recognizes both. > > The defect can be traced to the function MatchPart in the FindNext > procedure. Correction need to be done only under DJGPP (at compilation > time) when LFN=n at execution time. A possible solution is given by the > attached diff. Thanks for the report. I fixed this -- actually a bit more general: I put into the RTS a new constant FileNamesCaseSensitive and a new function FLoCase to convert a character to lower case if FileNamesCaseSensitive is False and leave it unchanged otherwise, and use them in the Dos unit, so that unit doesn't need any ifdefs. However, I'm not sure about when FileNamesCaseSensitive should be set to False: First of all, I think it should be on all __OS_DOS__ platforms, not only __DJGPP__. Then, what about the LFN stuff? I haven't used such a system, but I've read that it's not really case-sensitive (something like, the case of the files as given on creation is stored, but matching is still insensitive). If that's so, FileNamesCaseSensitive should still be False, and we don't have to check LFN. Can anyone confirm or deny? > Similarly the environment names are always capitalized, so that > GetEnv('path') and GetEnv('PATH') give the same result as displyed in > the following short program: > > program ge; > uses dos; > var F:SearchRec; > begin > writeln('LFN=',GetEnv('LFN')); > writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); > writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); > writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); > end. BTW, something unrelated to your request: when searching for an executable, you might prefer to use: FSearchExecutable ('rhide', GetEnv (PathEnvVar)); This searches for `rhide.com', `rhide.exe' and `rhide.bat' under Dos (so you get more flexibility there), and on other systems for `rhide' without extension (so it works there, too) and only with executable permission (so it's safer than "FSearch ('rhide', ...)" there). PathEnvVar is currently 'PATH' on all systems, but one never knows what will happen... ;-) BTW, FSearchExecutable and PathEnvVar need the `gpc' unit rather than `dos' (and `FSearch' and `GetEnv' are also present in `gpc' as well as in `dos'). > DJGPP in DOS 6 with LFN=n answers: > > LFN=n > ll > uu F:\DJGPP\BIN\RHIDE.EXE > lu F:\DJGPP\BIN\rhide.exe > > whereas in BP gives always (even in a W95 dos box) > > LFN= > ll F:\DJGPP\BIN\rhide.exe > uu F:\DJGPP\BIN\RHIDE.EXE > lu F:\DJGPP\BIN\rhide.exe > > This behavior of automatic capitalization of environment variables is so > strange that I am not sure it must be reproduced in a unit which aims at > portability: I think that nearly everybody would write naturally > programs with environment variables uppercase as displayed by the set > command. Actually, I have changed this after 19990118 (only for Dos, of course, not affecting other systems where case matters). This is the corresponding entry from the `Fixed bugs' section of the To-Do list (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html) 19990202: Dos-like systems: convert parameter to GetEnv and CGetEnv to upper case (actually, libc should do so) > A completely different bug is in the crt unit. Readkey returns #10 i.e. > linefeed when one hits the return as well as the ^M keys which should be > #13. > THis is very strange since the demo program testcurs.c which comes with > the sources of PDcurses has the correct behavior. Oh yes, these CR/LF stuff is a bit nasty because if seems to depend on a number of things like terminal modes, which are affected by CheckBreak (perhaps a bug in PDCurses, at least a bit of undocumented behaviour there ;-). I changed CRT a little after 1990118, hope this will also fix the symptom you've experienced: 19990202: DJGPP: CRT: ReadKey returns #10, not #13, for the enter key when CheckBreak is True Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 3

bugs under DOS/DJGPP
by Maurice Lombardi 03 Apr '99

03 Apr '99

Hi all I have found a couple of small bugs in the last beta gpc-19990118.i386-pc-djgppv201.zip when using LFN=n 8.3 limitation in DOS 6.2 The problem comes from the fact that in this situation DOS makes uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an odd behavior displayed by the following short program: program ff; uses dos; var F:SearchRec; begin FindFirst('ff.pas',Anyfile,F); writeln('l ',DosError); FindFirst('FF.PAS',Anyfile,F); writeln('u ',DosError); end. DJGPP answers l 0 u 18 i.e. it does NOT recognize the UPPERCASE filename, finding only the lowercase one. In the same situation BP answers l 0 u 0 i.e. it recognizes both. The defect can be traced to the function MatchPart in the FindNext procedure. Correction need to be done only under DJGPP (at compilation time) when LFN=n at execution time. A possible solution is given by the attached diff. Similarly the environment names are always capitalized, so that GetEnv('path') and GetEnv('PATH') give the same result as displyed in the following short program: program ge; uses dos; var F:SearchRec; begin writeln('LFN=',GetEnv('LFN')); writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); end. DJGPP in DOS 6 with LFN=n answers: LFN=n ll uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe whereas in BP gives always (even in a W95 dos box) LFN= ll F:\DJGPP\BIN\rhide.exe uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe This behavior of automatic capitalization of environment variables is so strange that I am not sure it must be reproduced in a unit which aims at portability: I think that nearly everybody would write naturally programs with environment variables uppercase as displayed by the set command. But for the same reason the first issue on FindFirst/FindNext must be corrected, because filename are usually written in uppercase in DOS, so that the actual behavior of gpc is completely unnatural. A completely different bug is in the crt unit. Readkey returns #10 i.e. linefeed when one hits the return as well as the ^M keys which should be #13. THis is very strange since the demo program testcurs.c which comes with the sources of PDcurses has the correct behavior. Hope this helps Maurice Lombardi -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

bugs in DOS/DJGPP
by Maurice Lombardi 03 Apr '99

03 Apr '99

Hi all I have found a couple of small bugs in the last beta -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

External references in GNU Pascal
by Mike Ainsworth 02 Apr '99

02 Apr '99

I've just started using GNU Pascal to port some legacy code across to Windows95/NT. I'm using DJGPP with the 19990118 beta copy of GPC. Everything appears to be working fine until I get to the linking stage. I'm getting unresolved references to Pascal procedures declared externally. I suspect I must be getting something fairly basic wrong, but I can't even get an example from the GPC documentation to build successfully! Suggestions would be gratefully received. Mike Ainsworth Example: -- foobar.pas -- module foobar; type footype = integer; var foo : footype; procedure setfoo(f : footype); begin foo := f; end; function getfoo : footype; begin getfoo := foo; end; end. -- what.pas -- program what(output); type footype = integer; procedure setfoo(f : footype); external; function getfoo : footype; external; begin setfoo(999); writeln(getfoo); end. -- Output -- gpc -o modtest.exe foobar.o what.o -lm -lgpc Error: what.o: In function `program_What': what.pas(8) Error: undefined reference to `Setfoo' what.pas(10) Error: undefined reference to `Getfoo' ========================================================================== Mike Ainsworth Praxis Critical Systems Limited, 20 Manvers Street, Bath BA1 1PX Tel: +44 1225 466991 Fax: +44 1225 469006 Email: ma(a)praxis-cs.co.uk ======= Software Engineering Safety-Critical Systems =======

3 2