Draft

Your first decryptor

52 of 62reunion
Description
Loading description...
Fundamentals
Algorithms
Logic
Cryptography
View
AllIssues10QuestionsSuggestions4Show Resolved
  • Please sign in or sign up to leave a comment.
  • akar-0 Avatar

    (C++) Expected: equal to "Error!" Actual: "". The description does not say a word about that.

  • donaldsebleung Avatar

    [C] Following my issue report, I would like to suggest the following modification to the function signature:

    void decrypt(char const *msg, char *buf);

    Here, the input parameter msg is labelled const preventing in-place modification. The second parameter buf is an output parameter which the callee can assume is large enough to fit the result. The caller then ignores the return value of decrypt() and checks buf for the computed result.

    This setup has the following advantages:

    • The input is not modified (good programming practice)
    • The callee does not have to worry about memory allocation
    • The caller can allocate buf using any method (static, dynamic, etc.) deemed appropriate and pass that buf to the callee

    Final 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 Avatar

    [C, but probably applies to NASM and maybe C++ as well] As @rowcased mentioned:

    C memory allocation specifications should be explicitly stated.

    From the function signature char *decrypt(char *) alone, it is unclear to the solver whether:

    • A static buffer should be used within the function and returned on every call to decrypt()?
    • A malloc()ed string should be returned (who will free it)?
    • The input parameter itself should be modified in-place (bad practice, as we can't invoke the function with a string constant)?

    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.

  • FArekkusu Avatar

    String translation is a duplicate.

  • dfhwze Avatar

    C: you allow input mutation. In fact, the reference solution does so.

  • dfhwze Avatar

    "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.

  • FArekkusu Avatar

    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.

  • FArekkusu Avatar

    Trivial map/filter/reduce is not a novel kata idea.

  • rowcased Avatar

    C memory allocation specifications should be explicitly stated.

  • rowcased Avatar

    The C fixture code produces warnings.

  • mauro-1 Avatar

    Tests should include empty messages.

  • mauro-1 Avatar

    C++: User can bypass random tests modifying input.
    Expected value should be computed first.

  • monadius Avatar

    NASM: please add #define _POSIX_C_SOURCE 200809L at the top of test code. Without this line the following warning appears:

    fixture.c: In function 'assert_set':
fixture.c:25:17: warning: implicit declaration of function 'strdup' [-Wimplicit-function-declaration]
     char *msg = strdup(s->msg);
  • rowcased Avatar

    Hi PUTIS aka Zverb, (correct me if I'm wrong), but it seems your code produces this warning:

    main.cpp:20:23: warning: comparison of integers of different signs: 'int' and 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::size_type' (aka 'unsigned long') [-Wsign-compare]
    for (int i = 0; i < message.size(); i++) {
                    ~ ^ ~~~~~~~~~~~~~~
1 warning generated.

    So, I would recommend that you eradicate that from your code. Cheers. :)