Draft
Your first decryptor
52 of 62reunion
Loading description...
Fundamentals
Algorithms
Logic
Cryptography
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
(C++) Expected: equal to "Error!" Actual: "". The description does not say a word about that.
Thanks, fixed
.
[C] Following my issue report, I would like to suggest the following modification to the function signature:
Here, the input parameter
msg
is labelledconst
preventing in-place modification. The second parameterbuf
is an output parameter which the callee can assume is large enough to fit the result. The caller then ignores the return value ofdecrypt()
and checksbuf
for the computed result.This setup has the following advantages:
buf
using any method (static, dynamic, etc.) deemed appropriate and pass thatbuf
to the calleeFinal note: do not worry about invalidating existing solutions, and apply this change to NASM (and C++, if you are using
char *
) as well if you decide to implement this suggestion.@donaldsebleung I do appreciate your suggestion and well-known of good programming practices. But as i did mention before i had just mistakenly placed the comment in another solution.
So it is fair to vote for your suggestion to be implemented! Vote for
a
to allocate the buffer Vote form
to modify the input string itselfa
0 : 0m
char*
and returningbuf
goes in line with other standard functions likestrcpy
orstrcat
. So I think that havingchar* decrypt(char const *msg, char *buf);
would be OK too.const
specifier (and especially lack of it) is not enough of a hint because very often it still can be interpreted in more than one way. Additionally, after experiences with other C kata and their abysmal memory management techniques, I can imagine users get really lost and confused what are possible techniques, which of them are good, and which are not. Just document every pointer coming into and out of the function. It won't hurt anyone.@hobovsky If the suggestion is voted up it will be
100%
:but this declaration has more sense according to the C-Standard library functions:
and the last one does not cause ambiguity what
newmsg
is to be done for!and such an example is
strdup
is not standard, for exactly this reason.For nitpickers: yes, I know.
@hobovsky you should have said: Fot nitpickers: yes, I do know.
It's woderfull which standard you are following... LoL
strdup
Well, it's you who mentioned "C-Standard library functions" and
strdup
is not a part of any C standard up to and including current C17. It's not a part of ANSI C, it's not a part of C99, it's not a part of C11. It's a part od POSIX indeed, but POSIX is not the "C-Standard". It's true thatstrdup
made into C2x, but C2x is not a current standard yet. You need to wait a bit until your example becomes valid, and even when it becomes valid, it will be a bad example. It will be rather an exception than a rule that string manipulation routines perform allocations internally. There's a bunch of string functions which accept a pointer to an output buffer, and functions with internal allocations are more than scarce, especially in the C Standard. How many funcions from the standard C library which return a pointer to an internally allocated buffer can you name? How many functions accept a pointer to an output buffer? Your example ofstrdup
is totally not representative, and it seems as specifically picked only to make a suboptimal approach look good.You and me have different opinions about the Standards, i see... My point is not about whether
strdup
is from the standard or not but about the function declaration style! Maybestrdup
was really bad choice to demonstrate but the idea should have been clear and by the way this not me who nitpicked me about the C-Standard library functions.Definitely
getenv
is ANSI C.[C, but probably applies to NASM and maybe C++ as well] As @rowcased mentioned:
From the function signature
char *decrypt(char *)
alone, it is unclear to the solver whether:static
buffer should be used within the function and returned on every call todecrypt()
?malloc()
ed string should be returned (who will free it)?Please do not close this Issue until it has actually been addressed adequately, by mentioning the expectation(s) clearly in the description. Repeated violations of this rule may result in temporary or permanent revocation of your Kata authoring privileges.
Did
fix
earlier but mischanged Complete Solution with Initial Solution But now did place the comment in the right place!String translation is a duplicate.
C: you allow input mutation. In fact, the reference solution does so.
The word "allow" is not appropriate here because the input should be manipulated instead! And that is why you do not see the
const
in the function declaration!"You are given an encrypted string that contains the symbols:" -> nope, somehow, you also test an undocumented edge case scenario, the infamous "empty string". This is a useless addition to the kata. I would remove it.
I wouldn't call the base case an edge case. Why would an empty string not be valid?
( Assuming you're actually talking about
""
, not some abomination likenull
. )checking for an empty
""
string is to test CodeWarrior's ability to handle contingencies.I believe that in many kata, the empty string test was added to train CodeWarrior
to anticipate exceptions and handle them appropriately.
This skill will come in handy later when working with large projects.
Hope you are satisfied with this answer.
Trivial map/filter/reduce is not a novel kata idea.Actually, this is a simple string translation, so it's an exact duplicate to many katas.I think you did not understand the essence of the kata.
I think you don't understand how CW works. Nobody cares about any highly philosophical/educational ideas which you have in mind while creating a kata - all we see is a task, and one that has been posted many time here. Stop closing issues, you're neither fixing anything, nor helping anyone by doing so.
Thanks, I didn't know that. I will consider when creating the next kata if I will make them.
Trivial map/filter/reduce is not a novel kata idea.
The main purpose of this kata is to teach the CodeWarrior how to work with an ASCII table,
Give him an idea of the location of the symbols in this table. It is not about simple drawing up a map, as it might seem at first sight.
Hope I solved your issue.
There are atleast hundred of katas dealing with ASCII codes.
I didn't get that.
Map is an associative container in C ++ based on a key-value pair.
"Drawing up" == "creating", I apologize if I am not clear in explanations.
Yes, in this kata you need to work with an ASCII table, but I tried to create it as unique as possible among similar ones.
Of course, the most obvious way is creating map with the input values and character from the ASCII table,
but this is not the solution intended in this kata.
I hope I answered your question.
Read this.
Well, Read this then.
Is this in any way enforced ( and specified ) ? If not, it's just not an argument.
Why are you aiming for implementation details in the first place? Kata are better suited to tasks defined by the result of a transformation, rather than the mechanics of it. A solution is tested as a black box ( mostly ).
Thank you, I will take this into account in the next kata if I create them.
This was my first experience and I will try to correct the errors in the following.
C memory allocation specifications should be explicitly stated.
Fixed
But should not... because there is noconst
word in the declaration! What is forconst
? Just for fun? ))No, you did not fix the issue. The solver still does not know whether to return a static buffer, a dynamically allocated string or modify
msg
in-place.Fixed
but as did explain above in the wrong setup... So there was no need to downvote me for that anyway!The C fixture code produces warnings.
Thanks! The old version with new stupid flags...
Fixed
Tests should include empty messages.
Hello!
Thanks for the suggestion.
Empty message test added.
The suggestion was "add tests for empty strings", not "change rules for empty strings".
C++: User can bypass random tests modifying input.
Expected value should be computed first.
As I understand it, the input data must be constant?
Can't figure out how User can bypass random tests
This comment has been hidden.
Thanks, fixed!
I appreciate your contribution.
NASM: please add
#define _POSIX_C_SOURCE 200809L
at the top of test code. Without this line the following warning appears:Done
but it does not help! So suggest to leave as it is...#define _POSIX_C_SOURCE 200809L
should be before#include <string.h>
. And also don't forget about Sample Test Cases.Fixed
Hi PUTIS aka Zverb, (correct me if I'm wrong), but it seems your code produces this warning:
So, I would recommend that you eradicate that from your code. Cheers. :)