Daniel,
Yes sorry I should have mentioned that I sent the source
seperately because the listserv doesn't like attachments. See
below,
Tim Josling
"Daniel H. Ardison" wrote:
>
> Tim,
>
> Forget the mails I sent you during the weekend, today I found the mail you
> sent me with the bugs at the office.
> Regarding the bugs I have this comments:
>
> - cobr_insind.c
>
> The way I see it indexof returns 0 if there is no mutch, and returns
> position starting at 1 otherwise. If I need to use 0 starting position I
> will substract the returned value. I took this from awk indexof interface. I
> could change this to return -1 if you want, but I will need to change the
> use of indexof on the other routines.
> Maybe I should comment at the begining of the file that starting position
> returned is 1, ok I will do it.
You are right it is not a bug. So if the substring starts at
offset 0 then you return 1, if at offset 2 you return 2, etc, if
not found you return 0 - is that right? Commenting to clarify it
is OK, although returning a pointer may be more elegant. But it
is up to you - adding a comment would suffice; I don't want to
get into micromanaging anyone's coding, as long as the code is in
the FSF standards.
>
> - cobr_insrep.c
>
> I agree with you that could be a memory leak and that I don't check for
> allocation success.
> Now, talking about checking, in which way runtime errors will be treated?
> You define all the interfaces returning void, Do you want that I use errno?
> I don't see that the caller could pass some auxiliar memory area, this is
> basically local info for local processing, I don't see why the caller should
> know that the routine needs auxiliar memory. I see returning a rutime error
> is the only way at the moment.
Storage allocation: the caller is the compiler so it is OK to
expect it to do certain things like pass a workarea, that you may
not want to do in a normal API- the compiler and runtime are
tightly linked. Normally I would only want to do getmains for
something that is inherently slow like IO or sorting. It looks
like you want three ints per replacing count, which should be
easy to provide.
Error handling: COBOL has no provision for this outside of some
of the IO. The caller can expect that inspect will work or the
program will die. So how to die? Just call abort() for now and
put in a comment that we need to have a standard way to have the
runtime crash (/* lll; need to have a standard way to abort */
where lll; is just a way to mark code that needs to be worked on
later .
>
> Please let me know what you think.
>
> Regards,
>
> Daniel
|
