[C-prog-lang-l] Assignment Phase 1 - few questions

[Jan Pechanec]

On Wed, 8 May 2019, Jan Vávra wrote:

Hi Jan,

please see below inline for the answers.

>
>Hello everyone,
>
>I have been working on the assignment for the last two days and it finally
>seems to work. At least all the mentioned examples give me the same type of
>error. But I am not sure about following things:
>
>1) What should be the error message for too long line while reading the 
>document? What are the rules for return value in this case?

As the error message is not specified, you chose.

Exit with 1, I will update the assignment.

>
>2) I have a few expressions I am not sure what their error message should 
>be:

In general, good thinking.

>   * "," --> "Invalid address" or should we implement printing of the whole
>   list (from head to tail)?

>From our spec, I'd say this should fall into "Invalid address" group.

>   * "-" and "--" --> "Invalid address"?

We do not allow '-' in addresses at all, so use "Unknown command".

>   * ".$" and ".$p" --> "Unknown command" or should a missing "," be
>   interpreted as "Invalid address"?
>   * "1x" vs. "1x,1p" --> "Unknown command" vs. "Invalid address"?
>   * "x" --> "Invalid address" or "Unknown command"?
>   * "x," --> "Invalid address" or "Unknown command"?
>   * "q," --> "Invalid address" or "Invalid command suffix"?
>   * "p," --> "Invalid address" or "Invalid command suffix"?

For these, if it's invalid in GNU ed as well, follow its behavior, as
suggested in our spec.  If it's valid in GNU ed but our spec does not
require it and does not specify the exact error, you decide what the
error message is gonna be.

If you follow behavior in our examples, you should be fine.

As a hint, our automated tests pass both for our implementation and
GNU ed as well, without distinguishing those two.

I've updated the specification on our web.

>3) Are there any other weird expressions I should be aware of?

I don't think so.  It's not our intention for you to spend too much
time in weird corner cases.  If we do not define the expected
behavior, we will probably not test it, so use your judgement.

FYI, this is what the UNIX spec says:

http://pubs.opengroup.org/onlinepubs/9699919799/

I'm not sure whether it's clear from there what error "x," should
trigger.

>4) After I deliver my "ed.c" file and the automated tests discover some 
>problems, for example, different error messages than expected, will there be
>possibility to make necessary changes and to hand it in again before the 
>given deadline?

Yes.  We expect you do your best effort to deliver functional code
where all features are implemented but obviously no non-trivial code
is without bugs.  If there are issues, we will go back and forth with
you until we are satisfied.

That said, I want to be explicit for others as well to know that
handing over only a partial implemenation (e.g. some commands are not
implemented at all, etc.) does not count as an accepted hand-over.  So
it's always better to hand it over at least a week before the deadline
or so.

I plan to upload our automated tests to github and I hope I can get to
it within a few days.

>I would really appreciate any answers you could give me. I also hope these Q
>&A will help others as well.

Absolutely, thanks for doing it.

Jan.

>
>Thank you very much,
>
>Jan Vávra

-- 
Jan Pechanec <jp (at) devnull (dot) cz>
http://www.devnull.cz