Some considerations on this code:
Strange a structure that saves data from a property calling imoveis . And a list of properties call imovel . It worsens when the type of this structure is called INFO .
float is not suitable for monetary values. But that's fine for an exercise, as long as you understand that you should not use it in production, because in production it's unlikely to use char to strings . I would probably even use it in ano , if it is only descriptive, as seems to be the case. It would only make sense to be int if you are going to be accountable to him. I can not tell if other types are suitable because they do not know the requirements.
As for activity status you can use a simple char to save this information. There you could save S or N, or 0 or 1 as a character or ASCII code. I could use int too, but it does not seem to be the best option. Depending on the compiler you could use a bool , or you can simulate it: Simulate the Boolean type in C .
typedef struct {
int tipo, cod;
int ano;
char cidade[100], morada[100], animais[20], obs[100];
float preco_min, preco_acons;
char ativo;
} Imovel;
typedef struct {
Imovel info;
struct imovel *seguinte;
struct imovel *anterior;
} Imoveis;
When initializing, you need to adopt a semantic pattern for this field. Something like this:
imovel.ativo = 1;
or
imovel.ativo = '1';
or
imovel.ativo = 'S';
This holds true for any field that has a limited set of previously known options. If it is 2, 3, in thesis up to 256 (you can use a enum if the compiler allows, in some cases it is 2 but it is not something boolean, it is not a matter of just being a yes or not, in the case of a status , even if it starts with 2 it might have something intermediate going forward, so it can be useful. If you need to go through 256 options you can still use short or int , although when there is a lot of option it is not always interesting to have an enumeration simulation like this.
