|How are string literals represented internally by compilers? firstname.lastname@example.org (Tony) (2009-06-19)|
|Re: How are string literals represented internally by compilers? email@example.com (glen herrmannsfeldt) (2009-06-21)|
|Re: How are string literals represented internally by compilers? firstname.lastname@example.org (Walter Banks) (2009-06-23)|
|From:||glen herrmannsfeldt <email@example.com>|
|Date:||Sun, 21 Jun 2009 21:44:02 +0000 (UTC)|
|Organization:||California Institute of Technology, Pasadena|
Tony <firstname.lastname@example.org> wrote:
< I don't remember reading about how string literals are represented in any of
< the books I have. Until I go back and scour those for the info (assuming it
< is there), I'll ask here. How are string literals represented internally by
When you say 'internally by compilers', it seems to me that you
mean during compilation.
< I assume that it's probably null-terminated character string for
< C and C++ and some kind of length-prefixed thing for Pascal in a specially
< designated data segment area and then just some sort of pointer for a given
< literal is placed in the code, yes?
Those seem likely for the object code and run time representation
for constants. Internally to the compiler, they are likely in
the representation for the language that the compiler is written in.
I would not be surprised to see C compilers in Pascal, or Pascal
compilers in C, though I don't actually know of any. (I haven't
looked very hard.)
The other question for constants, is whether you combine multiple
instances of the same constant into one. It gets interesting if
it is possible, even accidentally, to modify constants.
(Traditionally fun for Fortran, which usually passes arguments
by reference, even constants. Also, K&R C allows string constants
to be modified, though ANSI removed that feature.)
Return to the
Search the comp.compilers archives again.