May 1997 - Gpc

What is standard, and what isn't?
by Peter Gerwinski 01 May '97

01 May '97

Hello, perhaps somebody can help to clarify the following two questions: 1) Is the comparision with `=' or `<>' of structured variables okay in ISO Pascal? ISO 10206 6.8.3.5 only says that the types to be compared must be compatible. If not, this might be a reasonable extension (already offered by some compilers, *not* including Borland Pascal;). 2) In GPC strings, the schema discriminant "Capacity" is accessible as a "record field" of the string. Is this okay by ISO 10206, and should it be done for other schemata this way, too? And how to tread the "length" field of a string? ISO 10206 6.4.3.3 does not say anything about that. I could imagine the string schema type to be something similar to Type String ( Capacity: Integer ) = record length: Integer; String: packed array [ 1..Capacity ] of Char; end (* String *); except that the "String" field is automatically dereferenced. Thanks for your help, 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 Peter Gerwinski 01 May '97

01 May '97

According to The African Chief: > > 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. It's no space; it's a #0, as you requested. The above is an *explicit* trailing #0. It is part of the string and must not vanish when adding another string. The *implicit* trailing #0 to be appended for CString compatibility *will* vanish; however the program above will still produce the same result. 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 The African Chief 01 May '97

01 May '97

On Thu, 1 May 1997 13:40:14 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> >> 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. > >It's no space; it's a #0, as you requested. Yes. >The above is an *explicit* trailing #0. It is part of the string and >must not vanish when adding another string. True. >The *implicit* trailing #0 to be appended for CString compatibility >*will* vanish; however the program above will still produce the same >result. That is okay then. I just thought that the point needed to be made, that there could be a problem with a trailing #0. If the compiler makes the ones that it adds to vanish away, the problem disappears. 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: Modifying string length?
by Peter Gerwinski 01 May '97

01 May '97

According to Frank Heckenbach: > > 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 ... > But, a *packed* array? If I remember correctly, it's not possible to get an > address of a component of a packed record/array (because they could possibly > not start on a byte boundary) (but when trying it, I encountered some > problems, see below). Actually, packed arrays of chars are the same as non-packed arrays. Right now, GPC does not check whether you take the address of a packed array member, so it works with packed arrays of chars, and produces nonsense with Booleans (see below). > If this is so (and won't be changed so that it is possible to get an address > of those components that actually start on a byte boundary), I'd vote for an > un-packed array here. BTW: Is there any advantage in packing here? AFAICS (at > least with Linux), an un-packed array of char is exactly as big as a packed > one. Is this not always so? Extended Pascal requires "packed" here. > 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?). It's not like that, but perhaps it *should* be like that ... > 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 ... \begin{sigh} Following the tradition of a large well-known software company, I could now advertise for GPC by announcing that GPC's range checking, once it will be implemented, will be *much* better than that of Borland Pascal. Although I am sure that this will be true, I don't want to join this vaporware marketing method. \end{sigh} > BTW: Should the field be called "length" like the function length? It might > give conflicts with "with" statements ("with" works with schemata, doesn't > it?) as in: (It does. I thought it would not do.) You are right. It must be renamed then. > Perhaps something like str_length or such? "CurrentLength"? > As I said above, I had some problems with the new packed arrays. I tried the > following: Ah - the first bugs with packed arrays. I will look at them, thanks. 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? > Should the "()" be allowed here [after `@'] (though not required)? > FWIW, TP5.5 doesn't allow them, BP7.0 does... I will have a look at that, too. 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: ShortStr
by Peter Gerwinski 01 May '97

01 May '97

According to Kim Robert Blix: > > When it comes to compability on the issue of strings, would'nt it be > natural to call the short string version just "string" and the long > one "longstr", instead of the other way around? This would break compatibility to the Extended Pascal standard. But it could be reasonable to do it like you wrote in `--ucsd-pascal' and `--borland-pascal' mode. What about the following: Make `LongString' denote Extended Pascal string schemata, and `ShortString' denote UCSD/Borland Pascal strings; let `String' be the same as `LongString' in default mode but the same as `ShortString' in Borland Pascal mode; finally introduce more options `--short-strings' and `--long-strings' to change these defaults? 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 )" ... Anyway, this is a long-term plan. 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 The African Chief 01 May '97

01 May '97

On Thu, 1 May 1997 04:12:47 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> >> It would not be too difficult to make "MyStr.length" and "MyStr.String" >> >> accessible "record fields" of strings. Would it be desireable? >> > >> >Yes! (At least length; the String part is accessible anyway with s[n].) >> > >> >> I am >> >> not sure how this fits into the standard ... >> > >> >I'm not, either. If it conflicts, it should be disabled with >> >"--extended-pascal", I suppose. >> >> It should be disabled, with "-borlland-pascal" as well. > >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. I do that myself sometimes (but only to set the length to zero). What I was referring to was something like; "length(s) := ...." or "s.length := ..." - which shouldn't compile (if at all), when using "--borland-pascal". >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. 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: ShortStr
by The African Chief 01 May '97

01 May '97

On Thu, 1 May 1997 12:29:09 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: > finally introduce more options >`--short-strings' and `--long-strings' to change these defaults? I think this is the key! Introduce a "--short-strings" ( or "{$H-}" ) or whatever, to turn off the default (which should be long strings - because it ensures more compatibility with EP and Delphi 2). I believe that Delphi 2 automatically terminates long strings with a "Chr(0)". Perhaps we should do this as well? 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: ShortStr
by Berend de Boer 01 May '97

01 May '97

"Kim Robert Blix" wrote: >When it comes to compability on the issue of strings, would'nt it be >natural to call the short string version just "string" and the long >one "longstr", instead of the other way around? I think natural should mean the one with the least restrictions. Integers are 32-bit, not 16-bit, strings are unlimited, instead of limited, etc, etc. And this is more compatible with Delphi 2. Groetjes, Berend.

1 0

exit; ????
by skye 01 May '97

01 May '97

Is Exit not included in GPC? i.e. program test; procedure t1(a:integer); begin writeln('hello1'); if a = 1 then exit; writeln('hello2'); end; begin writeln('hello'); t1(1); t1(0); writeln('hello3'); end. should produce: hello hello1 hello1 hello2 hello3 but I get Undefined Indentifier 'Exit' I tried using return; and that works. I posted this question to the comp.lang.pascal NG and had someone from Borland tell me that Exit should do the trick (I didn't say I wasn't using TP tho). Is exit a Borland thing? -SC

2 1

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

01 May '97

The African Chief wrote: > >> It would not be too difficult to make "MyStr.length" and "MyStr.String" > >> accessible "record fields" of strings. Would it be desireable? > > > >Yes! (At least length; the String part is accessible anyway with s[n].) > > > >> I am > >> not sure how this fits into the standard ... > > > >I'm not, either. If it conflicts, it should be disabled with > >"--extended-pascal", I suppose. > > It should be disabled, with "-borlland-pascal" as well. 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. Peter Gerwinski wrote: > 2) In GPC strings, the schema discriminant "Capacity" is accessible > as a "record field" of the string. Is this okay by ISO 10206, > and should it be done for other schemata this way, too? And how to > tread the "length" field of a string? ISO 10206 6.4.3.3 does not > say anything about that. I could imagine the string schema type to > be something similar to > > Type > String ( Capacity: Integer ) = record > length: Integer; > String: packed array [ 1..Capacity ] of Char; > end (* String *); > > except that the "String" field is automatically dereferenced. Oh - I thought a string was like this already. (My previous mails were based on this assumption.) I think I read this somewhere, but don't remember where. But, a *packed* array? If I remember correctly, it's not possible to get an address of a component of a packed record/array (because they could possibly not start on a byte boundary) (but when trying it, I encountered some problems, see below). If this is so (and won't be changed so that it is possible to get an address of those components that actually start on a byte boundary), I'd vote for an un-packed array here. BTW: Is there any advantage in packing here? AFAICS (at least with Linux), an un-packed array of char is exactly as big as a packed one. Is this not always so? > It's "1..Capacity + 1". (Increasing the index by one adds one char.) > > +1 to allow for a trailing zero (or zero's in case of Unicode...). 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?). > What about the following: > > * Default mode (and Extended Pascal mode): The length field cannot > be accessed (except with "length ( MyStr )".) > > * With extended syntax (*$X+*): The length field can be read- and > write-accessed. > > Okay like that? Or perhaps better to have it in default mode, too, > and to switch it OFF in Extended Pascal mode? I think it's best as > above because you should assign a new length to a string only if you > know exactly what you are doing. 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). :-) BTW: Should the field be called "length" like the function length? It might give conflicts with "with" statements ("with" works with schemata, doesn't it?) as in: with dest_str do begin length:=length(src_str); ... end; Perhaps something like str_length or such? > (* By the way: Good news for all friends of schemata! They might be > finished (except, of course, bugs) this week ... *) What? The bugs will not be finished? What an omission! ;-) As I said above, I had some problems with the new packed arrays. I tried the following: program t; var q:packed array [1..10] of boolean; y:^boolean; begin y:=@q[3] end. and it compiled (though I think it shouldn't), giving quite a strange result in y. Then I did: program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@q[i] end. gpc said "invalid lvalue in unary &". Though this shoudln't compile, this error message seems strange to me. I'd have expected "Attempt to take address of bit-field structure member", as with packed records. Next I tried: program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@(q[i]) end. The result was: "parse error before '('" and some more error messages. (The same with an un-packed array here.) Should the "()" be allowed here (though not required)? FWIW, TP5.5 doesn't allow them, BP7.0 does... -- 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