pcb-rnd knowledge pool
Removing the global PCB variable
global_pcb by Tibor 'Igor2' Palinkas on 2017-03-16 | Tags: dev, global, variable, pcb, board, tabs |
Abstract: Background of the global PCB variable removal, policy/recommendation how to proceed.
Imported from the mailing list archives.
The original PCB code we inherited uses a global variable called PCB to hold the current board. It also has some other random global variables for local features. This is generally okay, we edit one board at a time.
However, there are a lot of ugly workarounds in some of the code because of this. The common pattern is:
1. some code once written for manipulating the One Central PCB we have
2. later someone figured we need to temporarily work on another PCB struct
3. this resulted in workarounds that try to save the global states (the PCB variable and potentially other global variables), create a new global state, run the code in question and finally restore the old state.
This is too easy to break. It's too easy to forget to save and restore, especially if a function we call calls another which then calls another and the side effect of changing a global state happens a few calls deep.
The solution is rather simple:
- library call should not depend on global states, but should get all states as arguments; this probably includes everything from I/O through polygons to utility functions like the layer code
- the generic, main code, and UI code could still use the global vars, as we run only one instance and we don't ever need to temporary swap things there
- if there are other board specific global variables, like the ones in rats.c, we should consider moving them in the PCB struct.
Policy: new functions should not use PCB directly but get a pcb_board_t * passed as first argument.