# 3.4 Constructor

## Constructor Names

Constructor names in `Solidity` have had security implications historically. If you go back all the way to `Solidity` compiler version `0.4.22`, the versions prior to that one required the use of the contract name as the name of the constructor. And between that version and `0.5.0` one could either use the contract name as a constructor or use the `constructor` keyword itself. It was only after `0.5.0` that `Solidity` forced the use of the `constructor` keyword for constructors.

So this flexibility, the use of the contract name as the constructor name, has historically caused bugs, where the contact name was misspelled which led to that function not being the constructor, but a regular function.

Also the flexibility between allowing both the old style and the new style constructor names caused security issues, because there was a precedence that was followed, if both of them existed. So this constructor naming confusion has been a historical source of bugs and `Solidity` smart contracts, although **it is not a concern anymore**.

## Void Constructor

There's a security concern related to "*void constructors*". What this means is that if a contract derives from other contracts, then it makes calls to the constructors of base contracts assuming they're implemented, but if in fact they are not, then this assumption leads to security implications.

So the best practice for derived contracts is to check if the base constructor is actually implemented and remove the call to that constructor, if it is not implemented at all.

## Constructor Call Value

This security pitfall is related to the checks for any value sent in contact creation transactions triggering the constructor.

Typically, if a constructor is not explicitly payable and there is an Ether value that is sent in a contract creation transaction that triggers such a constructor, then the constructor reverts that transaction.

However, because of a compiler bug, if contract did not have an explicit constructor but had a base contract that did define a constructor, then in those cases, it was possible to send Ether value in a contract creation transaction, that would not cause that revert to happen. This compiler bug was present all the way from version `0.4.5` to version `0.6.8`, and thus **is not an issue anymore**.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://secureum.gitbook.io/secureum-book/learn/learn/3_security_pitfalls_and_best_practices/3.4_constructor.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.