Consider implementing a check on msg.data.length

[GriffGreen]

There was an attack vector that an address that ends in 0 or 00 or 000 etc could use their address and omit the final 0's and then mess with the data length.

I love how the Token Card guys dealt with it.

https://github.com/MonolithDAO/token/blob/master/src/Token.sol#L23

    modifier onlyPayloadSize(uint numwords) {
        assert(msg.data.length == numwords * 32 + 4);
        _;

I might suggest we consider changing the verbiage, but the intent and application is great, in every function that a user has to input msg.data that includes and address, this modifier is used... this means transfer(), transferFrom(), approve() and also decreaseApproval() and increaseApproval() if we use it. (see my other issue ;-))

My suggested verbiage:

    modifier onlyValidDataLengths(uint numOfParams) {
        assert(msg.data.length == numOfParams * 32 + 4);
        _;

[jbaylina]

PR #15 implements it.

But I'm not convinced on this, because this functions might be called internally from a derived contract and what's checking are not the parameters but the data field.

[koeppelmann]

please be careful doing this. There is some low level solidity padding happening that might cause the payload to be bigger than expected. So while a check against a too small payload should be fine a check for "equal" is dangerous.
It might lead to a situation that those tokens could get stuck in e.g. a multisig wallet.

Read more here: https://blog.coinfabrik.com/smart-contract-short-address-attack-mitigation-failure/
or here:
http://vessenes.com/notice-about-fun-token-support-for-multisignature-wallets-2/

[acedev0816]

assert(msg.data.length == numwords * 32 + 4);
why +4?