non-direct typecasting structs from const to non-const via ifdefs in header file
I want to make struct members accessible for all, but writable only for specially marked code.
Using something like this in header file:
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
and placing EXTCONST everywhere in struct typedefs like this:
typedef struct {
int a;
} EXTCONST typename;
Corresponding .c file have #define ALLOW_WRITE at beginning, other files have not.
I'm nearly sure that this will work as expected, at least without agressive optimizations turned on.
Two questions:
1) will this work properly with maximum optimizations enabled?
2) is this way correct according to C standards?
NOTE: i know that this can be done via getter functions, but i think that st->a->b looks far better and more intuitive than a_get_b(st_get_a(st))
SUMMARY:
At least two people says that such hidden typecasting is not safe and no one says it is ok.
So i will use "improved" way to do read-noly access check.
#ifdef CONST_CHECK
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
#else
#define EXTCONST
#endif
And run the compiler two times for source files in question: one with -DCONST_CHECK to emit all warnings about unauthorized write access, and the second without this flag to produce compiled object file without any possible harmful side affects from compiler optimizations.
c struct casting const
asked Jan 3 at 17:19
firkfirk
146
|
show 1 more comment
I want to make struct members accessible for all, but writable only for specially marked code.
Using something like this in header file:
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
and placing EXTCONST everywhere in struct typedefs like this:
typedef struct {
int a;
} EXTCONST typename;
Corresponding .c file have #define ALLOW_WRITE at beginning, other files have not.
I'm nearly sure that this will work as expected, at least without agressive optimizations turned on.
Two questions:
1) will this work properly with maximum optimizations enabled?
2) is this way correct according to C standards?
NOTE: i know that this can be done via getter functions, but i think that st->a->b looks far better and more intuitive than a_get_b(st_get_a(st))
SUMMARY:
At least two people says that such hidden typecasting is not safe and no one says it is ok.
So i will use "improved" way to do read-noly access check.
#ifdef CONST_CHECK
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
#else
#define EXTCONST
#endif
And run the compiler two times for source files in question: one with -DCONST_CHECK to emit all warnings about unauthorized write access, and the second without this flag to produce compiled object file without any possible harmful side affects from compiler optimizations.
c struct casting const
asked Jan 3 at 17:19
firkfirk
146
What part do you think might be non-compliant? thestructdefinition or theifdefpart?
– Eugene Sh.
Jan 3 at 17:25
I fear the compiler may do some const-related optimizations while in fact the struct is not always const.
– firk
Jan 3 at 17:30
I don't think that it will provide the benefits you hope for. In fact, I think it is likely to make life uncomfortable. However, that's not a criticism of its technical feasibility; just on its practical usefulness.
– Jonathan Leffler
Jan 3 at 17:30
Then most of the text in the question is irrelevant. You are saying that you have two structures, but one isconstand one is not. And asking if these are compatible. No, they are not.
– Eugene Sh.
Jan 3 at 17:32
1
Then you should ask about the compatibility. The "const optimizations" (and other optimizations) will depend on the type compatibility among the other considerations. Binary representation is pretty much irrelevant when speaking of the language rules.
– Eugene Sh.
Jan 3 at 17:40
|
show 1 more comment
I want to make struct members accessible for all, but writable only for specially marked code.
Using something like this in header file:
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
and placing EXTCONST everywhere in struct typedefs like this:
typedef struct {
int a;
} EXTCONST typename;
Corresponding .c file have #define ALLOW_WRITE at beginning, other files have not.
I'm nearly sure that this will work as expected, at least without agressive optimizations turned on.
Two questions:
1) will this work properly with maximum optimizations enabled?
2) is this way correct according to C standards?
NOTE: i know that this can be done via getter functions, but i think that st->a->b looks far better and more intuitive than a_get_b(st_get_a(st))
SUMMARY:
At least two people says that such hidden typecasting is not safe and no one says it is ok.
So i will use "improved" way to do read-noly access check.
#ifdef CONST_CHECK
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
#else
#define EXTCONST
#endif
And run the compiler two times for source files in question: one with -DCONST_CHECK to emit all warnings about unauthorized write access, and the second without this flag to produce compiled object file without any possible harmful side affects from compiler optimizations.
c struct casting const
asked Jan 3 at 17:19
firkfirk
146
I want to make struct members accessible for all, but writable only for specially marked code.
Using something like this in header file:
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
and placing EXTCONST everywhere in struct typedefs like this:
typedef struct {
int a;
} EXTCONST typename;
Corresponding .c file have #define ALLOW_WRITE at beginning, other files have not.
I'm nearly sure that this will work as expected, at least without agressive optimizations turned on.
Two questions:
1) will this work properly with maximum optimizations enabled?
2) is this way correct according to C standards?
NOTE: i know that this can be done via getter functions, but i think that st->a->b looks far better and more intuitive than a_get_b(st_get_a(st))
SUMMARY:
At least two people says that such hidden typecasting is not safe and no one says it is ok.
So i will use "improved" way to do read-noly access check.
#ifdef CONST_CHECK
#ifdef ALLOW_WRITE
#define EXTCONST
#else
#define EXTCONST const
#endif
#else
#define EXTCONST
#endif
And run the compiler two times for source files in question: one with -DCONST_CHECK to emit all warnings about unauthorized write access, and the second without this flag to produce compiled object file without any possible harmful side affects from compiler optimizations.
c struct casting const
c struct casting const
asked Jan 3 at 17:19
firkfirk
146
asked Jan 3 at 17:19
firkfirk
146
edited Jan 3 at 18:22
firk
asked Jan 3 at 17:19
firkfirk
146
asked Jan 3 at 17:19
firkfirk
146
asked Jan 3 at 17:19
firkfirk
146
146
What part do you think might be non-compliant? thestructdefinition or theifdefpart?
– Eugene Sh.
Jan 3 at 17:25
I fear the compiler may do some const-related optimizations while in fact the struct is not always const.
– firk
Jan 3 at 17:30
I don't think that it will provide the benefits you hope for. In fact, I think it is likely to make life uncomfortable. However, that's not a criticism of its technical feasibility; just on its practical usefulness.
– Jonathan Leffler
Jan 3 at 17:30
Then most of the text in the question is irrelevant. You are saying that you have two structures, but one isconstand one is not. And asking if these are compatible. No, they are not.
– Eugene Sh.
Jan 3 at 17:32
1
Then you should ask about the compatibility. The "const optimizations" (and other optimizations) will depend on the type compatibility among the other considerations. Binary representation is pretty much irrelevant when speaking of the language rules.
– Eugene Sh.
Jan 3 at 17:40
|
show 1 more comment
What part do you think might be non-compliant? thestructdefinition or theifdefpart?
– Eugene Sh.
Jan 3 at 17:25
I fear the compiler may do some const-related optimizations while in fact the struct is not always const.
– firk
Jan 3 at 17:30
I don't think that it will provide the benefits you hope for. In fact, I think it is likely to make life uncomfortable. However, that's not a criticism of its technical feasibility; just on its practical usefulness.
– Jonathan Leffler
Jan 3 at 17:30
Then most of the text in the question is irrelevant. You are saying that you have two structures, but one isconstand one is not. And asking if these are compatible. No, they are not.
– Eugene Sh.
Jan 3 at 17:32
1
Then you should ask about the compatibility. The "const optimizations" (and other optimizations) will depend on the type compatibility among the other considerations. Binary representation is pretty much irrelevant when speaking of the language rules.
– Eugene Sh.
Jan 3 at 17:40
What part do you think might be non-compliant? the
struct definition or the ifdef part?– Eugene Sh.
Jan 3 at 17:25
What part do you think might be non-compliant? the
struct definition or the ifdef part?– Eugene Sh.
Jan 3 at 17:25
I fear the compiler may do some const-related optimizations while in fact the struct is not always const.
– firk
Jan 3 at 17:30
I fear the compiler may do some const-related optimizations while in fact the struct is not always const.
– firk
Jan 3 at 17:30
I don't think that it will provide the benefits you hope for. In fact, I think it is likely to make life uncomfortable. However, that's not a criticism of its technical feasibility; just on its practical usefulness.
– Jonathan Leffler
Jan 3 at 17:30
I don't think that it will provide the benefits you hope for. In fact, I think it is likely to make life uncomfortable. However, that's not a criticism of its technical feasibility; just on its practical usefulness.
– Jonathan Leffler
Jan 3 at 17:30
Then most of the text in the question is irrelevant. You are saying that you have two structures, but one is
const and one is not. And asking if these are compatible. No, they are not.– Eugene Sh.
Jan 3 at 17:32
Then most of the text in the question is irrelevant. You are saying that you have two structures, but one is
const and one is not. And asking if these are compatible. No, they are not.– Eugene Sh.
Jan 3 at 17:32
1
1
Then you should ask about the compatibility. The "const optimizations" (and other optimizations) will depend on the type compatibility among the other considerations. Binary representation is pretty much irrelevant when speaking of the language rules.
– Eugene Sh.
Jan 3 at 17:40
Then you should ask about the compatibility. The "const optimizations" (and other optimizations) will depend on the type compatibility among the other considerations. Binary representation is pretty much irrelevant when speaking of the language rules.
– Eugene Sh.
Jan 3 at 17:40
|
show 1 more comment
1 Answer
1
active
oldest
votes
This is a dangerous way to do, if you include a header using EXTCONST in a source defining ALLOW_WRITE and also in an other source without defining ALLOW_WRITE the two sources will not see the same definitions.
So for instance in a source the compiler can suppose something will not change because const, but because it calls something in the other source changing the value there is an inconsistency.
All the sources have to share the same definitions.
answered Jan 3 at 17:26
brunobruno
12.8k31426
Yes, the two definitions will differ: one with const keyword and one without it. It shouldn't be a problem from a point of its binary representation, but may be a problem if a compiler thinks the const one can't be altered after being passed to a function that uses it as non-const. The is what i am asking about.
– firk
Jan 3 at 17:28
Yes, so for me this is dangerous and must not be done. Furthermore this is also not easy for someone reading your code. Why do you want to do that ?
– bruno
Jan 3 at 17:31
"Why do you want to do that?" - Intuitive read-only access to struct members without syntax hell.
– firk
Jan 3 at 17:33
To add a const is not the hell, it is exactly the reverse, 1) you protect your code against errors (the compiler signal/reject when you try to modify something const) and 2) people looking at your code know something cannot be modified.
– bruno
Jan 3 at 17:36
Yes, and this is exactly what i want to do - protect "client" code from accidentally altering some data that it should'nt alter. And i am asking about side-effects from that from unexpected compiler optimizations.
– firk
Jan 3 at 17:42
|
show 5 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54026918%2fnon-direct-typecasting-structs-from-const-to-non-const-via-ifdefs-in-header-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is a dangerous way to do, if you include a header using EXTCONST in a source defining ALLOW_WRITE and also in an other source without defining ALLOW_WRITE the two sources will not see the same definitions.
So for instance in a source the compiler can suppose something will not change because const, but because it calls something in the other source changing the value there is an inconsistency.
All the sources have to share the same definitions.
answered Jan 3 at 17:26
brunobruno
12.8k31426
Yes, the two definitions will differ: one with const keyword and one without it. It shouldn't be a problem from a point of its binary representation, but may be a problem if a compiler thinks the const one can't be altered after being passed to a function that uses it as non-const. The is what i am asking about.
– firk
Jan 3 at 17:28
Yes, so for me this is dangerous and must not be done. Furthermore this is also not easy for someone reading your code. Why do you want to do that ?
– bruno
Jan 3 at 17:31
"Why do you want to do that?" - Intuitive read-only access to struct members without syntax hell.
– firk
Jan 3 at 17:33
To add a const is not the hell, it is exactly the reverse, 1) you protect your code against errors (the compiler signal/reject when you try to modify something const) and 2) people looking at your code know something cannot be modified.
– bruno
Jan 3 at 17:36
Yes, and this is exactly what i want to do - protect "client" code from accidentally altering some data that it should'nt alter. And i am asking about side-effects from that from unexpected compiler optimizations.
– firk
Jan 3 at 17:42
|
show 5 more comments
This is a dangerous way to do, if you include a header using EXTCONST in a source defining ALLOW_WRITE and also in an other source without defining ALLOW_WRITE the two sources will not see the same definitions.
So for instance in a source the compiler can suppose something will not change because const, but because it calls something in the other source changing the value there is an inconsistency.
All the sources have to share the same definitions.
answered Jan 3 at 17:26
brunobruno
12.8k31426
Yes, the two definitions will differ: one with const keyword and one without it. It shouldn't be a problem from a point of its binary representation, but may be a problem if a compiler thinks the const one can't be altered after being passed to a function that uses it as non-const. The is what i am asking about.
– firk
Jan 3 at 17:28
Yes, so for me this is dangerous and must not be done. Furthermore this is also not easy for someone reading your code. Why do you want to do that ?
– bruno
Jan 3 at 17:31
"Why do you want to do that?" - Intuitive read-only access to struct members without syntax hell.
– firk
Jan 3 at 17:33
To add a const is not the hell, it is exactly the reverse, 1) you protect your code against errors (the compiler signal/reject when you try to modify something const) and 2) people looking at your code know something cannot be modified.
– bruno
Jan 3 at 17:36
Yes, and this is exactly what i want to do - protect "client" code from accidentally altering some data that it should'nt alter. And i am asking about side-effects from that from unexpected compiler optimizations.
– firk
Jan 3 at 17:42
|
show 5 more comments
This is a dangerous way to do, if you include a header using EXTCONST in a source defining ALLOW_WRITE and also in an other source without defining ALLOW_WRITE the two sources will not see the same definitions.
So for instance in a source the compiler can suppose something will not change because const, but because it calls something in the other source changing the value there is an inconsistency.
All the sources have to share the same definitions.
answered Jan 3 at 17:26
brunobruno
12.8k31426
This is a dangerous way to do, if you include a header using EXTCONST in a source defining ALLOW_WRITE and also in an other source without defining ALLOW_WRITE the two sources will not see the same definitions.
So for instance in a source the compiler can suppose something will not change because const, but because it calls something in the other source changing the value there is an inconsistency.
All the sources have to share the same definitions.
answered Jan 3 at 17:26
brunobruno
12.8k31426
edited Jan 3 at 17:29
answered Jan 3 at 17:26
brunobruno
12.8k31426
answered Jan 3 at 17:26
brunobruno
12.8k31426
answered Jan 3 at 17:26
brunobruno
12.8k31426
12.8k31426
Yes, the two definitions will differ: one with const keyword and one without it. It shouldn't be a problem from a point of its binary representation, but may be a problem if a compiler thinks the const one can't be altered after being passed to a function that uses it as non-const. The is what i am asking about.
– firk
Jan 3 at 17:28
Yes, so for me this is dangerous and must not be done. Furthermore this is also not easy for someone reading your code. Why do you want to do that ?
– bruno
Jan 3 at 17:31
"Why do you want to do that?" - Intuitive read-only access to struct members without syntax hell.
– firk
Jan 3 at 17:33
To add a const is not the hell, it is exactly the reverse, 1) you protect your code against errors (the compiler signal/reject when you try to modify something const) and 2) people looking at your code know something cannot be modified.
– bruno
Jan 3 at 17:36
Yes, and this is exactly what i want to do - protect "client" code from accidentally altering some data that it should'nt alter. And i am asking about side-effects from that from unexpected compiler optimizations.
– firk
Jan 3 at 17:42
|
show 5 more comments
Yes, the two definitions will differ: one with const keyword and one without it. It shouldn't be a problem from a point of its binary representation, but may be a problem if a compiler thinks the const one can't be altered after being passed to a function that uses it as non-const. The is what i am asking about.
– firk
Jan 3 at 17:28
Yes, so for me this is dangerous and must not be done. Furthermore this is also not easy for someone reading your code. Why do you want to do that ?
– bruno
Jan 3 at 17:31
"Why do you want to do that?" - Intuitive read-only access to struct members without syntax hell.
– firk
Jan 3 at 17:33
To add a const is not the hell, it is exactly the reverse, 1) you protect your code against errors (the compiler signal/reject when you try to modify something const) and 2) people looking at your code know something cannot be modified.
– bruno
Jan 3 at 17:36
Yes, and this is exactly what i want to do - protect "client" code from accidentally altering some data that it should'nt alter. And i am asking about side-effects from that from unexpected compiler optimizations.
– firk
Jan 3 at 17:42
Yes, the two definitions will differ: one with const keyword and one without it. It shouldn't be a problem from a point of its binary representation, but may be a problem if a compiler thinks the const one can't be altered after being passed to a function that uses it as non-const. The is what i am asking about.
– firk
Jan 3 at 17:28
Yes, the two definitions will differ: one with const keyword and one without it. It shouldn't be a problem from a point of its binary representation, but may be a problem if a compiler thinks the const one can't be altered after being passed to a function that uses it as non-const. The is what i am asking about.
– firk
Jan 3 at 17:28
Yes, so for me this is dangerous and must not be done. Furthermore this is also not easy for someone reading your code. Why do you want to do that ?
– bruno
Jan 3 at 17:31
Yes, so for me this is dangerous and must not be done. Furthermore this is also not easy for someone reading your code. Why do you want to do that ?
– bruno
Jan 3 at 17:31
"Why do you want to do that?" - Intuitive read-only access to struct members without syntax hell.
– firk
Jan 3 at 17:33
"Why do you want to do that?" - Intuitive read-only access to struct members without syntax hell.
– firk
Jan 3 at 17:33
To add a const is not the hell, it is exactly the reverse, 1) you protect your code against errors (the compiler signal/reject when you try to modify something const) and 2) people looking at your code know something cannot be modified.
– bruno
Jan 3 at 17:36
To add a const is not the hell, it is exactly the reverse, 1) you protect your code against errors (the compiler signal/reject when you try to modify something const) and 2) people looking at your code know something cannot be modified.
– bruno
Jan 3 at 17:36
Yes, and this is exactly what i want to do - protect "client" code from accidentally altering some data that it should'nt alter. And i am asking about side-effects from that from unexpected compiler optimizations.
– firk
Jan 3 at 17:42
Yes, and this is exactly what i want to do - protect "client" code from accidentally altering some data that it should'nt alter. And i am asking about side-effects from that from unexpected compiler optimizations.
– firk
Jan 3 at 17:42
|
show 5 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54026918%2fnon-direct-typecasting-structs-from-const-to-non-const-via-ifdefs-in-header-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What part do you think might be non-compliant? the
structdefinition or theifdefpart?– Eugene Sh.
Jan 3 at 17:25
I fear the compiler may do some const-related optimizations while in fact the struct is not always const.
– firk
Jan 3 at 17:30
I don't think that it will provide the benefits you hope for. In fact, I think it is likely to make life uncomfortable. However, that's not a criticism of its technical feasibility; just on its practical usefulness.
– Jonathan Leffler
Jan 3 at 17:30
Then most of the text in the question is irrelevant. You are saying that you have two structures, but one is
constand one is not. And asking if these are compatible. No, they are not.– Eugene Sh.
Jan 3 at 17:32
1
Then you should ask about the compatibility. The "const optimizations" (and other optimizations) will depend on the type compatibility among the other considerations. Binary representation is pretty much irrelevant when speaking of the language rules.
– Eugene Sh.
Jan 3 at 17:40