[comp.lang.c] Special character constants

adrian@mti.mti.com (Adrian McCarthy) (01/16/91)

I only have K&R2, not the Standard.  On a machine whose character set does
not support special characters like tab and backspace, what happens to
character constants like '\t' and '\b'?  Is there some special value they
get set to (e.g., ' ' or '\0') instead?  Or is this issue left undefined?

I'd like to keep some code I'm writing portable to many machines by using
tabs if they are available and emulating them with spaces if they are not.

Aid.  (adrian@gonzo.mti.com)

gwyn@smoke.brl.mil (Doug Gwyn) (01/16/91)

In article <1292@mti.mti.com> adrian@mti.UUCP (Adrian McCarthy) writes:
>I only have K&R2, not the Standard.  On a machine whose character set does
>not support special characters like tab and backspace, what happens to
>character constants like '\t' and '\b'?  Is there some special value they
>get set to (e.g., ' ' or '\0') instead?  Or is this issue left undefined?

A conforming implementation MUST provide distinct character values for these.
However, it is not absolutely required to force I/O devices to handle them in
the intended way.

>I'd like to keep some code I'm writing portable to many machines by using
>tabs if they are available and emulating them with spaces if they are not.

Just use spaces.  If you really have to deal with such variations, there
are numerous other environmental variations you should also take care of,
and these lie outside the scope of standard C.

henry@zoo.toronto.edu (Henry Spencer) (01/17/91)

In article <1292@mti.mti.com> adrian@mti.UUCP (Adrian McCarthy) writes:
>...On a machine whose character set does
>not support special characters like tab and backspace, what happens to
>character constants like '\t' and '\b'?  Is there some special value they
>get set to (e.g., ' ' or '\0') instead?  Or is this issue left undefined?

They must have *some value* distinct from each other and from printable
characters.  In general, I think you are confusing the character set with
the output devices.  An ASCII tab character is still a tab character even
if a particular output device does not do anything useful with it.  Almost
every modern machine uses ASCII or some variant thereon, so the characters
almost invariably exist in the character set.

>I'd like to keep some code I'm writing portable to many machines by using
>tabs if they are available and emulating them with spaces if they are not.

Bear in mind that the definition of what an output device *does* with a
tab is very device-dependent.  Just having tabs "available" is not enough;
you need to know exactly how they are processed.  Short of using a library
like termcap or curses, if you want precise output appearance without any
prior knowledge of hardware or software, you're going to have to use
spaces regardless.
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry

karl@ima.isc.com (Karl Heuer) (01/17/91)

In article <1292@mti.mti.com> adrian@mti.UUCP (Adrian McCarthy) writes:
>On a machine whose character set does not support special characters like tab
>and backspace, what happens to character constants like '\t' and '\b'?

The character constants get unique values no matter what.  I would expect that
on a tabless system the stdio library would convert '\t' into the appropriate
number of spaces when writing to a terminal.  (I thought it might even do this
for all text streams, but the standard says that filtering through a text
stream preserves tabs as well as newlines and printable characters.  Note that
backspace and other control characters do not share this property.)

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint

mike (Michael Stefanik) (01/18/91)

In article <1292@mti.mti.com> adrian@mti.UUCP (Adrian McCarthy) writes:
>I only have K&R2, not the Standard.  On a machine whose character set does
>not support special characters like tab and backspace, what happens to
>character constants like '\t' and '\b'?  Is there some special value they
>get set to (e.g., ' ' or '\0') instead?  Or is this issue left undefined?

That is dependant on the C preprocessor that runs on your machine; however,
what character set are you using that doesn't support tabs or backspace?
Just curious ...
-- 
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
--
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."

martin@mwtech.UUCP (Martin Weitzel) (01/22/91)

In article <1991Jan16.174248.2689@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
[...]
>Bear in mind that the definition of what an output device *does* with a
>tab is very device-dependent.  Just having tabs "available" is not enough;
>you need to know exactly how they are processed.  Short of using a library
>like termcap or curses, if you want precise output appearance without any
>prior knowledge of hardware or software, you're going to have to use
>spaces regardless.

Hey, wait a moment here. If we drive this to the extreme, can we really
depend on spaces to produce certain visible space on some output device?
Or is it just so that the *probability* of space-characters producing
some space on output devices is higher than for tab-characters? Well, I
know this is nit-picking, but consider the case of

	a) some printer or terminal emulator (sort of `xterm') running
	   with a proportional spaced font (with properly set up tabs
	   tab-characters are somewhat more likely to produce halfway
	   "nice" alignment in this situation).

	b) a `dumb' terminal without `line-wrap' on printable characters
	   but with line-wrap on tabs and the cursor beeing allready in
	   the last column.

What is the *least* the programmer can depend on? Can he or she depend on
certain results of `printf("hello, world\n");' IMHO it's completly outside
the scope of the standard what visible rendering would result from this (if
we assume the output is directed to some device capable of producing visible
renderings).
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83

gwyn@smoke.brl.mil (Doug Gwyn) (01/26/91)

In article <1063@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>Hey, wait a moment here. If we drive this to the extreme, can we really
>depend on spaces to produce certain visible space on some output device?

No, but it is a reasonable thing to expect.
The C standard is simply not in a position to dictate the detailed
characteristics of external devices.  It does require that distinct
code values be provided for representing a certain set of characters
both at compile time and at run time, but there is no requirement
that even the "graphic" characters have any particular glyphs on
actual devices.  (They could be holes in a punched card or paper tape.)
Control characters are even more difficult to rely on; the C standard
stipulates what the "intended" effect of them is, but a conforming
implementation may be deficient in its support of these intentions.

>What is the *least* the programmer can depend on? Can he or she depend on
>certain results of `printf("hello, world\n");'

No, the user may not understand English.

henry@zoo.toronto.edu (Henry Spencer) (02/08/91)

In article <1063@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>... If we drive this to the extreme, can we really
>depend on spaces to produce certain visible space on some output device?
>Or is it just so that the *probability* of space-characters producing
>some space on output devices is higher than for tab-characters?

The latter.  The interpretation of space is mostly agreed on; not so for tab.
-- 
"Maybe we should tell the truth?"      | Henry Spencer at U of Toronto Zoology
"Surely we aren't that desperate yet." |  henry@zoo.toronto.edu   utzoo!henry