-
Notifications
You must be signed in to change notification settings - Fork 110
Description
I've ran into this more than a few times already during development, that when NMEA_PARSER_PATH is not set correctly, no modules are loaded. In this situation, parsing of any NMEA message silently fails.
This is perfectly legal, but sets one on a somewhat lengthy troubleshooting path: why didn't the message get parsed? why didn't the message type get detected? why no parsers loaded? ah, because shared libraries haven't been found!.
What doesn't help is that the parser loading happens from a constructor function, where it isn't possible to do anything about the return value of nmea_load_parsers:
Lines 81 to 85 in d55d296
| void __attribute__ ((constructor)) nmea_init(void); | |
| void nmea_init() | |
| { | |
| nmea_load_parsers(); | |
| } |
In my opinion, the best solution would be to deprecate the automatic loading of parsers, and let the application call nmea_init and nmea_cleanup explicitly, as it is common for C libraries. Then an error code could be returned to the application from nmea_init, indicating for example that no parsers were loaded. This would be a breaking change for existing projects, though. Given that libnmea is pre-1.0, this might still be acceptable, assuming that semver is followed?
The next best solution seems to be to add a function nmea_get_parser_count or similar, which would return the number of parsers loaded. The application can then check if the value is zero and bail out with a human-readable error message if it is.
I can submit a PR for either of the solutions, but would like to get @jacketizer's advice and approval first.