Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spi/pwm: fix "uninitialized" warnings #51

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Livius90
Copy link

@Livius90 Livius90 commented Jan 4, 2024

Fix "uninitialized" warnings which can produced in case of use GCC v12.3.0 with -Wall -Wextra arguments.

@vsergeev
Copy link
Owner

@Livius90 thanks for the PR. My only concerns are that we shouldn't add *_INVALID states to the end of the enums. What if we legitimately needed to add a new enum member? Generally speaking, we shouldn't change an external API to fix internal warnings.

@Livius90
Copy link
Author

Livius90 commented Jan 13, 2024

@Livius90 thanks for the PR. My only concerns are that we shouldn't add *_INVALID states to the end of the enums. What if we legitimately needed to add a new enum member? Generally speaking, we shouldn't change an external API to fix internal warnings.

It is practical to provide an initialize value for an enum type variable.

https://github.com/vsergeev/c-periphery/pull/51/files#diff-324566633fa8f84c13e8a0e4d2eae73cdf43a89a9db1d75a14cc0bd7b672827bR416

pwm_polarity_t polarity = PWM_POLARITY_INVALID;

What do you prefer to use for initialize an enum variable? If just zero would use, it means it will be initialized for the first enum value. In a more complex code it can cause any issue.

pwm_polarity_t polarity = 0;    /* PWM_POLARITY_NORMAL */

@vsergeev
Copy link
Owner

It's not practical to put the invalid state after a bunch of valid ones. That's not only confusing, but also breaks the enum for any future additions. I agree with your latter suggestion -- that we might as well just explicitly initialize to 0 (whichever state it corresponds to).

@Livius90
Copy link
Author

Livius90 commented Jan 13, 2024

Do you mean the *_INVALID type should be the first like this?

typedef enum pwm_polarity {
    PWM_POLARITY_INVALID,
    PWM_POLARITY_NORMAL,    /* Normal polarity */
    PWM_POLARITY_INVERSED,  /* Inversed polarity */
} pwm_polarity_t;

What do you prefer now, i can change to use *_INVALID enum types from first position in enum list, or I can just initializing bit_order and polarity to zero without change enums in headers?

pwm_polarity_t polarity = 0;    /* PWM_POLARITY_NORMAL */
...
spi_bit_order_t bit_order = 0;    /* MSB_FIRST */

@vsergeev
Copy link
Owner

vsergeev commented Jan 14, 2024

Do you mean the *_INVALID type should be the first like this?

typedef enum pwm_polarity {
    PWM_POLARITY_INVALID,
    PWM_POLARITY_NORMAL,    /* Normal polarity */
    PWM_POLARITY_INVERSED,  /* Inversed polarity */
} pwm_polarity_t;

Yup, exactly. This would have been ideal, but at this point I don't think it's a good idea to break the API.

What do you prefer now, i can change to use *_INVALID enum types from first position in enum list, or I can just initializing bit_order and polarity to zero without change enums in headers?

pwm_polarity_t polarity = 0;    /* PWM_POLARITY_NORMAL */
...
spi_bit_order_t bit_order = 0;    /* MSB_FIRST */

Yeah, this is a good compromise for now. I don't think the comment is actually needed, and it might even be a bit confusing, because the intention is just to give the variable an initialized value rather than set it to the state described in the comment.

@Livius90
Copy link
Author

@vsergeev
Done

@Livius90
Copy link
Author

Livius90 commented Aug 23, 2024

@vsergeev
When is it going to be merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants