unsigned int vs long in RHEL libconfig. #55

Closed
opened 2019-03-19 13:00:33 +01:00 by xava-charlesj · 6 comments
xava-charlesj commented 2019-03-19 13:00:33 +01:00 (Migrated from github.com)

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.

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.
babelouest commented 2019-03-19 15:29:24 +01:00 (Migrated from github.com)

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-API

So I prefer to stay in the current API in that case.

Maybe you should install a more recent version of libconfig?

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-API So I prefer to stay in the current API in that case. Maybe you should install a more recent version of libconfig?
xava-charlesj commented 2019-03-19 22:00:58 +01:00 (Migrated from github.com)

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.

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.
babelouest commented 2019-03-20 00:18:39 +01:00 (Migrated from github.com)

I will add a check in the CMakelists.txt file and add a warning in the documentation, thanks for the report.

I will add a check in the `CMakelists.txt` file and add a warning in the documentation, thanks for the report.
babelouest commented 2019-03-20 01:37:19 +01:00 (Migrated from github.com)

@xava-charlesj , this should be fixed in the branch 1.4 now, thanks

@xava-charlesj , this should be fixed in the branch 1.4 now, thanks
xava-charlesj commented 2019-03-20 01:39:08 +01:00 (Migrated from github.com)

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.

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.
babelouest commented 2019-03-20 01:46:32 +01:00 (Migrated from github.com)

Awesome, I'm closing the issue then

Awesome, I'm closing the issue then
This discussion has been locked. Commenting is limited to contributors.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
KittenSquad/glewlwyd#55
No description provided.