Re: Debug my program please.

TC <tecomeco@xxxxxxxxx> wrote:
[code elided]

> I have an error in to recursive function aggiungi(i)at first recursion.

Again, the nag compiler points out a few interesting things,
though this time I get far enough to compile (once I remove the
colons from the case statements and unwrap a few lines. You ought to
fix the nonstandard case statements, but I understand that it might
take more work for you to figure out how to keep the lines from
wrapping than it takes for me to unwrap them - not a big deal).

Nag observes that the pointer X in subroutine scansoine is never
dereferenced, which makes one wonder why the code bothers to
define it in the first place. Perhaps this is an extract or
building block for something larger in which it would be used,
so this isn't necessarily an error, but it does at least call
one's attention to it. Likewise pointer Z in crealberof is never
dereferenced. (Added later... Oh, I see. This is because you
have Aggiungi as a function and need some way to just ignore its
result. See comments below about functions that return pointers.)

Well, time for me to actually try to figure out what the program is
doing... My ignorance if what I presume to be Italian is a slight
hindrance, but I can guess enough to manage at this level, and I
do claim to be able to read the Fortran parts. :-) I hope you can
read my English better than I can read Italian, or I'm wasting my
time writing this. :-( ...

As a side note, I see that that scansoine has a compiler-dependent
value for iostat. The value -1 is a common one, but is not standard.
I recommend just testing whether the value is negative (that much is
in the standard) unless you have specific reason for distinguishing
eof from eor. Perhaps you do want to distinguish, in which case you
might want to at least make a note that this is compiler-dependent.
I like to put compiler-dependent things like that in a separate file
(I prefer in a module, though an include file also works) in order to
facilitate porting, though if this is just a learning excercise, that
might not be as important. Oh, I also see a hard-wired iostat value
of 128 in the main program for "File non trovato" (file not found?),
which is completely compiler-specific.

Another side note. I see the following declarations in scansoine
integer :: i = 1
integer :: d = 1
Do you know what those initializations do? Is it what you really want?
In particular, those variables are initialized to 1 only on the first
call to scansione. On any subsequenty calls to scansoine, they just
retain whatever values they had from the end of previous call. While
I'm not sure yet, I suspect that this isn't what you want.
If you want to set the values to 1 at the beginning of every call,
then use an executable assignment statement.

I'm slightly curious why alphabeto is declared with length 74, but
only 72 characters are used, but that's clearly another side issue.
(And I see that alf isn't ever used, but I suppose that could change.)
And is alphabeto really supposed to have the lower-case letters twice,
with no upper case ones? That's clearly not the immediate problem, but
I wonder.

I notice the reference to parola(d:) in scansione. While I can see a
possible reason for writing it that way, the reason is pretty subtle.
It is ok, but is the subtlety intentional? In case this isn't
intentional, what I see is that the "obvious" form here is parola(d:d),
but writing parola(d:) keeps you from exceeding the declared length of
parola in case there is a long word in the data. I'd have handled that
in a more explicit way, but this does actually work.

I notice that you have functions that return pointers as results.
I strongly recommend that subroutines instead of functions be used
for purposes like this. While functions that return pointers are
allowed, they are *VERY* error prone, even for expert users. Even
if this isn't related to the error in this code (which I haven't yet
found), I recommend avoiding the practice, because it is likely to be
the source of an error in a future one.

I'm not getting an error at the place where you indicate in Aggiungi.
Nor do I see anything horribly wrong there. I suspect you meant to
indicate that there was an error at the corresponding place in
AggiungiF, where I also seem to be seeing a crash.

I'm slightly puzzled by the logic in print, where you don't descend
either the right or left subtrees unless both exist. It doesn't crash,
but I'm not sure it does what you wanted.

Aha. Found it. See my mention above about functions that return
pointers being error prone. Well, you got caught by one of the
classic errors of them. The recursive invocations of AggiungiF
invoke it with i%s= and i%d= instead of i%s=> and i%d=>. Fixing
this gives a program that runs without crashing, at least for
the trivial 2-word test file that I experimented with. I don't
think it quite yet does what you want (see above comments about
print), but this fixes the crash.

> Error: the instruction attemp read from location 000000.
> Is right that is null, but why "if (.not. associated(i)) then" make this
> error?

Once you've made an error with pointers like that, all subsequent bets
are pretty much off. Compilers aren't generally good at catching these.
The code is probably actually crashing on teh assignment statement,
as it attempts to dereference the null pointer instead of associating
it as you intended.

P.S. Functions that return pointers are so error prone that I'm
inclined to ignore requests for help with code that does that.
I figure that people who choose to ignore my advice on that
don't get my help in debugging the consequences. Novices who
haven't yet had the chance to hear my advice get the benefit of
the doubt, and I'm more likely to spend the time to help...
once. :-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.