Hi Spencer,

"Spencer Kinder" [email protected] wrote:

Hi I just have a couple questions for the project/submission,

First, is the project submission section the sandbox we can use? And will we be able to take multiple "attempts" at submitting because it looks like a test format and I want to be sure before I use it.

I'll enable the test sandbox shortly. But really, you shouldn't rely on it, and it won't help you much. The project spec and the labs make it clear that part of the work of the project is for students to make use of sanitizers, static analysis, and testing (at a variety of levels of optimization). The testing area will not enable these for you – students should have already completed labs on all these topics, and be able to put the ideas into practice themselves. However, if you're completely stumped for testing ideas, then the test sandbox might provide some inspiration as to some (minimal) tests you could implement.

Another question is about the preconditions, as far as I can tell the user will need to ensure that the preconditions are met and we (the designer) don't need to check them. However it seems that the we need to meet the precondition that "cipher_text must point to a buffer of identical length to plain_text" as there is no way for a user to supply this. My question is then do we need to check the other preconditions?

In general, regarding preconditions: you'll have to interpret this for yourself, I'm afraid. Preconditions were discussed in lectures, and it's now up to you to correctly apply what was covered.

Regarding the cipher_text: I'm not clear why you think a user (I assume you mean "a caller of the functions") has "no way to supply this". Why wouldn't they?

Also just a small thing about the include for the crypto.h file, when submitting do we use include <crypto.h> instead of "crypto.h"?

  From recollection, the spec says <crypto.h>, but in this case, Moodle will accept either.

I hope that helps — let me know if you need any clarification.

cheers,

Arran

Hi Spencer,

"Spencer Kinder" [email protected] wrote:

The other two questions still stand, but I just remembered that the user can call the functions and cli is just for testing, please ignore the second question.

The cli function is an important deliverable for the project, and is definitely not "just for" testing! You may want to review last week's lecture, since I discussed the cli function and its purpose in a reasonable amount of detail.

Also, I suggest it might be an idea to mentally replace "user" with "developer" when thinking about the project. (Or at least when posting about it.) In the software and illegal narcotics industries, "user" normally means the final end-user of a product. Most users will never see an API – it's developers who do that. (The distinction does become a bit blurred in some cases, since there are products – say, the REST endpoints exposed by enterprises like GitHub, Amazon, Azure, etc. – which essentially are just APIs.)

In this project, we are not told anything at all about end-users or what their requirements might be. Presumably, the API we're implementing is intended to be incorporated into some command-line application, but that's outside the scope of the project.

Cheers,

Arran