Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12949 > unrolled thread

Character Array vs String

Back to article view | Back to comp.lang.c

Contents

  Character Array vs String Sheky <shekhar07.nitdgp@gmail.com> - 2011-11-09 03:09 -0800
    Re: Character Array vs String Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 03:28 -0800
    Re: Character Array vs String James Kuyper <jameskuyper@verizon.net> - 2011-11-09 06:52 -0500
    Re: Character Array vs String Quentin Carbonneaux <qcarbonn@invalid.com> - 2011-11-09 12:01 +0000
      Re: Character Array vs String 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-09 04:48 -0800
        Re: Character Array vs String Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 05:53 -0800
          Re: Character Array vs String "osmium" <r124c4u102@comcast.net> - 2011-11-09 09:44 -0600
            Re: Character Array vs String Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-10 00:57 -0800
              Re: Character Array vs String "osmium" <r124c4u102@comcast.net> - 2011-11-10 08:56 -0600
                Re: Character Array vs String Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-10 08:16 -0800
                  Re: Character Array vs String "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2011-11-10 18:34 +0100
                    Re: Character Array vs String Kenneth Brody <kenbrody@spamcop.net> - 2011-11-10 14:08 -0500
                      Re: Character Array vs String Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 20:52 +0000
                    Re: Character Array vs String Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-11 01:29 -0800
                Re: Character Array vs String Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-11-10 12:29 -0500
                Re: Character Array vs String lawrence.jones@siemens.com - 2011-11-10 12:32 -0500
                  Re: Character Array vs String Keith Thompson <kst-u@mib.org> - 2011-11-10 12:41 -0800
                  Re: Character Array vs String jt@toerring.de (Jens Thoms Toerring) - 2011-11-11 13:12 +0000
                Re: Character Array vs String David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
                  Re: Character Array vs String Kenneth Brody <kenbrody@spamcop.net> - 2011-11-23 11:39 -0500
                    Re: Character Array vs String "BartC" <bc@freeuk.com> - 2011-11-23 17:15 +0000
                      Re: Character Array vs String Kaz Kylheku <kaz@kylheku.com> - 2011-11-23 18:48 +0000
                      Re: Character Array vs String Ben Pfaff <blp@cs.stanford.edu> - 2011-11-23 10:58 -0800
                      Re: Character Array vs String Patrick Scheible <kkt@zipcon.net> - 2011-11-27 20:21 -0800
                      Re: Character Array vs String David Thompson <dave.thompson2@verizon.net> - 2012-01-19 02:43 -0500
          Re: Character Array vs String Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 07:48 -0800
            Re: Character Array vs String James Kuyper <jameskuyper@verizon.net> - 2011-11-09 11:06 -0500
              Re: Character Array vs String Willem <willem@toad.stack.nl> - 2011-11-09 16:24 +0000
                Re: Character Array vs String James Kuyper <jameskuyper@verizon.net> - 2011-11-09 11:30 -0500
                  Re: Character Array vs String "BartC" <bc@freeuk.com> - 2011-11-09 16:53 +0000
                  Re: Character Array vs String Willem <willem@toad.stack.nl> - 2011-11-09 17:05 +0000
                  Re: Character Array vs String Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 08:54 -0800
                    Re: Character Array vs String Tobias Blass <tobiasblass@gmx.net> - 2011-11-09 21:01 +0000
                      Re: Character Array vs String "BartC" <bc@freeuk.com> - 2011-11-09 21:26 +0000
                        Re: Character Array vs String Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-10 01:11 -0800
                          Re: Character Array vs String David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
                            Re: Character Array vs String Keith Thompson <kst-u@mib.org> - 2011-11-21 00:15 -0800
                    Re: Character Array vs String Keith Thompson <kst-u@mib.org> - 2011-11-09 14:06 -0800
                      Re: Character Array vs String Stephen Sprunk <stephen@sprunk.org> - 2011-11-09 19:32 -0600
                        Re: Character Array vs String Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 03:21 +0000
                          Re: Character Array vs String "BartC" <bc@freeuk.com> - 2011-11-10 11:00 +0000
                            Re: Character Array vs String Keith Thompson <kst-u@mib.org> - 2011-11-10 03:26 -0800
                            Re: Character Array vs String Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 12:04 +0000
                              Re: Character Array vs String Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-21 12:02 -0800
                                Re: Character Array vs String Kenneth Brody <kenbrody@spamcop.net> - 2011-11-23 11:42 -0500
                                  Re: Character Array vs String Uno <merrilljensen@q.com> - 2011-11-27 22:46 -0700
                                    Re: Character Array vs String Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-27 23:30 -0800
                                      Re: Character Array vs String Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-28 00:22 -0800
          Re: Character Array vs String Keith Thompson <kst-u@mib.org> - 2011-11-09 13:59 -0800
      Re: Character Array vs String James Kuyper <jameskuyper@verizon.net> - 2011-11-09 08:36 -0500
        Re: Character Array vs String Quentin Carbonneaux <qcarbonn@invalid.com> - 2011-11-09 14:06 +0000
      Re: Character Array vs String Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 05:38 -0800
      Re: Character Array vs String Keith Thompson <kst-u@mib.org> - 2011-11-09 13:52 -0800
    Re: Character Array vs String Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-09 07:39 -0500
    Re: Character Array vs String "BartC" <bc@freeuk.com> - 2011-11-09 13:51 +0000
    Re: Character Array vs String John Bode <jfbode1029@gmail.com> - 2011-11-23 19:32 -0800
      Re: Character Array vs String James Kuyper <jameskuyper@verizon.net> - 2011-11-24 11:49 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#13010

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.9049b181463c1e9cc0f2.20111110032150GMT.87liro1x2p.fsf@bsb.me.uk...
> Stephen Sprunk <stephen@sprunk.org> writes:
>
>> On 09-Nov-11 16:06, Keith Thompson wrote:
>>> The use of a two-character sequence to mark the end of a line is a
>>> concession to old hardware that needed separate commands to move the
>>> cursor to the beginning of the line and to advance to the next one.
>>> It's not necessary on current systems.
>>
>> AIUI, old teletypes needed the _time_ that it took to receive two
>> characters to do that combined action.  IOW, if only a single character
>> was used, the machine's output would fall further and further behind its
>> input with each line printed--and they didn't have much in the way of
>> buffers, so "real" characters would soon start getting lost.
>
> Some needed *more* time.  A logical newline was sometimes translated
> into \n\r\0\0\0\0\0\0\0\0\0.  If I'm not mistaken, some systems had to
> send more nulls after long lines than after short ones.

Didn't a teletype use any handshaking to indicate when it was ready for more 
data?

Each extra \0 took another 1/10 second to send (on an ASR33 anyway), 
accompanied by a lot of extra clatter. I think it would be noticed if it 
happened on every line!

> What the hardware needs is now, thankfully, kept entirely separate
> from what marks logical lines in input or output.

But CR and LF are sometimes still considered to be positioning codes, rather 
than logical separators. (Although Windows consoles seem to have dropped 
support for LF, so printf("abc%cdef",10); shows:

abc
def

instead of:

abc
   def

but printf("abc%cdef",13); does still display:

def

)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13013

"BartC" <bc@freeuk.com> writes:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
> news:0.9049b181463c1e9cc0f2.20111110032150GMT.87liro1x2p.fsf@bsb.me.uk...
[...]
>> Some needed *more* time.  A logical newline was sometimes translated
>> into \n\r\0\0\0\0\0\0\0\0\0.  If I'm not mistaken, some systems had to
>> send more nulls after long lines than after short ones.
>
> Didn't a teletype use any handshaking to indicate when it was ready for more 
> data?

Not necessarily.

> Each extra \0 took another 1/10 second to send (on an ASR33 anyway), 
> accompanied by a lot of extra clatter. I think it would be noticed if it 
> happened on every line!

Even today, the man page for the "stty" command has the following:

       * [-]ofdel
              use delete characters for fill instead of null characters

       * [-]ofill
              use fill (padding) characters instead of timing for delays

I seem to recall using systems where "stty" has a setting to control how
many null characters are transmitted after a carriage return, to allow
time for the cursor to reach the beginning of the line.

>> What the hardware needs is now, thankfully, kept entirely separate
>> from what marks logical lines in input or output.
>
> But CR and LF are sometimes still considered to be positioning codes, rather 
> than logical separators.

Yes, which is why I suggested that it would have made more sense to have
a *separate* logical separator.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13015

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.9049b181463c1e9cc0f2.20111110032150GMT.87liro1x2p.fsf@bsb.me.uk...
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>
>>> On 09-Nov-11 16:06, Keith Thompson wrote:
>>>> The use of a two-character sequence to mark the end of a line is a
>>>> concession to old hardware that needed separate commands to move the
>>>> cursor to the beginning of the line and to advance to the next one.
>>>> It's not necessary on current systems.
>>>
>>> AIUI, old teletypes needed the _time_ that it took to receive two
>>> characters to do that combined action.  IOW, if only a single character
>>> was used, the machine's output would fall further and further behind its
>>> input with each line printed--and they didn't have much in the way of
>>> buffers, so "real" characters would soon start getting lost.
>>
>> Some needed *more* time.  A logical newline was sometimes translated
>> into \n\r\0\0\0\0\0\0\0\0\0.  If I'm not mistaken, some systems had to
>> send more nulls after long lines than after short ones.
>
> Didn't a teletype use any handshaking to indicate when it was ready
> for more data?

In the case I am dimly remembering, data readiness was not the issue.
The interface could take more data and it would be printed wherever the
print head happened to be at the time.  I am sure this was regarded as
daft even then.

<snip>
>> What the hardware needs is now, thankfully, kept entirely separate
>> from what marks logical lines in input or output.
>
> But CR and LF are sometimes still considered to be positioning codes,
> rather than logical separators. (Although Windows consoles seem to
> have dropped support for LF, so printf("abc%cdef",10); shows:
>
> abc
> def
>
> instead of:
>
> abc
>   def

Your example is in C and in C the intent of printing '\n' to a display
device is to move "the active position to the initial position of the
next line".  This is tied in to C's adoption of '\n' as marking the end
of a line of text -- \n is a line end and the IO system must do what it
takes to make it so.

> but printf("abc%cdef",13); does still display:
>
> def

I'd write \r for portability and clarity but, yes, that is the common
behaviour and what the C standard intends: \r "[m]oves the active
position to the initial position of the current line".

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13731

On Nov 10, 7:04 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "BartC" <b...@freeuk.com> writes:
> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
> >news:0.9049b181463c1e9cc0f2.20111110032150GMT.87liro1x2p.fsf@bsb.me.uk...
> >> Stephen Sprunk <step...@sprunk.org> writes:
>
> >>> On 09-Nov-11 16:06, Keith Thompson wrote:
> >>>> The use of a two-character sequence to mark the end of a line is a
> >>>> concession to old hardware that needed separate commands to move the
> >>>> cursor to the beginning of the line and to advance to the next one.
> >>>> It's not necessary on current systems.
>
> >>> AIUI, old teletypes needed the _time_ that it took to receive two
> >>> characters to do that combined action.  IOW, if only a single character
> >>> was used, the machine's output would fall further and further behind its
> >>> input with each line printed--and they didn't have much in the way of
> >>> buffers, so "real" characters would soon start getting lost.
>
> >> Some needed *more* time.  A logical newline was sometimes translated
> >> into \n\r\0\0\0\0\0\0\0\0\0.  If I'm not mistaken, some systems had to
> >> send more nulls after long lines than after short ones.
>
> > Didn't a teletype use any handshaking to indicate when it was ready
> > for more data?
>
> In the case I am dimly remembering, data readiness was not the issue.
> The interface could take more data and it would be printed wherever the
> print head happened to be at the time.  I am sure this was regarded as
> daft even then.

Yes, teletypes (I'm thinking of the KSR33 and ASR33 models, here)
would print exactly what you sent them, regardless of where the print
head was at the time.

It was customary to send a CR followed by a LF (often followed by one
or more padding characters like NUL) so that the print head had time
to return to the left margin /before/ it received and printed the
first printable character of the next line. From the right margin, the
carriage took more than 1/10'th of a second to return to the left
margin, and sometimes took more than 2/10'ths of a second. Thus, while
the carriage was traveling left, the LF character (and, if necessary,
the follow-on NUL padding characters) gave the carriage that time it
needed.

The LF character on it's own was quite immediate; it never took the
entire 1/10'th second to complete.

[toc] | [prev] | [next] | [standalone]

#13822

On 11/21/2011 3:02 PM, Lew Pitcher wrote:
[...]
> Yes, teletypes (I'm thinking of the KSR33 and ASR33 models, here)
> would print exactly what you sent them, regardless of where the print
> head was at the time.
>
> It was customary to send a CR followed by a LF (often followed by one
> or more padding characters like NUL) so that the print head had time
> to return to the left margin /before/ it received and printed the
> first printable character of the next line. From the right margin, the
> carriage took more than 1/10'th of a second to return to the left
> margin, and sometimes took more than 2/10'ths of a second. Thus, while
> the carriage was traveling left, the LF character (and, if necessary,
> the follow-on NUL padding characters) gave the carriage that time it
> needed.
[...]

Yup.  I saw systems which didn't add some sort of delay-after-CR, and the 
printouts would include what was supposed to be the first character of the 
next line somewhere in the middle of the line.  (Sometimes between lines, as 
the LF hadn't yet fully advanced the paper.)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#13992

On 11/23/2011 9:42 AM, Kenneth Brody wrote:
> On 11/21/2011 3:02 PM, Lew Pitcher wrote:
> [...]
>> Yes, teletypes (I'm thinking of the KSR33 and ASR33 models, here)
>> would print exactly what you sent them, regardless of where the print
>> head was at the time.
>>
>> It was customary to send a CR followed by a LF (often followed by one
>> or more padding characters like NUL) so that the print head had time
>> to return to the left margin /before/ it received and printed the
>> first printable character of the next line. From the right margin, the
>> carriage took more than 1/10'th of a second to return to the left
>> margin, and sometimes took more than 2/10'ths of a second. Thus, while
>> the carriage was traveling left, the LF character (and, if necessary,
>> the follow-on NUL padding characters) gave the carriage that time it
>> needed.
> [...]
>
> Yup. I saw systems which didn't add some sort of delay-after-CR, and the
> printouts would include what was supposed to be the first character of
> the next line somewhere in the middle of the line. (Sometimes between
> lines, as the LF hadn't yet fully advanced the paper.)
>

Interesting.  Would I be "wrong" to think that 'teletype' might usually 
be abbreviated to 'tty'?
-- 
Uno

[toc] | [prev] | [next] | [standalone]

#13997

On Nov 28, 12:46 am, Uno <merrilljen...@q.com> wrote:
> On 11/23/2011 9:42 AM, Kenneth Brody wrote:
>
>
>
> > On 11/21/2011 3:02 PM, Lew Pitcher wrote:
> > [...]
> >> Yes, teletypes (I'm thinking of the KSR33 and ASR33 models, here)
> >> would print exactly what you sent them, regardless of where the print
> >> head was at the time.
[snip]
> Interesting.  Would I be "wrong" to think that 'teletype' might usually
> be abbreviated to 'tty'?

Not in the least. TeleType was the brand name, which was commonly
abbreviated to "TTY".

[toc] | [prev] | [next] | [standalone]

#14001

On Nov 28, 7:30 am, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> On Nov 28, 12:46 am, Uno <merrilljen...@q.com> wrote:
>
> > On 11/23/2011 9:42 AM, Kenneth Brody wrote:
>
> > > On 11/21/2011 3:02 PM, Lew Pitcher wrote:
> > > [...]
> > >> Yes, teletypes (I'm thinking of the KSR33 and ASR33 models, here)
> > >> would print exactly what you sent them, regardless of where the print
> > >> head was at the time.
> [snip]
> > Interesting.  Would I be "wrong" to think that 'teletype' might usually
> > be abbreviated to 'tty'?
>
> Not in the least. TeleType was the brand name, which was commonly
> abbreviated to "TTY".

well Teletype was like "hoover"- it was used generically.

[toc] | [prev] | [next] | [standalone]

#12989

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> CONTEXT!!
> Leave some in so we know what you are responding to.
>
> On Nov 9, 12:48 pm, 88888 Dihedral <dihedral88...@googlemail.com>
> wrote:
>
>> For unicode  support in C is documented in C99. In C89 the 8-bit ANSI char
>
> the character code you are trying to refer to is "ASCII" not "ANSI"

I doubt it.  He's probably trying to refer to the Windows-specific
character set that is usually incorrectly called "ANSI"
(even though it's never been the subject of any ANSI
standard).  It's more properlyi calledWindows-1252 or CP-1252
(<http://en.wikipedia.org/wiki/Windows-1252>).  It's an 8-bit
character set that's similar to ISO-8859-1 (Latin-1), except that
codes in the range 0x80 .. 0x9f are used for printable characters
rather than control characters.

In the Windows world, it's common to refer to this particular 8-bit
character set (or similar variants) as "ANSI", and to a 16-bit
representation (UTF-16 or UCS-2) as "Unicode", even though UTF-16 is
just one of several *representations* of Unicode.

ASCII is a 7-bit character set, not an 8-bit character set (ASCII
characters are typically represented as 8-bit bytes with the
high-order bit set to 0).  There are a number of 8-bit extensions
to ASCII.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#12961

On 11/09/2011 07:01 AM, Quentin Carbonneaux wrote:
> On 2011-11-09, Sheky <shekhar07.nitdgp@gmail.com> wrote:
>> Could anybody please mention difference between character array and
>> string in C?
> 
> To my knowledge, C does not have strings.

See 7.1.1p1, which I cited in my own response to Quentin.

C doesn't have a string type, but that's a very different question.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#12965

On 2011-11-09, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/09/2011 07:01 AM, Quentin Carbonneaux wrote:
>> On 2011-11-09, Sheky <shekhar07.nitdgp@gmail.com> wrote:
>>> Could anybody please mention difference between character array and
>>> string in C?
>> 
>> To my knowledge, C does not have strings.
>
> See 7.1.1p1, which I cited in my own response to Quentin.

I saw it.

> C doesn't have a string type, but that's a very different question.

My answer was a bit misleading... But, as you guessed it I tried to state that
C does not have a string type (I did not think of a string as a data structure,
which it is).

Thanks for making it clear.

-- 
qcar

[toc] | [prev] | [next] | [standalone]

#12962

On Nov 9, 2:01 pm, Quentin Carbonneaux <qcarb...@invalid.com> wrote:
> On 2011-11-09, Sheky <shekhar07.nit...@gmail.com> wrote:
>
> > Could anybody please mention difference between character array and
> > string in C?
>
> To my knowledge, C does not have strings.
>
It has syntactic support for strings, as string literals. It also has
functions in the standard library that operate on strings. What it
doesn't have is a string type variable. Strings are passed about as
character pointers.
--
MiniBasic - a simple Basic interpreter with good string support
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#12987

Quentin Carbonneaux <qcarbonn@invalid.com> writes:
> On 2011-11-09, Sheky <shekhar07.nitdgp@gmail.com> wrote:
>> Could anybody please mention difference between character array and
>> string in C?
>
> To my knowledge, C does not have strings.

Your knowledge is incomplete.  C doesn't have a string *type*, but it
does have strings, defined as "a contiguous sequence of characters
terminated by and including the first null character".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#12957

On 11/9/2011 6:09 AM, Sheky wrote:
> Could anybody please mention difference between character array and
> string in C?

     A character array is an array whose individual elements are
characters: `char this[42]', for example.  (The term "character"
is ambiguous, since C has four types that could claim the name:
`char', `signed char', `unsigned char', and `wchar_t'.  In informal
use "character" usually means `char', but be aware that the term
is not quite so specific and misunderstanding may occur.)  Anyhow:
A character array is an array of "character" elements, just as an
`int' array is an array of `int' elements.

     A string is a particular data structure that can be stored in
a character array.  It consists of some sequence of "payload"
characters plus a special "sentinel" character to mark the end of
the string.  The sentinel character has the numeric value zero, and
no payload character has that value.  It is possible to have no payload 
characters at all (the sentinel will be in the array's first position),
and this represents the empty string.  (Note: The terms "payload" and
"sentinel" are not formally defined by C; they're just my attempt to
name and explain the parts of a string.)

     Example:

	char message[10];
	strcpy(message, "Hello");

`message' is a character array: A ten-element array where each element
is a character.  After strcpy(), a string of six characters (five
payload and one sentinel) inhabits the first six positions of the
array.  The remaining four characters are still part of the array,
but are not part of the string.


          <---------------------- array ------------------------------>

           [0]   [1]   [2]   [3]   [4]   [5]   [6]   [7]   [8]   [9]
          +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
message: | 'H' | 'e' | 'l' | 'l' | 'o' |  0  |  ?  |  ?  |  ?  |  ?  |
          +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
                                          sen-
          <---------- payload ----------> ti-
                                          nel

          <------------- string ------------->

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#12964

"Sheky" <shekhar07.nitdgp@gmail.com> wrote in message 
news:bb3e536d-ddae-4dab-ab1c-bbb2967da95d@j36g2000prh.googlegroups.com...
> Could anybody please mention difference between character array and
> string in C?

As I understand it, a character array can contain a string, amongst other 
things.

So in a ten-character array, if the first three characters are 'A', 'B' and 
'C', and the fourth character is zero, then it contains the 3-character 
string "ABC" at the beginning (and the other 6 characters can contain 
anything).

But the more you look into this, the more complicated it gets (so that same 
array also contains the string "BC", and the last 5 characters form a 
5-character array, which may or may not contain a string of it's own, and so 
on). So don't worry about it too deeply.

-- 
Bartc
 

[toc] | [prev] | [next] | [standalone]

#13832

On Nov 9, 5:09 am, Sheky <shekhar07.nit...@gmail.com> wrote:
> Could anybody please mention difference between character array and
> string in C?

A string is a sequence of character values terminated by a 0.  This
sequence of character values may be stored in an array of type char.

[toc] | [prev] | [next] | [standalone]

#13860

On 11/23/2011 11:01 PM, Stefan Ram wrote:
> John Bode <jfbode1029@gmail.com> writes:
>> A string is a sequence of character values terminated by a 0.  This
> 
>   "of char values". "char" is not "character", "int" is not "integer",
>   and so on, you got it.

Section 7.1.1p1 says "character" not "char"; it also says "null
character" rather than "0". Strings are allowed to contain multibyte
characters.
-- 
James Kuyper

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web