By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,795 Members | 1,832 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,795 IT Pros & Developers. It's quick & easy.

Printing string constants

P: n/a
I have a quick question regarding printing string constants. When you
printf() a string constant, how are the characters encoded that get
sent to the standard output? Is it in the execution character set?

Thanks in advance.

Jun 30 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On 30 Jun 2006 07:41:14 -0700, "Ross" <ro************@yahoo.co.uk>
wrote:
I have a quick question regarding printing string constants. When you
printf() a string constant, how are the characters encoded that get
sent to the standard output? Is it in the execution character set?

If by string constant you mean string literal, they are created at
compile time. I expect the compiler is required to convert them from
the compilation character set to the execution character set. On the
other hand, you can send any NUL-terminated array of char to printf
and it is up to whatever is on the other side of stdout to determine
what happens to each byte.
Remove del for email
Jul 1 '06 #2

P: n/a
"Ross" <ro************@yahoo.co.uk> wrote
I have a quick question regarding printing string constants. When you
printf() a string constant, how are the characters encoded that get
sent to the standard output? Is it in the execution character set?

That's right.
Normally C source is written in ASCII, and generally C programs use ASCII
internally as their execution set. A few years ago I would have said "most
machines are ASCII" but the concept of an "ASCII machine" has become a bit
fuzzier since then.
Occasionally you might have a C source, but compile for a machine with a
funny character set. So the source file

printf("Hello world\n");

contains the ASCII values 72, 101, 108, 108, etc, along with ASCII values
for the quote,34 paretheses 40, 41, and so on.

Our funny system uses 100 for A, 101 for B, 200 for a 201 for b and so on.
So when we compile, the string "Hello world\n" is laid out in memory as 107,
204, 211, 211 etc. These values are passed to printf(), and by some magic
the glyphs appear in shining pixels on the screen.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
Jul 1 '06 #3

P: n/a
"Malcolm" <re*******@btinternet.com> writes:
"Ross" <ro************@yahoo.co.uk> wrote
I have a quick question regarding printing string constants. When you
printf() a string constant, how are the characters encoded that get
sent to the standard output? Is it in the execution character set?

That's right.
Normally C source is written in ASCII, and generally C programs use ASCII
internally as their execution set. A few years ago I would have said "most
machines are ASCII" but the concept of an "ASCII machine" has become a bit
fuzzier since then.

[...]

It depends on what you mean by "normally".

There are still machines that use the EBCDIC character set. C
programs on such machines are written in EBCDIC, and they generally
produce EBCDIC output. This is not common, and it's probably becoming
less common with the passage of years, but there's nothing abnormal
about it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 1 '06 #4

P: n/a
"Keith Thompson" <ks***@mib.orgwrote
"Malcolm" <re*******@btinternet.comwrites:

It depends on what you mean by "normally".

There are still machines that use the EBCDIC character set. C
programs on such machines are written in EBCDIC, and they generally
produce EBCDIC output. This is not common, and it's probably becoming
less common with the passage of years, but there's nothing abnormal
about it.
But it must happen that programmers who work with such machines regularly
take functions stored as ASCII text, for example in the comp.lang.c FAQ, and
expect them to work on their platform.

Anyway, what is the PC I am typing this at? Would you call it a Unicode
machine or an ASCII machine? Surely it is really an attribute of the program
that happens to be running at the time, in a modern system.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm

Jul 1 '06 #5

P: n/a
Malcolm said:
"Keith Thompson" <ks***@mib.orgwrote
>"Malcolm" <re*******@btinternet.comwrites:

It depends on what you mean by "normally".

There are still machines that use the EBCDIC character set. C
programs on such machines are written in EBCDIC, and they generally
produce EBCDIC output. This is not common, and it's probably becoming
less common with the passage of years, but there's nothing abnormal
about it.
But it must happen that programmers who work with such machines regularly
take functions stored as ASCII text, for example in the comp.lang.c FAQ,
and expect them to work on their platform.
Yes. When they move those programs to their platform, it typically undergoes
a translation process (e.g. ASCII to EBCDIC). It's commonplace, and easy to
do, although the various flavours of EBCDIC make it slightly more
interesting if you have to write the conversion yourself. Normally, though,
a mainframe is accessed via terminal emulation software which knows how to
do the translation for you, in either direction.
Anyway, what is the PC I am typing this at? Would you call it a Unicode
machine or an ASCII machine? Surely it is really an attribute of the
program that happens to be running at the time, in a modern system.
Right. Who cares? As long as there's a way to convert text to the relevant
character set, that's all that matters.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 1 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.