I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

Talk:Data Encryption Standard

From Rosetta Code

REXX decryption[edit]

Has anyone an idea how to implement this:
"Decryption is simply the inverse of encryption, follwing the same steps as above, but reversing the order in which the subkeys are applied."
Reverting the subkeys did not work --Walter Pachl 05:37, 22 July 2017 (UTC)

It works. Above failure was due to an error in my test. --Walter Pachl 11:05, 23 July 2017 (UTC)

malloc() return value not checked in C version[edit]

I built the C version for an embedded processor. When I ran it there, the decrypted values didn't match the encrypted ones. Also, the third encryption/decryption didn't produce all the expected output.

The culprit is that the code as it stands at this writing doesn't check for malloc() returning zero, and this is exactly what was happening. So instead, some of the lowest addresses in data memory got corrupted.

(In this development toolchain, unless the programmer explicitly specifies a value for the heap size, only a tiny heap actually gets allocated.)

As it happens, on this processor that memory range is mapped to the processor registers. So variables in those registers were getting clobbered.

Had I read the source more carefully before building, I would have seen this flaw and might have recognized more quickly what was wrong.

In my copy I've made a simple fix using a small wrapper around malloc() that uses assert() to abort the program if malloc returns 0.

Should I go ahead and make this change to the code here on rosettacode.org? Or can anyone suggest something better?

Welcome to the community. I guess just go ahead if it is a bug fix and since C is a popular language you are more likely to get feedback. Good luck and have fun.--Hkdtam (talk) 18:23, 21 April 2020 (UTC)