Difference between '\0' and 0

[August Karlstrom]

Hello all,

If c is a char then is there any difference between

c = '\0'

and

c = 0

?
Regards,
August

[August Karlstrom]

Emmanuel Delahaye wrote:

Robert Gamble wrote on 29/05/05 :

(The literal 0 can also denote the nil pointer)

A nil pointer? Perhaps you mean NULL pointer constant, but this would
not apply to type char which is being discussed here...

'nil pointer' is a generic term used in Computer Science. Its
C-implementation is null pointer constant or NULL.

Thanks for the backup, this is exactly what I was trying to say.

-- August

[Peter Nilsson]

Robert Gamble wrote:

August Karlstrom wrote:

Robert Gamble wrote:

August Karlstrom wrote:
> (The literal 0 can also denote the nil pointer)

A nil pointer? Perhaps you mean NULL pointer constant, but this would
not apply to type char which is being discussed here...
I used "nil pointer" to emphasize the distinction between the "points to
nothing" concept and the C macro constant NULL.

You said that literal 0 can denote the "nil pointer". There is no nil
pointer in C, but there is a NULL pointer constant

There are null pointer constants which become null pointers when
converted to a pointer. NULL is an implementation defined null pointer
constant available when you include certain headers.
which can be expressed as a literal 0 in a pointer context.

Any integer constant with zero value is a null pointer constant, by
definition.

People, there's a whole section of the FAQ devoted to this! ;)

--
Peter

[Peter Nilsson]

Keith Thompson wrote:

C uses some specific pointer representation to represent a null
pointer.

Note: there may be more than one representation for null pointers.

--
Peter

[August Karlstrom]

Emmanuel Delahaye wrote:

August Karlstrom wrote on 29/05/05 :

If c is a char then is there any difference between
c = '\0'
and
c = 0
The Lint program Splint thinks there is a difference:
int main(void)
{
char c;

c = '\0';
c = 0;
return 0;
}
$ splint test.c
Splint 3.1.1 --- 15 Jun 2004

test.c: (in function main)
test.c:6:4: Assignment of int to char: c = 0
Types are incompatible. (Use -type to inhibit warning)

Finished checking --- 1 code warning

It's true that and int is not a char. Why in the world are you using a
char ? The cases where a single char is necessary are extremely rare
(only scanf("%c", &c) comes to my mind, and scanf() is not a recommended
function...)

You're right, this issue is more of theoretical interest.
That said, Lint seems to consider that '\0' is a char that is wrong in
C. (Or maybe, Lint is checking in C++ mode, in that case 0 is an int and
'\0' is a char). Your extension seems to be .c, that is correct for a
C-program. Check the Lint configuration.

Splint is a C only checker.

-- August

[CBFalconer]

Emmanuel Delahaye wrote:

Dik T. Winter wrote on 29/05/05 :

<...> The conclusion is that Splint does not handle character
constants correctly.

Arf! Who has checked the checker ?

You are missing the point. Splint doesn't have to handle character
constants correctly, or anything else for that matter. It is NOT a
compiler. It is a tool, whose purpose is to point out questionable
or problematic constructs. Further action is up to the programmer
and his compiler.

A better comparison is a spell checker, which probably will
highlight things that smell suspiciously like a mis-spelling. It
isn't expected to be right all the time.

--
Some informative links:
news:news.annou nce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Chris Croughton]

On Sun, 29 May 2005 20:37:21 GMT, Keith Thompson
<ks***@mib.or g> wrote:

A digression: In my opinion, C depends too heavily on implicit
conversions. If I were designing the language from scratch, most
conversions that are implicit in C would probably be explicit -- but
most of them would be expressed by some mechanism less heavyweight
than a cast. The resulting code would probably be more verbose than
typical C. If you like extreme terseness, be glad that I don't
actually design programming languages.
I would have no problem with you designing such a language, since that
language would not be C and so I wouldn't be using it <g>.
But given the actual design of
C, it almost always makes sense to use implicit conversions rather
than explicit casts, which tend to swat flies with sledgehammers.
Implicit conversions are bad from a language design point of view, but
good (or at least far better than the alternative) from a C
programming point of view.

If I want a strongly typed language I know where to find Ada <g>...

Chris C

[August Karlstrom]

Chris Croughton wrote:

On Sun, 29 May 2005 20:37:21 GMT, Keith Thompson
<ks***@mib.or g> wrote:

A digression: In my opinion, C depends too heavily on implicit
conversions . If I were designing the language from scratch, most
conversions that are implicit in C would probably be explicit -- but
most of them would be expressed by some mechanism less heavyweight
than a cast. The resulting code would probably be more verbose than
typical C. If you like extreme terseness, be glad that I don't
actually design programming languages.

I would have no problem with you designing such a language, since that
language would not be C and so I wouldn't be using it <g>.

But given the actual design of
C, it almost always makes sense to use implicit conversions rather
than explicit casts, which tend to swat flies with sledgehammers.
Implicit conversions are bad from a language design point of view, but
good (or at least far better than the alternative) from a C
programming point of view.

If I want a strongly typed language I know where to find Ada <g>...

Or why not Oberon-2.

-- August

[Old Wolf]

Dik T. Winter wrote:

'\377' is an int with value 255

Is that correct? I know that '\xFF' is implementation-defined
as to whether it is -1 or 255 ..

[Peter Nilsson]

Old Wolf wrote:

Dik T. Winter wrote:

'\377' is an int with value 255
Is that correct?

In strict terms, no.
I know that '\xFF' is implementation-defined
as to whether it is -1 or 255 ..

The value is the value c would have if it were evaluated as
in...

unsigned char x = 255;
int c = * (char *) &x;

In other words, the byte value of the constant is interpreted
as a (plain) char, and subsequently converted to an int.

It is implementation defined whether plain char is signed or
unsigned.

On implementations where CHAR_BIT > 8, and on implementations
where plain char is unsigned, the value is 255.

On 8-bit, signed plain char, ones complement or signed
magnitude machines, the value is effectively unspecified
under C90. C99 limits the representation of negative
integers more thoroughly, so the value is either -1, -0 or
-127 for 2c, 1c and sm representations respectively.

It is the view of many clc regulars that 1c and sm machines
must have unsigned plain char, if the implementation is
to have any QoI. However, there is nothing the standard
which precludes low QoI implementations .

--
Peter

[Chris Croughton]

On Mon, 30 May 2005 20:51:41 GMT, August Karlstrom
<fu********@com hem.se> wrote:

Chris Croughton wrote:

If I want a strongly typed language I know where to find Ada <g>...

Or why not Oberon-2.

Not powerful enough. For instance, one of the features I like in Ada is
declaring variables with specific ranges (-3..7 etc.), so that they
can't go out of bound without throwing an exception. Oberon-2 was, I
gather, created as a language for teaching, like Pascal (but later so it
learnt from some of the pitfalls of early Pascal), Ada was designed for
Real World(tm) tasks.

(That's not a criticism of Oberon-2, which is fine for its purpose, it's
just not as good for my purposes...)

Chris C