Skip to content

Improve diagnostics when no parser modules are loaded #51

@igrr

Description

@igrr

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:

libnmea/src/nmea/nmea.c

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions