unsigned int vs long in RHEL libconfig. #55
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
KittenSquad/glewlwyd#55
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Not sure if it's just RHEL 6, but I had issues with all the unsigned int in the config struct, the config_lookup_int libarary has long as param 3 - so it was trashing 4 bytes of the next config option in the master config structure each time it got a value. Fixed by changing all appropriate unsigned ints to longs in the .h. (refresh_token_expiration was being trashed by a later grab of session_expiration, since it sits just above it in the .h struct). Code didn't crash but it appeared as a bug where refresh_token_expiration was always seemingly zero despite config being set. Walking through the code highlighted it was being set to 0 by:
config_lookup_int(&cfg, "session_expiration", &config->session_expiration);
Long params as per libconfig.h
extern LIBCONFIG_API int config_lookup_int(const config_t *config,
const char *path, long *value);
sizeof unsigned int: 4
sizeof long: 8.
Glewlwyd is built with libconfig 1.4, where, according to the documentation expects an int in the function
config_lookup_int: https://www.hyperrealm.com/libconfig/libconfig_manual.html#The-C-APISo I prefer to stay in the current API in that case.
Maybe you should install a more recent version of libconfig?
You're absolutely right - apologies, the perils of legacy environments. Could it be plausible to add a Make / compiler warning to suit if libconfig < 1.4? Given that the effects are so subtle and may well go unnoticed for some.
I will add a check in the
CMakelists.txtfile and add a warning in the documentation, thanks for the report.@xava-charlesj , this should be fixed in the branch 1.4 now, thanks
Great, thank you - appreciate that it's a little trivial.
FYI, am currently running 1.4.10 alongside libconfig 1.7.2 and all is well so far.
Awesome, I'm closing the issue then