Hi all, Just checking if I understand the project right, so we need to implement encryption and decryption functions for both the Caesar and Vigenere ciphers, following the provided specifications in the crypto.h header file. Additionally, we'll create a command-line interface (CLI) function to facilitate easy testing of your code. Ensuring code quality by adhering to secure coding practices and proper documentation. Testing thoroughly and handling edge cases are essential for robust implementation. Is that's sound right?

Hi,

Sure, that sounds mostly right. The code really should be pretty easy, so there should be plenty of time to focus on making sure your code is correct, covers edge cases, and is clear and understandable. Therefore markers will expect a fairly high standard when it comes to those things, and to following secure coding best practices.

I will say, though, that whether the implementations should be "robust" is a bit more questionable. Normally when we say "robust", we mean that a program should handle errors gracefully. However, that usually applies only to whole programs, or to user-facing code (as opposed to developer-facing), or code that takes input that could potentially be malformed or from an untrusted source. In this project, there's only one function that falls into that category, namely cli.

All the functions other than cli have clear preconditions and postconditions, and the onus is on the developer calling them to ensure that the preconditions hold. If the preconditions don't hold, the result of the function will simply be undefined (and probably unexpected) – the only thing you can do if you do discover a precondition doesn't hold is use an assert() call to abort operation.

For instance, consider something like the memcpy function in the C library (see here). It's a requirement imposed on the caller that both arguments must point to valid locations in memory, and that they must not overlap, and that reading or writing n bytes from them won't take you out of bounds. Is there anything you could or should do to make an implementation of memcpy "robust"? I'd suggest there isn't, and in any case you shouldn't. However, I'll discuss this more in this week's lecture – stay tuned :)

Cheers

Arran

ANONYMOUS wrote:

> Hi all, Just checking if I understand the project right,
> so we need to implement encryption and decryption functions for both the Caesar and Vigenere ciphers, following the provided specifications in the crypto.h header file. Additionally, we'll create a command-line interface (CLI) function to facilitate easy testing of your code. Ensuring code quality by adhering to secure coding practices and proper documentation. Testing thoroughly and handling edge cases are essential for robust implementation.
> Is that's sound right?

Hello Sir,

Just "Arran" is fine.

If using assert() to check preconditions, doesn't this go against the project specification where it says: never print to standard out or standard error? As I think assert() does print to stderr.

I'm going to ask you to reflect a bit more on your question. Can you think of any ways of resolving this possible contradiction? What are they? Suggest some ideas.

Cheers

Arran

Hi,

Just to clarify, my suggestion was that you come up with (ideally multiple) ways the apparent contradiction might be resolved – the idea here is for students to actively engage with the project specification, and think about how project requirements work and can be clarified in the real world. I encourage that sort of discussion on the forum!

You have proposed that "Using a simple if statement instead of assert() would be better then", but there are a few problems with that. Firstly, I'm not sure I see how that resolves the problem – it doesn't clarify what's going to be done when the if conditional evaluates to true. Secondly, assert statements are already conditional, effectively – they only have an effect if the condition they assert evaluates as false – so it's not clear to me why you think an if statement would be any better. Lastly, I'll gently remind students that it's a good idea to explain your reasoning (this is a good principle to bear in mind for assessments, on the discussion forum, and in the workplace), and when asking questions on the forum, to explain what you've already thought of or tried, and why it hasn't worked. A one-sentence conclusion doesn't really do that.

At any rate: rather than me trying to guess at what you mean and why you said it, I'm going to recommend you take this query to lectures and/or to your labs for discussion with me, other students and/or your lab facilitator. There are still multiple labs and lecture slots available to discuss your questions before the project is due. (Tomorrow's lecture will be particularly appropriate, though, as we'll be discussing API design.)

You also could read in your C textbook about what the purpose of the assert() macro is, and how it's used in development. If the textbook you've chosen doesn't have much discussion of this, then you could take a look at the Seacord Effective C text, which has a reasonable discussion of it in a chapter dedicated to testing and debugging.

I hope that helps. Feel free to email me directly if anything is unclear.

Cheers,

Arran

ANONYMOUS wrote:

Using a simple if statement instead of assert() would be better then.

Hi all,

Just to check, can we have 2 .c files plus a header, or is it necessary to only use 1 .c file plus a header?

Hi,

It's entirely up to you how you organize your code. What you need to submit is definitions for the 5 required functions (and any helper functions you might define). Anything extra you submit will be ignored, unless it hinders readability or causes compilation failures.

Cheers,

Arran

ANONYMOUS wrote:

Hi all,

Just to check, can we have 2 .c files plus a header, or is it necessary to only use 1 .c file plus a header?