Thread: ROM Qualifier vs Const?

A friend asked me what rom meant, when used as a qualifier, I did not know so I looked into it. I gathered, from what little documentation exists about this qualifier, that it simply puts it into the "rom" (program space) rather than the data space ("RAM") as a standard variable would be.

One question, why?

Why would you want something to be in the program space, surely this doesn't make it persistent across instances, does it?

Why would you want to do:

Code:

rom int = 5;

In which it's in program space and can only be read opposed to:

Code:

const int = 5;

In which it's in the data space and only can be read..which goes further, since you can pack qualifiers onto a var declaration, to say, what happens if you do:

Code:

const rom int = 5;

It's already const by definition of the "rom" qualifier, and it's more or less "rom" by definition of the const qualifier (sure it's in the data segment, but it's still "read only").

Information on this is scarce as ........ for some reason, most keyword, reserved word, or qualifier lists (as I checked all of them I could find) don't even list them, and some that do don't have any info for them (it's just a blank).

Anybody know what I'm missing here?

rom is not a C keyword. Perhaps your friend saw someone do something like

Code:

#define rom const

where every instance of "rom" is replaced with "const" by the preprocessor.

At any rate, making the code const does not necessarily mean it is read only. By using the const qualifier, you make it so that you cannot change the contents of the variable with the particular variable name associated with the const qualifier. You may quite easily change the contents of the variable by using a different identifier though.

Originally Posted by kermit

rom is not a C keyword. Perhaps your friend saw someone do something like

Code:

#define rom const

where every instance of "rom" is replaced with "const" by the preprocessor.

I suppose it's possible, he didn't give me the usage, but I've seen some samples of it out there, meaning it is used...and if there's a pre-processor directive for it, that means it IS being used for SOMETHING, even if it's just replacing it with const. There's a reason they'd change the name, there's a reason somebody would use that name.

C doesn't have many (any?) keywords, they're all reserved, I believe.

Originally Posted by kermit

At any rate, making the code const does not necessarily mean it is read only. By using the const qualifier, you make it so that you cannot change the contents of the variable with the particular variable name associated with the const qualifier. You may quite easily change the contents of the variable by using a different identifier though.

So you're saying if you made a pointer to it and then dereferenced it you could change the value? I mean I suppose there's no stopping you there...and there's no pass by ref in C so you'd most likely be using a pointer, in which all bets of protecting anything are off...so are you saying if you did something like:

Code:

cont int c = 5;
int b = c;
c = 10; // invalid - won't compile -- assume removed
b = 10; // valid, won't complain
printf("%d\n", c);
printf("%d\n", b);

--------------------------------------

prints:
10
10

Will work?

I don't know, I don't use const, to me it's an embarrassment of the language.

Originally Posted by kermit

rom is not a C keyword. Perhaps your friend saw someone do something like

Code:

#define rom const

where every instance of "rom" is replaced with "const" by the preprocessor.

At any rate, making the code const does not necessarily mean it is read only. By using the const qualifier, you make it so that you cannot change the contents of the variable with the particular variable name associated with the const qualifier. You may quite easily change the contents of the variable by using a different identifier though.

I've done stuff like this at times. Mostly it's to remind me that something is special in some way.

Aliasing const as rom might be because the variables pointed to were in a chip and the programmer wanted a reminder.

Other than that... it's a distinction without a difference.

Originally Posted by kermit

?? C has as many keywords as specified by the standard. They are reserved in the sense that you may not use them as identifiers for anything else, e.g, :

Code:

int var1; /* OK */
int char; /* Not OK */

I thought a simple keyword (not a reserved word) was usable as a variable, but also meant something to the language when used in different context(s). A reserved word isn't allowed to be used as a variable. No?

Originally Posted by kermit

I was thinking of something more like this:

Code:

#include <stdio.h>

int main(void)
{
    const int i = 5;
    int *p = &i;

    i = 4      /* !! Wrong.   Cannot use identifier i to change contents of variable. */
    *p = 4;    /* We _can_ use any other identifier that points to the same place. */

    printf("The value of i is %d\n", i);

    return 0;
}

Now the compiler will complain when you try to compile, unless of course you do something evil, like this:

Code:

#include <stdio.h>

int main(void)
{
    const int i = 5;
    int *p = (int *) &i;

    *p = 4;

    printf("The value of i is %d\n", i);

    return 0;
}

You can crank up the warnings, and the compiler will not give so much as a peep.

Yeah, that's what I meant by using pointers, and by "So you're saying if you made a pointer to it and then dereferenced it you could change the value? I mean I suppose there's no stopping you there...and there's no pass by ref in C so you'd most likely be using a pointer, in which all bets of protecting anything are off..."

Pointers give you infinite power. I meant a non "cheat" method, as there's no pass by ref in C.[/quote]

Originally Posted by CommonTater

I've done stuff like this at times. Mostly it's to remind me that something is special in some way.

Aliasing const as rom might be because the variables pointed to were in a chip and the programmer wanted a reminder.

Other than that... it's a distinction without a difference.

Fair enough, I'm fairly against that sort of practice, but the compiler won't care.

Originally Posted by Salem

It´s more likely that you have a vendor specific C compiler which has a number of additional keywords for supporting programming of some embedded device.

Now what ´rom´ actually means in terms of any given compiler is dependent on that compiler. But chances are it means what has been hinted - that the value in question will be burned into the ROM when the device is programmed, and will be truly fixed for all time (and be available when the program starts).

A const in C just means ´warn me if I try to modify this´ (which is a bit different from the C++ idea of const).
A const value in C would still be in RAM and would have to be initialised by some mechanism.

Yeah, I guess that makes sense. How is const different in C than in C++? I was unaware of this.

Originally Posted by laserlight

I believe that it is the enforcement that is different, i.e., warning versus error.

I know C++ will stop you if you try to modify a const, that's why I've become best buddies with const_cast, I just tried modifying a const value in C and gcc told me it was read only.

Originally Posted by laserlight

You should not be best buddies with const_cast unless you are stuck working with some library that fails miserably in the const correctness department.

As I said earlier, I am firmly against the use of const (at all) - I hate it and think it's an embarrassment to the language. I've never had const save me, only give me grief. Const cast is probably the best thing around because of people who decide that EVERY accessor NEEDS to return a const value.

It should be up to the programmer to NOT screw with things he or she shouldn't. Not the compiler. That kind of protection is expected at higher levels such as Java, it has no place for C nor C++.