Gpc May 1997

gpc@gnu.de

30 participants
111 discussions

Re: Modifying string length?
by Frank Heckenbach 02 May '97

02 May '97

Peter Gerwinski wrote: > > s:='' should do the same. (BP optmizes this to just setting the length to 0, > > I hope gpc does as well.) > > It does. (But better check it, too - I already was wrong once with > statements of this type.;-) Yes, it does. I checked it. It even does "s:='...'" where '...' is a constant string with length<=14 without any loops or calls. > > I think it should (at least with {$X+} or such), because it's the only way > > to translate some kinds of procedures -- unless one wants to limit such > > procedures to borland-like short strings. > > Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )". ^^^^^^ ...or rather CurrentLength, as you said before. Then perhaps it would be useful to allow the same syntax also for ShortStrings (additionally), just as if ShortString[n] was declared as: record case boolean of false:(CurrentLength:byte); true:(string:array[0..n] of char); end; Also, it could be good to provide a (read-only) "pseudo field" Capacity. (BTW: LongStrings' Capacity is always read-only, isn't it?) BP 7.0 allows this via High(s) -- is something like BP's High and Low functions (to give the lower and upper bounds of arrays and subrange types) present or planned for gpc? Then the compiler could just translate "s.Capacity" to "High(s)" in the case of ShortStrings. These two things would make ShortStrings more similar to (and often exchangeable with) LongStrings, without giving up BP compatibility. > > The question is, should the #0 be added for short strings as well? > > If Length=Capacity, it's impossible, but otherwise??? > > We could increase the space allocated for a short string by 1, but this > would break compatibility to UCSD and Borland Pascal. So better ignore > this and live with "String [ 255 ]" having only a capacity of 254 in fact. No, I guess this could break some programs, too. BTW: The problem is also there for Length=Capacity<=255: either we'd have Sizeof(String[n])=n+2 or (Capacity of String[n])=n-1 -- both could lead to problems. So, perhaps better forget about the #0 with ShortStrings, and add it when converting to other strings... > > Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) > > I would not call this "non-standard" since this - like many other things, > e.g. Units - was not invented by Borland but by UCSD. But UCSD was non-standard, too, wasn't it? Just out of curiosity, it doesn't really matter to me. -- Frank Heckenbach, Erlangen, Germany heckenb(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

Portability questions (Arrays)
by Frank Heckenbach 02 May '97

02 May '97

Hi everyone! Two questions about portability of properties of arrays: Let's assume a:array[x..y] of t (not a packed array). 1. Is it safe to assume -- for all platforms, including possible future ones -- that SizeOf(a) = ((Ord(y)-Ord(x)+1) * SizeOf(t)? 2. Is it safe to assume that Integer(@a[p])-Integer(@a[q]) = (p-q) * SizeOf(t)? (Is it generally allowed to cast a pointer into an integer, in the first place?) -- Frank Heckenbach, Erlangen, Germany heckenb(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 Frank Heckenbach 02 May '97

02 May '97

Christian Wendt wrote: > PG>> not "impossible"- you only got to reinvent the wheel and write to > PG>> $b80000... _big_ loss in portability & comfort (no easy to call writeln. > PG>Nevertheless this will remain my preferred method in BO5. The fastest > PG>thing you can imagine on the DOS platform. > hmm. is the type of "file" specified in the ISO /Extended? > would it be possible to define it similar to TP/BP? > there's a list of procedures inwith the file "record" - they specify the > functions to init/flush/writebuffer/readbuffer (theoretical you could do > the same with an object...) I assume you mean BP's TFDD (Text File Device Drivers). BTW: It's for "Text", not for typed are untyped files (though there's actually no reason why it shoudln't apply to them, too, except that BP's doesn't). Indeed, I'd like to have something like this in gpc, too. I'm not at all familiar with the internals of "Text" files (or other files) in gpc. (ISTR, it has something to do with "bindable" variables, but I don't know much about those, either.) First a short explanation for those not familiar with BP: Basically, TFDDs allow the programmer to assign procedures with the following semantics to a "Text" variable to be used instead of file I/O: Open: Input: File mode (Reset / Rewrite / Extend (aka Append)) Read: Input: Buffer size Output: Actual size read (<= Buffer size); the value 0 signals an EOF -- but perhaps it would be better to have a separate EOF function (e.g. for things like serial ports that may have no data at one time, but get some data later). Data that were read (in the buffer) Write: Input: Data in buffer Size Flush: (the same as Write, except that it should additionally "physically flush the file", as far as that makes sense -- I can't remember any examples where this did anything different than Write) Close: - All procedures also have an "error code" as Output to signal un-/successful completion of the operation. The TFDD can have a local data space (in BP: up to 16 bytes, AFAIR) -- local to the file to distinguish different "instances" of files assigned to a particular TFDD. (Here we see the similarities to objects...) The big advantage is that one can do a Write[ln]/Read[ln] with all its possibilites and have the data automatically "piped" to certain routines. Sure, one could achieve the same in gpc with WriteStr/ReadStr and passing the string to the routines, but (a) it's not completely as easy (2 statements instead of one), (b) managing the "local data" would require additional effort everywhere this is used, (c) it's not TP compatible..., (d) a TFDD can be used transparently (e.g. a variable assigned to a TFDD can be passed to any procedure that wants a "Text" file). The particular syntax (and other things) BP uses for this is, IMHO, not very nice (it was introduced after the "good days" of Borland, but before the introduction of OOP, which could have simplified things), so I don't vote for copying BP's mechanism. But any way to do such things would be good. In fact, many of my units use TFDDs, and I can't see a "good" way of porting programs that use them to gpc (only perhaps with heavy use of the preprocessor, but I'd not like to do it like that). I'd not complain at all if it was done with OOP (i.e. "Text" would be an object type, the "procedure" above would be methods, the local data would be the fields of the object), the main thing is that the object could be used in simple Read[ln]/Write[ln] statements. Any chances to do something like this with reasonable effort? -- Frank Heckenbach, Erlangen, Germany heckenb(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: What is standard, and what isn't?
by Peter Gerwinski 02 May '97

02 May '97

According to Nils Bokermann: > How do you want to compare structured variables? Compare member by > member? Yes. Except with types where we know that a simple byte compare is sufficient. > I knew a very fine programming language (ELAN) in which it was possible > to define your own operator (`=', `<>' or whatever you wanted). Is it > possible to have this as an extension to Pascal? It's a PXSC extension which is already in GPC: Operator = ( x, y: MyType ) result: Boolean; begin (* MyType = MyType *) result:= ( x.foo = y.foo ) and ( x.bar = y.bar ) or whatever; end (* MyType = MyType *); 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: Modifying string length?
by Peter Gerwinski 02 May '97

02 May '97

According to Frank Heckenbach: > > s:='' should do the same. (BP optmizes this to just setting the length to 0, > I hope gpc does as well.) It does. (But better check it, too - I already was wrong once with statements of this type.;-) > I think it should (at least with {$X+} or such), because it's the only way > to translate some kinds of procedures -- unless one wants to limit such > procedures to borland-like short strings. Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )". > The question is, should the #0 be added for short strings as well? > If Length=Capacity, it's impossible, but otherwise??? We could increase the space allocated for a short string by 1, but this would break compatibility to UCSD and Borland Pascal. So better ignore this and live with "String [ 255 ]" having only a capacity of 254 in fact. > Currently the length could probably be changed by writing to > s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-| No. This will only work for lenghts below 256 and on big-endian machines. Better cast the String to a record (read: cast a pointer to the String to a pointer to a record). > BTW: Does the standard require range checking (or does it say anything about > it at all)? Yes, AFAIK. > And with {$X-} they don't work at all, you mean? Seems ok. > And the same for packed records? Yes. > Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) I would not call this "non-standard" since this - like many other things, e.g. Units - was not invented by Borland but by UCSD. > BTW: String[n] with n>255 wouldn't work at all then? Yes. 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: stdin/stdout
by Peter Gerwinski 02 May '97

02 May '97

According to Andreas Bauer: > > can you please explain me how to use the stdin/stdout with gpc? > The compiler does not seem to know these. The "legal" way is to use ordinary `read', `readln', `write', and `writeln' operations. Note that `read' returns a space at the end of a line, not a chr ( 10 ) or chr ( 13 ), and that `eoln ( Input )' is `true' instead. > It *does* work when stdin/stdout are connected to the terminal, but > when using pipes it seems not to work. It should work except that the first char is "eaten" by the GPC RTL. See the thread "[BUG] GPC - a char killer?" on 7. and 11. April in this list for reasons and a workaround. 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]

1 0

Re^5: Legal Change in GPC ?
by Peter Gerwinski 02 May '97

02 May '97

According to Christian Wendt: > > PG>The same stuff as in Borland's CRT, isn't it? > Hmm. no - several stuff. > move; > declaration of byte... > paramstr,paramcount > (the date is 27.10.96) - seems to be an extract of tools/system.pas of BO5 We are speaking of different Units: You mean `bpcompat.pas' while I am speaking of `bpcompat.zip' which contains `system.pas', `crt.pas', etc. > hmm. is the type of "file" specified in the ISO /Extended? You mean the internal structure of the `file' type? No. > would it be possible to define it similar to TP/BP? > there's a list of procedures inwith the file "record" - they specify the > functions to init/flush/writebuffer/readbuffer (theoretical you could do > the same with an object...) It's defined in a quite different way. The record contains a lot of interesting information about the file, but no `hooks'. The actual input/output is done via `ordinary' functions written in C. But be invited to implement those `hooks' in the GPC RTS. > PG>Of course. But a CRT Unit could use these sequences to access the > PG>terminal in a portable way. > Yes... transparent for the programmer... Everything is transparent for the programmer since you have the source code of everything. :-) 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

problem with gpclib.a (alpha-version)...
by Peter Gerwinski 01 May '97

01 May '97

According to Andreas Eckleder: > > ...i've got some problem with the library file of the actual (?!?) > alphaversion of gnu-pascal... (* Du meinst: "current" version? ;*) Obviously not - see below. > [...] > > the other problem i realized with this alpha-version is that i couldn't > manage to use the inline assembler. > i only only got a message telling me function asm() not beeing existent. This was a but in some old alpha versions of GPC which is fixed now. The current version is gpc-970420 (see my signature). BTW, the GPI file format changes with (almost) each version, so please recompile your units after upgrading. > because of this strong behavior i use the gpc2.0 compiler with the alpha- > libraries...perhaps THIS is the reason why the function above doesn't > work, > but i am not quite sure about that... (* That's what alpha versions are for: To find all bugs before releasing it to the public. :*) Please try again with gpc-970420 - or with gpc-9705?? ... perhaps this weekend ... 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]

2 1

Re: Modifying string length?
by Frank Heckenbach 01 May '97

01 May '97

The African Chief wrote: > >But how would you translate references to s[0] in BP then? I know, there > >shouldn't be any in most programs, but sometimes it can be useful, e.g. for > >efficiency. But it's ok for me if it's only enabled with {$X+}, see below. > > "s[0] := ..." is okay. But you couldn't do that with long strings since their length isn't stored in [0], but in .length. So there are cases where write access to .length is needed, that's what I meant. > I do that myself sometimes (but only to set the length to zero). s:='' should do the same. (BP optmizes this to just setting the length to 0, I hope gpc does as well.) > "length(s) := ...." > or "s.length := ..." > > - which shouldn't compile (if at all), when using "--borland-pascal". I think it should (at least with {$X+} or such), because it's the only way to translate some kinds of procedures -- unless one wants to limit such procedures to borland-like short strings. > >Does this mean strings will always have an additional trailing #0? Do the > >string routines currently support this (i.e. automatically add a #0 at the > >end; but they should not recognize #0 as a terminator, but only rely on the > >length field)? That would be good, because it simplifies converting a string > >into a CString a lot (just "CString(@s[1])", right?). > > Delphi 2 does this with long strings (I think). If we are going to do it, > perhaps it should only be done for long strings as well? > > However, what happens when you want to add a string to > the end of it? Check this example, and look at the ouput > under Borland; > > program Fred; > var > s,s1:string[40]; > begin > s := 'Fred Smith'+#0; > s1 := s + 'is okay'; > writeln ( s1 ); > {prints "Fred Smith is okay" - where did the space before "okay" > come from? I didn't want or put it there - viz; problem with trailing "#0"} > end. As Peter has already pointed out, an implicit #0 would not behave like this. I suppose this would be achieved by having the length not include the #0. So the internal representation of 'foo' would be something like: Long string: Capacity:...; Length: 3; string: ('f','o','o',#0,...) Short string: (#3,'f','o','o',#0,...) The question is, should the #0 be added for short strings as well? If Length=Capacity, it's impossible, but otherwise??? BTW: Your example raises the "problem" that if you have a string with one or more #0 in it, and convert it to a CString, the CString will be shorter than expected. But I think there's nothing to be done about it. If one wants to convert a string to a CString, one just must not put any #0 in it... Peter Gerwinski wrote: > > But how would you translate references to s[0] in BP then? I know, there > > shouldn't be any in most programs, but sometimes it can be useful, e.g. for > > efficiency. But it's ok for me if it's only enabled with {$X+}, see below. > > That's one reason why `StortString's should be implemented - which will > have "s[0]". But this job doesn't have high priority for me ... As I said above, it would (currently) suffice for me if "s[0]:=..." could be translated to "s.CurrentLength:=..." for long strings. But at the moment, it can't be translated at all. The BP syntax "s[0]" is, IMHO, not very good, so it should not be supported (emulated) for long strings. > > Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off > > around code that needs it, and be safe from accidents elsewhere). It would be > > even better than BP (where accidental writes to s[0] are not even detected > > by range checking). :-) > > As long as GPC has no range checking at all ... I know... Currently the length could probably be changed by writing to s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-| BTW: Does the standard require range checking (or does it say anything about it at all)? > "CurrentLength"? Why not. > What about this: With (*$X+*), addresses of packed array members are > only rejected if they don't lie on a byte boundary, and otherwise they > work? And with {$X-} they don't work at all, you mean? Seems ok. And the same for packed records? > Another idea, perhaps even better: let "String ( 255 )" or > "LongString ( 255 )" denote an Extended Pascal (long) string, but > "String [ 255 ]" or "ShortString [ 255 ]" an UCSD Pascal (short) > string? Like this, both Extended Pascal and Borland Pascal programs > will just compile. Needless to say that `--extended-pascal' will > switch off "String [ 255 ]" and `--borland-pascal' will switch off > "String ( 255 )" ... Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) BTW: String[n] with n>255 wouldn't work at all then? Seems ok to me. -- Frank Heckenbach, Erlangen, Germany heckenb(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

Please delete me from your mailing list
by Cristian Sala 01 May '97

01 May '97

Please cancel my registration to your mailing list tank you Cristian Sala

1 0

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