about string and character

[ymuntyan]

Then why don't you just code
char a = "";
and see what your compiler has to say about it?

I don't take it because it converts a pointer to a char for some
reason, to demonstrate some point. And it has undefined behavior
on my system I believe (I bet it's UB on your system too).

Probably because you think you know this and are just trolling.

If I am trolling, then you are double-trolling: my question was
a particular case of the original question, and your reply is
bunch of "why don't you do <something else>" like it answers
something

Here are four bytes in memory on an 8-byte boundary: 0x20414200.
Do they represent a string or part of one; four individual char; 2
short; 1 short; 2 int; 1 int; if either type of int are the
magnitude(s) large, medium, or small; 1 long; or one float? It's the
same four bytes; how could they possibly mean different things?

Indeed, this question is so hard that gcc will bite your arse if you
don't stick to "it's magic, but it's not just a byte sequence
that matters" rule, contributing to popularity of -fno-strict-aliasing
option. It has nothing to do with the original question though,
because "string" is not a data type.

Try
char x[5];
void *p1 = x; /*(1)*/
void *p2 = &x; /*(2)*/

p1 is obviously equal to p2. Since equality is transitive, how can
the right hand expression of (1) possibly be different than the right
hand expression of (2)?

So you take an array, you do the stuff. So what? What does it have to
do with a char object? Please, pointer comparison rules are not what
we are talking about (even if it was about pointers, result of
comparison with == operator is different from "being the same or
different"). Oh well.

Best regards,
Yevgen

 

[Keith Thompson]

Then why don't you just code
char a = "";
and see what your compiler has to say about it?

Obviously that's a constraint violation.

But ``char a = 0;'' does create a valid string, such that strlen(&a)
will yield the value 0.

Given these declarations:

char x = 0;
char *y = "";
char z[] = "";

x, y, and z are of three different types (char, pointer to char, array
of 1 char), but all three declarations create strings. That's because
a string is not a data type, but a data format.

Creating an empty string by declaring a char initialized to 0 is a
very silly thing to do, but it's valid.

[...]

 

[Chris Torek]

char str[] = "Hello";
The sizeof str is 6 while strlen(str) is 5.
Indeed.

While the nul is of type char it's not really a character, is it?

It is definitely a "char". It is a valid character, although it
is not what some people call a character. (Some people call *me*
a character. ) As usual, this all comes down to the general
problem of making sure that everyone involved in some discussion
intents the same semantics when they use the same words. (I
occasionally see people say things like "bah, mere semantics", yet
"semantics" are essential to correct understanding.)

As another data point, note that strchr() and strrchr() will
find the terminating '\0'. For instance:

char s[] = "Hello";
char *p = strchr(s", '\0');

will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
can say that for some Standard C functions dealing with strings,
the terminating '\0' *is* "part of the string"; for others (e.g.,
strlen()), it is excluded.

 

[Willem]

Chris wrote:
) will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
) can say that for some Standard C functions dealing with strings,
) the terminating '\0' *is* "part of the string"; for others (e.g.,
) strlen()), it is excluded.

Doesn't strlen return the index of the first '\0' in a string ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Richard Heathfield]

Willem said:

Chris wrote:
) will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
) can say that for some Standard C functions dealing with strings,
) the terminating '\0' *is* "part of the string"; for others (e.g.,
) strlen()), it is excluded.

Doesn't strlen return the index of the first '\0' in a string ?

And the last.

 

[Charlie Gordon]

Willem said:

Chris wrote:
) will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
) can say that for some Standard C functions dealing with strings,
) the terminating '\0' *is* "part of the string"; for others (e.g.,
) strlen()), it is excluded.

Doesn't strlen return the index of the first '\0' in a string ?

And the last.

That's debatable:

strlen("abc\0def") -> 3

Are 'd', 'e', 'f', and the final '\0' not part of the object "abc\0def" ?
Is "abc\0def" not a string ?

 

[Charlie Gordon]

Then why don't you just code
char a = "";
and see what your compiler has to say about it?

Obviously that's a constraint violation.

But ``char a = 0;'' does create a valid string, such that strlen(&a)
will yield the value 0.

Given these declarations:

char x = 0;
char *y = "";
char z[] = "";

x, y, and z are of three different types (char, pointer to char, array
of 1 char), but all three declarations create strings. That's because
a string is not a data type, but a data format.

Creating an empty string by declaring a char initialized to 0 is a
very silly thing to do, but it's valid.

So is this:

char x = *"";

;-)

 

[Dik T. Winter]

> > Willem said:
> >

> >> Chris wrote:
> >> ) will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
> >> ) can say that for some Standard C functions dealing with strings,
> >> ) the terminating '\0' *is* "part of the string"; for others (e.g.,
> >> ) strlen()), it is excluded.
> >>
> >> Doesn't strlen return the index of the first '\0' in a string ?

> >
> > And the last.

>
> That's debatable:
>
> strlen("abc\0def") -> 3
>
> Are 'd', 'e', 'f', and the final '\0' not part of the object "abc\0def" ?
> Is "abc\0def" not a string ?

They are a single object. But only the firt part is a string.

 

[santosh]

Willem said:

Chris wrote:
) will leave p non-NULL, pointing to the '\0' stored in s[5].
So we ) can say that for some Standard C functions dealing with
strings, ) the terminating '\0' *is* "part of the string"; for
others (e.g., ) strlen()), it is excluded.

Doesn't strlen return the index of the first '\0' in a string ?


And the last.

That's debatable:

strlen("abc\0def") -> 3

Are 'd', 'e', 'f', and the final '\0' not part of the object
"abc\0def" ? Is "abc\0def" not a string ?

They are a single object. But only the firt part is a string.

Then the name "character string literal" would be misleading.

 

[Keith Thompson]

Willem said:

Chris wrote:
) will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
) can say that for some Standard C functions dealing with strings,
) the terminating '\0' *is* "part of the string"; for others (e.g.,
) strlen()), it is excluded.

Doesn't strlen return the index of the first '\0' in a string ?

And the last.

That's debatable:

strlen("abc\0def") -> 3

Are 'd', 'e', 'f', and the final '\0' not part of the object "abc\0def" ?

They're part of the object; they're not part of the string.

Is "abc\0def" not a string ?

No, it isn't. { 'a', 'b', 'c', '\0' } is a string, defined by the
standard as "a contiguous sequence of characters terminated by and
including the first null character".

 

[Keith Thompson]

Then the name "character string literal" would be misleading.

This is acknowledged in a footnote in C99 6.4.5:

A character string literal need not be a string (see 7.1.1),
because a null character may be embedded in it by a \0 escape
sequence.

 

[Joe Wright]

char str[] = "Hello";
The sizeof str is 6 while strlen(str) is 5.
Indeed.

While the nul is of type char it's not really a character, is it?

It is definitely a "char". It is a valid character, although it
is not what some people call a character. (Some people call *me*
a character. ) As usual, this all comes down to the general
problem of making sure that everyone involved in some discussion
intents the same semantics when they use the same words. (I
occasionally see people say things like "bah, mere semantics", yet
"semantics" are essential to correct understanding.)

As another data point, note that strchr() and strrchr() will
find the terminating '\0'. For instance:

char s[] = "Hello";
char *p = strchr(s", '\0');

will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
can say that for some Standard C functions dealing with strings,
the terminating '\0' *is* "part of the string"; for others (e.g.,
strlen()), it is excluded.

All good and true, nonetheless I contend, given ASCII, that codes from 0
through 127 are values of type char but not what I call a character. The
character values start at 32 (space) through 126. Please consider..

| 0 NUL| 1 SOH| 2 STX| 3 ETX| 4 EOT| 5 ENQ| 6 ACK| 7 BEL|
| 8 BS | 9 HT | 10 LF | 11 VT | 12 FF | 13 CR | 14 SO | 15 SI |
| 16 DLE| 17 DC1| 18 DC2| 19 DC3| 20 DC4| 21 NAK| 22 SYN| 23 ETB|
| 24 CAN| 25 EM | 26 SUB| 27 ESC| 28 FS | 29 GS | 30 RS | 31 US |
| 32 | 33 ! | 34 " | 35 # | 36 $ | 37 % | 38 & | 39 ' |
| 40 ( | 41 ) | 42 * | 43 + | 44 , | 45 - | 46 . | 47 / |
| 48 0 | 49 1 | 50 2 | 51 3 | 52 4 | 53 5 | 54 6 | 55 7 |
| 56 8 | 57 9 | 58 : | 59 ; | 60 < | 61 = | 62 > | 63 ? |
| 64 @ | 65 A | 66 B | 67 C | 68 D | 69 E | 70 F | 71 G |
| 72 H | 73 I | 74 J | 75 K | 76 L | 77 M | 78 N | 79 O |
| 80 P | 81 Q | 82 R | 83 S | 84 T | 85 U | 86 V | 87 W |
| 88 X | 89 Y | 90 Z | 91 [ | 92 \ | 93 ] | 94 ^ | 95 _ |
| 96 ` | 97 a | 98 b | 99 c |100 d |101 e |102 f |103 g |
|104 h |105 i |106 j |107 k |108 l |109 m |110 n |111 o |
|112 p |113 q |114 r |115 s |116 t |117 u |118 v |119 w |
|120 x |121 y |122 z |123 { |124 | |125 } |126 ~ |127 DEL|

It's easy for me to see ACK (6) as char type but I can't see it as a
character. This argument is a mole-hill, not a mountain.

 

[Joe Wright]

Chris wrote:
) will leave p non-NULL, pointing to the '\0' stored in s[5]. So we
) can say that for some Standard C functions dealing with strings,
) the terminating '\0' *is* "part of the string"; for others (e.g.,
) strlen()), it is excluded.

Doesn't strlen return the index of the first '\0' in a string ?


SaSW, Willem

No. 'size_t strlen(const char *s);' returns an unsigned integer count of
the number of characters before the terminating nul.

 

[Richard Heathfield]

Joe Wright said:

Willem wrote:

No. 'size_t strlen(const char *s);' returns an unsigned integer count of
the number of characters before the terminating nul.

How does that result differ from the index of the first '\0' in a string?

 

[CBFalconer]

will leave p non-NULL, pointing to the '\0' stored in s[5]. So
we can say that for some Standard C functions dealing with
strings, the terminating '\0' *is* "part of the string"; for
others (e.g., strlen()), it is excluded.

Doesn't strlen return the index of the first '\0' in a string ?

No. 'size_t strlen(const char *s);' returns an unsigned integer
count of the number of characters before the terminating nul.

Which (index, not address) is the same thing. If the char array
doesn't hold a string it causes UB.

 

[Joe Wright]

Joe Wright said:


How does that result differ from the index of the first '\0' in a string?

It doesn't. Apologies to all.

 

[Keith Thompson]

All good and true, nonetheless I contend, given ASCII, that codes from
0 through 127 are values of type char but not what I call a
character. The character values start at 32 (space) through
126. Please consider..

[ASCII chart snipped]

It's easy for me to see ACK (6) as char type but I can't see it as a
character. This argument is a mole-hill, not a mountain.

It's a character as the term is defined by the C standard. See C99
3.7 and 3.7.1.

 

[Eric Sosman]

[...]
All good and true, nonetheless I contend, given ASCII, that codes from 0
through 127 are values of type char but not what I call a character. The
character values start at 32 (space) through 126. Please consider..
[...]
It's easy for me to see ACK (6) as char type but I can't see it as a
character. This argument is a mole-hill, not a mountain.

Poor guy. I guess one could get along without tabs,
but C without newlines must be pretty hard to manage ...