Thread: [ooc-compiler] Position of runtime error
Brought to you by:
mva
|
From: August K. <fus...@co...> - 2005-05-12 00:57:12
|
Hello all,
In runtime error messages, OOC outputs the position where the error
occurred but no info on line (or column) number, for instance:
##
## Runtime error in module Test at pos 171
## Dereference of NIL
##
It's kind of hard to find the position in an editor that lacks Emacs'
`goto-char' function and even for Emacs users it would be more
convenient with a line (and a column) number.
If the function _runtime_error in lib/src/RT0.c made a call to the
function GetLineAndColumn below the error message could be output as for
instance:
##
## Runtime error in module Test at pos 171 (line 11, column 3)
## Dereference of NIL
##
Comments?
Regards,
August
(I suspect that there may be some library function somewhere that does
the same thing as GetLineAndColumn)
/*
* GetLineAndColumn(f, p, &ln, &c) calculates line number ln and
* column number c corresponding to position p in file f .
*
* precondition: p > 0
*
* postcondition: ln > 0 and c >= 0
*/
static void GetLineAndColumn(const char *filename, int pos,
/*@out@*/ int *line, /*@out@*/ int *column)
{
FILE *f;
int i, c, ret;
assert(pos > 0);
f = fopen(filename, "r");
if (f == NULL) { perror(__func__); exit(EXIT_FAILURE); }
*line = 1;
*column = 0;
for (i = 1; i < pos; i++) {
c = fgetc(f);
if (ferror(f)) {
perror(__func__); exit(EXIT_FAILURE);
} else if (feof(f)) {
fprintf(stderr, "%s: Reached end of file\n", __func__);
exit(EXIT_FAILURE);
} else if (c == '\n') {
(*line)++; *column = 0;
} else {
(*column)++;
}
}
ret = fclose(f);
if (ret == EOF) { perror(__func__); exit(EXIT_FAILURE); }
assert((*line > 0) && (*column >= 0));
}
|
|
From: Stewart G. <sgr...@ii...> - 2005-05-13 14:10:32
|
Hi August, > In runtime error messages, OOC outputs the position where the error > occurred but no info on line (or column) number, for instance: > > ## > ## Runtime error in module Test at pos 171 > ## Dereference of NIL > ## > > It's kind of hard to find the position in an editor that lacks Emacs' > `goto-char' function and even for Emacs users it would be more > convenient with a line (and a column) number. [...] You can get this information using the 'ooef' utility. For example, ooef src/Test.Mod 171 This gives you the source code context (the default behaviour, also available via the --context switch). If you just want to know the line and column you can do: ooef --linecol src/Test.Mod 171 Hope this helps. Cheers, Stewart |
|
From: Marco O. <Mar...@we...> - 2005-05-14 17:14:21
|
Hello! I have been working too little with oo2c in recent months so I did not even remember "ooef" before Stewart Greenhill mentioned it. But after that I even remembered how I used and I tried it again. Just pipe the output to ooef. As you can see below ooef finds line number and column for each source file with error or warning. I have oo2c 2.1.4 installed, but it should work also with current version. bash> oo2c -M ExtractPopNeu |ooef src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined src/ExtractPopNeu.Mod:76:25: Undeclared identifier src/ExtractPopNeu.Mod:80:25: Undeclared identifier src/ExtractPopNeu.Mod:89:25: Undeclared identifier src/ExtractPopNeu.Mod:92:25: Undeclared identifier Greetings, Marco ----- Original Message ----- From: "Stewart Greenhill" <sgr...@ii...> To: "August Karlstrom" <fus...@co...> Cc: <ooc...@li...> Sent: Friday, May 13, 2005 4:13 PM Subject: Re: [ooc-compiler] Position of runtime error > Hi August, > >> In runtime error messages, OOC outputs the position where the error >> occurred but no info on line (or column) number, for instance: >> >> ## >> ## Runtime error in module Test at pos 171 >> ## Dereference of NIL >> ## >> >> It's kind of hard to find the position in an editor that lacks Emacs' >> `goto-char' function and even for Emacs users it would be more >> convenient with a line (and a column) number. > [...] > > You can get this information using the 'ooef' utility. > > For example, > ooef src/Test.Mod 171 > > This gives you the source code context (the default behaviour, also > available via the --context switch). If you just want to know the line > and column you can do: > ooef --linecol src/Test.Mod 171 > > Hope this helps. > > Cheers, > Stewart > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > ooc-compiler mailing list > ooc...@li... > https://lists.sourceforge.net/lists/listinfo/ooc-compiler > |
|
From: August K. <fus...@co...> - 2005-05-14 22:02:28
|
Marco Oetken wrote: > Just pipe the output to ooef. As you > can see below ooef finds line number and column for each > source file with error or warning. I have oo2c 2.1.4 > installed, but it should work also with current version. > > bash> oo2c -M ExtractPopNeu |ooef > src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined > src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined > src/ExtractPopNeu.Mod:76:25: Undeclared identifier > src/ExtractPopNeu.Mod:80:25: Undeclared identifier > src/ExtractPopNeu.Mod:89:25: Undeclared identifier > src/ExtractPopNeu.Mod:92:25: Undeclared identifier This is the kind of output I get by default from oo2c 2.1.8 without using ooef (not sure if ooef has any effect in this case). It's the runtime errors I'm talking about, not compilation errors. Thanks anyway. -- August |
|
From: August K. <fus...@co...> - 2005-05-14 22:06:09
|
Stewart Greenhill wrote: > Hi August, > >> In runtime error messages, OOC outputs the position where the error >> occurred but no info on line (or column) number, for instance: >> >> ## >> ## Runtime error in module Test at pos 171 >> ## Dereference of NIL >> ## >> >> It's kind of hard to find the position in an editor that lacks Emacs' >> `goto-char' function and even for Emacs users it would be more >> convenient with a line (and a column) number. > > [...] > > You can get this information using the 'ooef' utility. > > For example, > ooef src/Test.Mod 171 > > This gives you the source code context (the default behaviour, also > available via the --context switch). If you just want to know the line > and column you can do: > ooef --linecol src/Test.Mod 171 Ok, thanks. I still don't understand why the runtime can't output line and column as oo2c does by default. -- august |
|
From: Stewart G. <sgr...@ii...> - 2005-05-16 01:15:36
|
On 15/05/2005, at 6:06 AM, August Karlstrom wrote: > Stewart Greenhill wrote: >> You can get this information using the 'ooef' utility. >> For example, >> ooef src/Test.Mod 171 >> This gives you the source code context (the default behaviour, also >> available via the --context switch). If you just want to know the >> line and column you can do: >> ooef --linecol src/Test.Mod 171 > > Ok, thanks. I still don't understand why the runtime can't output line > and column as oo2c does by default. It could output this information, but that would require some changes to the way source position is encoded for run-time errors. Currently, oo2c uses the module descriptor and a single integer (ie. character position). I think a single integer would still be enough if (for example) 8 bits were used for column and 24 bits for row. The current solution works well for me. Usually, I want the line number and a little bit of source code context so I have to run an external program anyway. Cheers, Stewart |
|
From: August K. <fus...@co...> - 2005-05-26 00:47:05
|
If I compile and run the following program I get a segmentation fault
rather that a run time exception.
MODULE Test;
PROCEDURE P;
VAR p: POINTER TO ARRAY OF LONGINT;
BEGIN
p[0] := 1
END P;
BEGIN
P
END Test.
So in this regard the above program compiled with OOC is just as unsafe
as a C program. Wasn't the elimination of wild pointers one of the
design criteria of Oberon?
-- August
|
|
From: Stewart G. <sgr...@ii...> - 2005-05-26 01:14:34
|
Hi August,
> If I compile and run the following program I get a segmentation fault
> rather that a run time exception.
>
> MODULE Test;
> PROCEDURE P;
> VAR p: POINTER TO ARRAY OF LONGINT;
> BEGIN
> p[0] := 1
> END P;
> BEGIN
> P
> END Test.
>
> So in this regard the above program compiled with OOC is just as
> unsafe as a C program. Wasn't the elimination of wild pointers one of
> the design criteria of Oberon?
OOC generates the following warning for this code.
In file src/Test.Mod:
PROCEDURE P;
VAR p: POINTER TO ARRAY OF LONGINT;
BEGIN
p[0] := 1
#--------^
# 5: Warning: Undefined variable
END P;
BEGIN
P
OOC V1 used to support the optional initialisation of stack-based
variables (obviously, with a performance cost) via the "Initialize :=
TRUE" pragma. I'm not sure if this feature made it into the V2
compiler. Generally, if you check the compiler warnings it will pick up
most of these cases.
Cheers,
Stewart
|
|
From: August K. <fus...@co...> - 2005-05-28 01:55:51
|
Stewart Greenhill wrote: > > Hi August, > >> If I compile and run the following program I get a segmentation fault >> rather that a run time exception. >> >> MODULE Test; >> PROCEDURE P; >> VAR p: POINTER TO ARRAY OF LONGINT; >> BEGIN >> p[0] := 1 >> END P; >> BEGIN >> P >> END Test. >> >> So in this regard the above program compiled with OOC is just as >> unsafe as a C program. Wasn't the elimination of wild pointers one of >> the design criteria of Oberon? > > > OOC generates the following warning for this code. > > In file src/Test.Mod: > PROCEDURE P; > VAR p: POINTER TO ARRAY OF LONGINT; > BEGIN > p[0] := 1 > #--------^ > # 5: Warning: Undefined variable > END P; > BEGIN > P > > OOC V1 used to support the optional initialisation of stack-based > variables (obviously, with a performance cost) via the "Initialize := > TRUE" pragma. I'm not sure if this feature made it into the V2 compiler. > Generally, if you check the compiler warnings it will pick up most of > these cases. > > Cheers, > Stewart > > OK, thanks. Maybe a warning is enough. -- august |