CBFalconer wrote:
> Emil Jerabek wrote:
> >
> ... snip ...
> >
> > Sorry, should think twice before submitting a bugreport. The story with
> > "file of record end" is more complicated then I wrote.
> >
> > The test below should pass for any type (which is permissible as
> > a file component-type, of course). It indeed works with, say,
> > "file of Integer", but with the empty record type it fails:
[...]
> >
>
> I have not …
[View More]checked the standards, but is the problem accepting the
> empty record? It seems like a pointless thing to do, leading to
> all sorts of problems, such as:
>
Sure, it is completely pointless, except that it _is_ mandated by the
standard. Namely, section 6.4.3.4 (Record-types) of ISO 10206 says:
...
record-type = `record' field-list `end' .
field-list = [ ( fixed-part [ `;' variant-part ] | variant-part ) [ `;' ] ] .
...
A field-list containing neither a fixed-part nor a variant-part shall have
no components, shall determine a single value-bearing state bearing a null
value, shall be designated empty, and shall denote the totally-undefined
initial state.
...
> TYPE per = ^emptyrecord;
> VAR erarray : ARRAY[1..N] OF emptyrecord;
>
> ...
> new(per);
> erarray[i] := erarray[j];
> erarray[i] := per^;
> per^ := erarray[i];
> dispose(per);
>
Well, what's the problem here? All these assignment statements are
simply no-ops.
> etc. Accepting that has further problems with the design of the
> memory allocation mechanism - I have just built one for DJGPP and
> had to detect a zero size and increment it, otherwise storage
> needed for free block tracking would have been missing. The
> ramifications of an empty object go on and on and on and ....
>
> --
> Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net)
> Available for consulting/temporary embedded and systems.
> (Remove "XXXX" from reply address. yahoo works unmodified)
> mailto:uce@ftc.gov (for spambots to harvest)
>
Emil Jerabek
[View Less]
CBFalconer wrote:
> Emil Jerabek wrote:
> >
> > it seems that GPC ignores the upper bounds of $SUBJ when they are
> > automatically converted to CString:
> >
> > [pas]% cat slice.pas
> > program Foo (Input, Output);
> >
> > procedure Bar (S: CString);
> > begin
> > {$local X+}
> > WriteLn (S)
> > {$endlocal}
> > end;
> >
> > var
> > S: String (20);
> >
> > begin
> > …
[View More] S := 'failedOKfailed';
> > Bar (S[7 .. 8])
> > end.
> > [pas]% gpc slice.pas
> > [pas]% ./a.out
> > OKfailed
>
> Is this part of any standard? or is it yet another extension? The
String slices (and, more generally, array slices) are defined
in ISO 10206. CString's (and implicit conversion of String's to
CString's) are a GNU extension.
Emil Jerabek
> way I handled this in PascalP (a 7185 compiler) was with the
> extension "dest := array[7 FOR 2]" (which was Doug Fraleys idea,
> and may still be in HP Pascal). dest should then be of type
> ARRAY[1..2]. The same construct could be used on the dest side,
> i.e. "dest[7 FOR 2] := 'OK';" Everything could be checked at
> compile time for constant indices and lengths, and run time checks
> were no harder than any other index check.
>
> --
> Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net)
> Available for consulting/temporary embedded and systems.
> (Remove "XXXX" from reply address. yahoo works unmodified)
> mailto:uce@ftc.gov (for spambots to harvest)
>
[View Less]
[ Sorry Frank, for sending it to your privat address first ]
On Tue, Mar 19, 2002 at 12:50:52AM +0100, Frank Heckenbach wrote:
> Carel Fellinger wrote:
>
> > How can I get more details on that bug? I can't find the file
> > daj3.pas on my machine.
>
> It's part of the GPC source distributions, or the separate test
> suite distributions in
> ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/.
Okee, downloading both.. I see a file dajmod3.pas, no daj3.pas, …
[View More]seems
like half of the test:) But I get the idea.
> > Does this apply to constant strings only, so can you program around it
> > by declaring var's and initialize them in the init-code of the
> > implementation module? Sure hope so.
>
> No, it applies to variables declared in a module interface.
Did me own test, and it seems that explicitly initializing the var
as part of the var declaration can serve as a workaround, like in:
module c interface;
export c = all;
type s = string(25); { comments, -> output }
var x : s = 'pipo de clown'; { this seems to work }
y : s = ''; { this seems to work }
z : s; { this one fails }
end.
module c implementation;
to begin do
begin
y := 'mama lou'; { this is caried over }
z := 'invisible'; { useless }
writeln(z.capacity, z, length(z)); {-> 00 }
end;
end.
program b;
import c;
begin
writeln(x.capacity, x, length(x)); {-> 25pipo de clown13 }
writeln(y.capacity, y, length(y)); {-> 25mama lou8 }
writeln(z.capacity, z, length(z)); {-> 00 }
x := 'spam';
y := 'and';
z := 'eggs';
writeln(x.capacity, x, length(x)); {-> 25spam4 }
writeln(y.capacity, y, length(y)); {-> 25and3 }
writeln(z.capacity, z, length(z)); {-> 00 }
end.
I sure hope this is inline with your understanding of the bug as I need
this feature in that largish 80's program I'm porting.
--
groetjes, carel
[View Less]
Hello,
is there a way, similar to Delphi, to convert float or integer values into a
string? I mean something like the FLOATTOSTR or FORMATFLOAT function.
Thank you, regards
Silvio a Beccara
> Hi,
>
> I've read that the binaries of the compiler are in the "Binary"
> directory. But in the FTP site there's no such directory.
>
> Thanks for any help.
>
> Aldo
>
Hello,
We tried compiling a source with gpc-20010924 and made changes to the
records by 'packing' them to suit our needs of reading from already existing
files.
But then we changed to gpc-20011215 (we had also installed earlier) and
these changed programs that compiled in gpc-20010924 , give us errors like :
" Cannot take address of bitfield <a field name>"
" packed fields may not be used as `var' parameters "
Can you kindly tell me why this happens because i don'…
[View More]t see it as an explicit
change made after the 24-09 version.
Thanks and Regards,
Anuradha
[View Less]
Hi everyone,
GPC version 20020318, the release candidate #4 for GPC 2.1, has been
uploaded to
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20020318.tar.gz
Compared to RC 3, this release contains only some minor bug fixes
and portability enhancements.
One bug in the recent OOP extensions has been fixed (thanks to
Maurice Lombardi for the report). Some build problems on
Cygwin/mingw have been resolved (thanks to the Chief). Some minor
problems on Linux/S390 have been fixed (…
[View More]thanks to Gerhard Tonn and
Matthias Klose for providing a test account). Some bugs regarding
types of size 0 have been fixed (thanks to reports by Emil Jerabek).
The cooperation with GCC patched for Cygwin/mingw, gcc-2.95.3-5,
gcc-2.95.3-6 and gcc-2.95.4 has been improved.
Frank
--
Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/
GPC To-Do list, latest features, fixed bugs:
http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
[View Less]