[comp.lang.c] Character constants

richard@aiai.ed.ac.uk (Richard Tobin) (03/01/89)

In article <1783@dlvax2.datlog.co.uk> scm@datlog.co.uk ( Steve Mawer ) writes:
>Not if he knows the C language.  A single character written within
>single quotes is a *character constant*.  This isn't an int.

K&R, p180:
  The value of a character constant is the numerical value of the
  character in the machine's character set.

Draft proposed ANSI standard (May 13, 1988) Section 3.1.3.4 (p29):
  An integer character constant has type int.

["integer character constant" constrasts with "wide character constant"]

-- Richard

-- 
Richard Tobin,                         JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,             ARPA:  R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.                  UUCP:  ...!ukc!ed.ac.uk!R.Tobin

curci@stat.uucp (Ray Curci (scri)) (03/03/89)

Why is therer so much discussion about  character discussions?

A simple printf("%d", sizeof('x') ); reveals that a character constant
(at least both on sun3 and ultrix 11/780) are the same as an int (4 chars).
Isn't it a lot easier to execute a simple test program than to try to
look up this type of information?

curci@stat.fsu.edu

rob@sleepy.eng.ohio-state.edu (Rob Carriere) (03/03/89)

In article <7447@pyr.gatech.EDU> curci@stat.fsu.edu (Ray Curci (scri)) writes:
>Why is therer so much discussion about  character discussions?
>
>A simple printf("%d", sizeof('x') ); reveals that a character constant
>(at least both on sun3 and ultrix 11/780) are the same as an int (4 chars).
>Isn't it a lot easier to execute a simple test program than to try to
>look up this type of information?

Yes, it is (usually) much easier.  Yes, you should do it, *to test
your compiler*.  No, it does not answer the question.  A compiler does
not a language definition make.

Secondly, your test here is insufficient.  For example, the computer
that is currently bearing with me chattering all over the place will,
on request, also happily provide the information that

sizeof(long) == sizeof(float) 

The assumption that this would mean that the types long and float are
the same seems rather unsafe.

SR

henry@utzoo.uucp (Henry Spencer) (03/04/89)

In article <7447@pyr.gatech.EDU> curci@stat.fsu.edu (Ray Curci (scri)) writes:
>A simple printf("%d", sizeof('x') ); reveals that a character constant
>(at least both on sun3 and ultrix 11/780) are the same as an int (4 chars).
>Isn't it a lot easier to execute a simple test program than to try to
>look up this type of information?

Unfortunately, executing a test program just tells you what your compiler
thinks the answer is.  That doesn't mean it's right.  Quite apart from
compiler bugs, which definitely exist, there has been some divergence
among C compilers over the years.  It will be quite a while before all
compilers comply with the ANSI standard, even in theory.
-- 
The Earth is our mother;       |     Henry Spencer at U of Toronto Zoology
our nine months are up.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

guy@auspex.UUCP (Guy Harris) (03/04/89)

>A simple printf("%d", sizeof('x') ); reveals that a character constant
>(at least both on sun3 and ultrix 11/780) are the same as an int (4 chars).
>Isn't it a lot easier to execute a simple test program than to try to
>look up this type of information?

Doug Gwyn indicated that one version of a C compiler delivered by one
vendor decided that

	sizeof "this is a big fat string"

was the same as

	sizeof (char *)

which is simply not correct.  Your simple test program may give the
wrong answer if your compiler is buggy.

It may be easier to execute a simple test program, but it may not be
easier to believe the results of that program....

byrum@cs.odu.edu (Terry Franklin Byrum) (03/07/89)

I am borrowing this account; see signature below.

Speaking of checking sizeof() to determine language specifications, I've
found it to be of even greater use in revealing compiler aberrations (BUGS!!).

Try the following little program on your "favorite" compiler.  Explaining each
line is a good exercise for the novice, and loooking at the output is a good
test of a compiler.  Notice that the Microsoft compiler gets line 2 correct,
but blows line 3: incredible since it is a fundamental rule of C language
that p[i] == *(p + i) for any pointer p and int i.  With attitudes like that,
it's a wonder it ever gets any array indexing or pointer indirection right!

                                        Lloyd Kremer
                                        Brooks Financial Systems
                                        ...!xanth!brooks!lloyd
                                        Have terminal ... will hack!

------------------cut here------------------------------------------
main()
{
	double foo[2][10];

	printf("sizeof(foo) == %d\n", sizeof(foo));
	printf("sizeof(foo[0]) == %d\n", sizeof(foo[0]));
	printf("sizeof(*foo) == %d\n", sizeof(*foo));
	printf("sizeof(foo[0][0]) == %d\n", sizeof(foo[0][0]));
	printf("sizeof(**foo) == %d\n", sizeof(**foo));
	printf("sizeof(*foo[0]) == %d\n", sizeof(*foo[0]));
	printf("sizeof((*foo)[0]) == %d\n", sizeof((*foo)[0]));
	return(0);
}

/* CORRECT OUTPUT: (assuming sizeof(double) == 8)
sizeof(foo) == 160
sizeof(foo[0]) == 80
sizeof(*foo) == 80       Microsoft 5.1 C Compiler says 160 here!  (BROKEN!!)
sizeof(foo[0][0]) == 8
sizeof(**foo) == 8
sizeof(*foo[0]) == 8
sizeof((*foo)[0]) == 8
*/
------------------cut here------------------------------------------

-- 

	Inventions have long since reached their limit --
	and I see no hope for further developments.
		- Julius Frontinus, world famous engineer, Rome, 10 AD

                                |  Terry Franklin (Frank) Byrum
                                |  BROOKS Financial Systems, Inc.
   ___                          |  INET:  byrum@cs.odu.edu
  /__  _.  __. _ _  /_          |  UUCP:  ...!sun!xanth!brooks!byrum 
 /   _/ \_(_/|_|\|_/ \          |  DISCLAIMER: No one listens anyway! 

daniel@gonzo.UUCP (Daniel Lanier) (03/08/89)

In article <1113@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>Doug Gwyn indicated that one version of a C compiler delivered by one
>vendor decided that
>
>	sizeof "this is a big fat string"
>
>was the same as
>
>	sizeof (char *)
>
>which is simply not correct.  Your simple test program may give the
>wrong answer if your compiler is buggy.

tick-tock, tick-tock, bing!

	Gould UTX 1.2

"I have here in my hand a list of 63 known compiler bugs that walk like a
duck, talk like a duck, and look like a duck, and I want to know what
the administration is going to do about them."

Sometimes you have to name names, or at least feel a compulsive urge...

	Danil




-- 
							"Wiseguy, huh?"