125. Board-Independent Status Indicator

The firmware must provide a system status indicator used by application logic to reflect runtime state.

The same application firmware must run on different hardware boards with incompatible GPIO wiring and control logic.

The target hardware board must be selected at build time and must never be chosen at runtime.

It must be impossible to build firmware that targets more than one hardware board at the same time.

The current codebase does not enforce this separation and cannot support multiple boards correctly.

Your task is to redesign the code so hardware differences are isolated behind a proper abstraction.

Program Flow:

1. The program reads an integer N, representing the number of system events.
2. The program reads N event values sequentially.
3. An event value of 1 requests the status indicator to toggle.
4. An event value of 0 requests no change.
5. After each event, the current status indicator state is printed.

Input Format:
Input is provided via standard input (stdin).

• First value:
  • N (integer)
  • Range: 1 ≤ N ≤ 20
• Next N values:
  • Integer event codes (0 or 1)
  • Values may be separated by spaces or newlines

Output Format:
Print exactly N lines.

Each line must be exactly:

STATUS=ON 

or

STATUS=OFF 

Rules:

• Initial status indicator state is OFF
• Output order must match input order
• No extra spaces or text

Example:

Example 1
Input:

5
1 1 0 1 1

Output:

STATUS=ON
STATUS=OFF
STATUS=OFF
STATUS=ON
STATUS=OFF

Constraints:

• Exactly one hardware board must be selected at build time
• Runtime board selection is forbidden
• Application code must not access GPIO registers or hardware-specific APIs
• Invalid build configurations must fail compilation
• main() must not be modified
• No dynamic memory allocation
• No STL containers
• Deterministic behavior required

Validation Requirement:
To validate portability:

• Build and run the program with BOARD_TYPE_B selected
• Then comment BOARD_TYPE_B, uncomment BOARD_TYPE_A, and rebuild
• The program must compile and run correctly in both cases without changing application logic