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

False triggering of recursive inclusion protection in list lib #4

Open
dimmykar opened this issue Nov 1, 2022 · 2 comments
Open

False triggering of recursive inclusion protection in list lib #4

dimmykar opened this issue Nov 1, 2022 · 2 comments

Comments

@dimmykar
Copy link

dimmykar commented Nov 1, 2022

Hi! I liked your implementation of linked list without dynamic allocation, and I decided to try it in a fairly large STM32-based embedded project.

It was unexpected, when compiling, an error appeared when declaring a my list element that included a struct list_element structure:

typedef struct
{
    struct can_device *can_device;
    struct list_element elem;
} ONLINE_LIST_ELEMENT;

The error was pointing to struct list_element elem; and said the following:

"field elem has incomplete type"

In the implementation of struct list_element, everything was OK and I could not understand what the problem was. Finally, I saw a relatively simple defense against recursively including the list.h header:

#ifndef LIST_H
#define LIST_H

...

#endif // LIST_H

Replacing this construct with #pragma once, the compilation was finished successfully.

I don't even know where exactly I still have the LIST_H header included, but LIST_H is a very simple and common label.

It would be nice to replace it with something else, or use #pragma once (but this may not be available for some compilers, most likely outdated)

@clnhlzmn
Copy link
Owner

clnhlzmn commented Nov 1, 2022

This is a good point and LIST_H could definitely be replaced with something more unique. I don't want to use #pragma once because it is not standard.

@dimmykar
Copy link
Author

dimmykar commented Nov 1, 2022

In accordance with the name of the repository, you can use the UTILS_LIST_H option (and pattern UTILS_MODULE_H for all libraries of this repo), this option will already be more unique

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

No branches or pull requests

2 participants