fallback function, best practices when registering information

Question

I'm currently working on a smart-contract, and I have this warning in Remix :

Fallback function of contract browser/token.sol requires too much gas 
(102480).
If the fallback function requires more than 2300 gas, the contract 
cannot receive Ether.

I understand that, when executing the fallback method, I'm in a context of limited available gas. But for a token creation, for instance, I need to write multiple variables to have an accurate accounting of my token distribution.

function() payable {
  require(block.number > icoStartBlock && block.number < icoEndBlock);

  uint256 tokenAmount = msg.value * ((block.number < icoPremiumEndBlock) ? 550 : 500);

  shares[msg.sender] += msg.value;
  balances[msg.sender] += tokenAmount;
  balances[owner] += tokenAmount / 6;

  raised += msg.value;
  created += tokenAmount;
}

If the user that send Ether to my smart-contract know there is a need for more gas, will it be working if he sends more ? Am I doing an anti-pattern ? The the contract cannot receive Ether part of the message on Remix is scaring me a bit.

Answer 1

The warning the contract cannot receive Ether is in the context of another contract sending your contract ether.

Your contract, let's call it C cannot receive ether from another contract D that uses Solidity's send function.

One way to avoid the warnings is to give the function in C a name, like buy:

function buy() payable { ... }

D can then send ether using instanceOfC.buy.value(etherAmountInWei)().

Here is an example of C getting paid by D:

contract C {
    function getBalance() constant returns(uint) {
        return this.balance;
    }

    function buy() payable public {
        // logic
    }

}

contract D {
    // allows D to be funded with some ether during its creation
    function D() payable {
    }

    function getBalance() constant returns(uint) {
        return this.balance;
    }

    function sendToC(address c) public {
        C(c).buy.value(12)();
    }
}

For non-contracts that want to send ether to C, they now have to call buy instead of "just sending ether" (via the fallback function). A user already has to increase their transaction's gas limit from 21,000 and they would now also have to pass the Method ID of buy.

For other guidance see When does the fallback function get called? including

Since fallback functions can be misused or abused, Vitalik Buterin suggested "establishing as a convention that fallback functions should generally not be used except in very specific cases."