3

Given following definition of global (or static local) variable:

static const <type>* const ptr = {&var1, &var2, ...};

, may I rely upon the fact that both ptr and data in initializer list will be placed to separate read-only section of generated object file (i.e. it will not be placed to .data or similar sections containing non-const variables) ?

Question relates only to gcc c/c++ compiler behavior common to all architectures/platforms (at least those of them where read-only memory exists). It doesn't imply any platform, processor, OS, linker, start-up runtime, libraries, etc.

Please, don't ask me what I'm going to do. I know what I'm doing. If the information I provided are not enough for answer then issue has to be considered as xxx-specific and generic answer is "No". I have already read questions-answers where this subject was mentioned very close:

Impact of the type qualifiers on storage locations
How is read-only memory implemented in C?
Does "const" just mean read-only or something more?
Why does compiler allow you to "write" a const variable here?
GCC C++ (ARM) and const pointer to struct field
memcpy with destination pointer to const data

But I didn't found assured and direct answer.

Community
  • 1
  • 1
Artem Pisarenko
  • 123
  • 1
  • 2
  • 13
  • 1
    Have you looked at the link map created by your linker to see exactly where each variable is placed? – Greg Hewgill Nov 18 '12 at 18:31
  • Is this behaviour specified by the C++ standard? If not, I wouldn't assume it's "guaranteed" in a strict sense of the word. – millimoose Nov 18 '12 at 18:32
  • @Greg Hewgill, it will not guarantee behavior in such generic assumption. – Artem Pisarenko Nov 18 '12 at 18:37
  • I would *guess* that it is, to some extent (if these definitions are distinguishable from their non-const relatives), based on the default linker scripts that gcc uses. These, in turn, are platform dependent, and so a general answer would not be possible. – Damien_The_Unbeliever Nov 18 '12 at 18:37
  • @Damien_The_Unbeliever, it doesn't depend on linker script. I ask about input sections of each object file generated by compiler before it's being passed to any linker. – Artem Pisarenko Nov 18 '12 at 18:47
  • 1
    @Artem Pisarenko: Your definition is invalid. You cannot use `{}` initializer with multiple values inside to initialize a pointer. Did you intend to use a compound literal? – AnT stands with Russia Dec 05 '12 at 08:14

1 Answers1

2

According to the stackoverflow thread Where are constant variables stored in C? It is implementations specific. And personally I would not even rely on the thought that all GCC ports are implemented the same way. That's why for example the AVR port introduced a "progmem" attribute.

So according to your

Don't ask me what I'm doing, if there is not enough information, the answer is "no"

attitude, I'd say here: The answer is "no" there is no portable way to guarantee something like that. In fact even if you instruct the compiler and the linker to place it in something like a "readonly section". If this section lies in RAM, who will prevent write access to this section?

Community
  • 1
  • 1
junix
  • 3,161
  • 13
  • 27
  • 1
    This is not the only rason for `progmem` in AVR. `progmem` stuff lives in Flash, while "normal" stuff lives in RAM where it is copied to from flash at startup. This is because AVR is It is mainly for not breaking [Harvard architecture](http://en.wikipedia.org/wiki/Harvard_architecture). – glglgl Dec 05 '12 at 08:22
  • @glglgl Yes, that's true. But I thought this additional information would not be needed here, as this is not the point of the discussion. – junix Dec 05 '12 at 13:44
  • That's right... maybe "That's one reason (amongst others) why for example..." whatever. Not important... – glglgl Dec 05 '12 at 14:01
  • I decided to I rely on this in my platform. Of course, it requires proper linker script. The question was about support from compiler side. – Artem Pisarenko Jan 01 '13 at 17:37