building against OpENer as external library fails due to missing definitions
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- c, cmake
- Domain
- build-system, embedded-iot, networking
Research direction
Start with enipmessage.h and trace how PC_OPENER_ETHERNET_BUFFER_SIZE is supplied by the CMake files through add_definition() and OPENER_ETHERNET_BUFFER_SIZE. Check the installed public headers and libUtils usage when OpENer is consumed as an external library. Done means an external application can obtain the stack's buffer-size definition without guessing.
Written by the indexing model from the issue text.
Description
The declaration of type ENIPMessage in file enipmessage.h contains PC_OPENER_ETHERNET_BUFFER_SIZE as buffer size for the message buffer inside of that struct:
typedef struct enip_message {
CipOctet message_buffer[PC_OPENER_ETHERNET_BUFFER_SIZE];
CipOctet *current_message_position;
size_t used_message_length;
} ENIPMessage;
It is part of libUtils and used by other parts of the stack. The file enipmessage.h is included by other headers and installed, so can be considered part of the public API of the stack. The value PC_OPENER_ETHERNET_BUFFER_SIZE however is not only referenced in that header but used in various places of the stack's code. It is passed as preprocessor option at build time of the stack and comes from the CMake files through an add_definition() statement which takes the CMake option OPENER_ETHERNET_BUFFER_SIZE as input.
This leads to the following situation: there is this build time option (OPENER_ETHERNET_BUFFER_SIZE) which results in hardcoded array sizes of the built stack. When later building against the stack as external library the same value is required as preprocessor definition but it's defined nowhere and you don't get it from public API headers. So it is essentially impossible to know its value at build time of an app. You need to guess.
An app using a different value for PC_OPENER_ETHERNET_BUFFER_SIZE as the stack used will probably crash?!
- Dominant language
- C
- Stars
- 858
- Forks
- 314
- Avg merge
- 18d 2h
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from EIPStackGroup/OpENer
-
Memory leak in TCP/IP Interface Object attribute 5 and 6 setters on the validation-failure path Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
EIPStackGroup/OpENer#605 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
EIPStackGroup/OpENer#606 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
EIPStackGroup/OpENer#593 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
EIPStackGroup/OpENer#592 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
EIPStackGroup/OpENer#582 ·
All issues in EIPStackGroup/OpENer
Similar issues
-
level/task module/gcp type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
hapostgres/pg_auto_failover#1190 ·
-
docs
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
P3 sonic-vpp
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sonic-net/sonic-buildimage#29662 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 94/100
spack/spack-packages#6586 ·