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 1 of 3  [1] 2 3  Next page →

#12949 — Character Array vs String

Could anybody please mention difference between character array and
string in C?

[toc] | [next] | [standalone]

#12951

On Nov 9, 1:09 pm, Sheky <shekhar07.nit...@gmail.com> wrote:
> Could anybody please mention difference between character array and
> string in C?
>
There's not much difference. In C, a string is an array of characters
with a terminating 0, or null character.

There's special syntax for specifying a string, which is the
conventional quotes. "Fred" creates a constant character array, 5
characters long, with a terminal null. We call that a "strign
literal". char name[5] = {'F', 'r', 'e', 'd', '\0'}; does exactly the
same thing, but the array is writeable.

Occasionally you might need a character array without a terminating
null. This wouldn't be a string in C terms, and will probably cause a
crash if you feed it to a string function like strcpy(). Usually it's
better to put on the null even if you don't use it, because it's only
one byte, and it means you can print the string out with no trouble if
you need to do so for some reason. The other situation is where you
have several strings in the same array, with nulls between them. name
= e.g. char *name = "Fred\0Bloggs\0\0". A few Microsoft Windows
functions like to receive lists of strings like this. They use a
sequence of two nulls to indicate the end of the list.

--
Visit my website. Nice program to demonstrate entropy and the
hydrophobic effect.
http://www,malcolmmclean.site11.com/www

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

#12953

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

A character array is an array of objects of character type, either char,
signed char, unsigned char, or wchar_t. It remains an array, regardless
of what's stored in those objects.

A string is a data structure that could, among other things, be stored
in a character array. "A string is a contiguous sequence of characters
terminated by and including the first null character." (7.1.1p1).

Example:

char array[] = "One\0Two";

Every single character in that array can be treated as the first
character of a different string; most of those strings overlap each
other. For instance, array+3 points at the string "", which is empty
except for the terminating null character. array+5 points at the string
"wo",

-- 
James Kuyper

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

#12955

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.

-- 
qcar

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

#12958

For unicode  support in C is documented in C99. In C89 the 8-bit ANSI char string was assumed and the termination of a string  is a 0 stored in the of a string. 

In some encoding C-code compiled to deal with ANSI C string might fail. 
This was what I tested long time ago. 

In programming languages length of a string might be stored explicitly in 2 to 4 bytes. Be careful of the length of two bytes stored that will cause trouble.

I think that the wchar that could support unicode can enhance the PC platform over the unix-lynux platform that might  not support unicode in non-English users.   
 

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

#12966

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"

> string was assumed

no it wasn't. K&R (pre-standard C) may have done this (but I'm not
convinced even K&R was locked to ASCII). C89 went to a little trouble
to make it char set independent. No reason why a conforming C89
implementaions could not use EBCDIC (a rather nasty IBM character
code). And such things exist.

> and the termination of a string  is a 0 stored [at] the [end] of a string.

yes, the standard insists on this

> In some encoding C-code compiled to deal with ANSI C string might fail.

no. All conforming implementations must use zero to terminate a
string.
Badly written C programs might assume a particular character encoding.
But it isn't hard to write programs that are character encoding
neutral.

> This was what I tested long time ago.

anything that failed was either not a C compiler or your test progarm
was broken.

> In

--some--

> programming languages length of a string might be stored explicitly in 2 to 4 bytes. Be careful of the length of two bytes stored that will cause trouble.

Pascal did this typically. C++ std::string probably does it. There are
a zillion string libraries out there that do it. They will only cause
problems if you pass a non-C string to code taht is expecting a C-
string.

> I think that the wchar that could support unicode can enhance the PC platform over the unix-lynux platform that might  not support unicode in non-English users.

I'm pretty sure all main-stream OS's (Win, Linux, MacOS) support
unicode already.  Hence no enhancement necessary.

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

#12967

"Nick Keighley" wrote:

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"

Furthermore, ASCII is a 7-bit code, not 8.  It is usually extended in some 
fashion to become eight bits in actual use as opposed to an abstraction.
ANSI is the organization that "blesses" some stuff for the USA.

ANSI - American National Standards Institute.

ASCII - American Standard Code for Information Interchange. 

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

#13005

On Nov 9, 3:44 pm, "osmium" <r124c4u...@comcast.net> wrote:
> "Nick Keighley" wrote:
> On Nov 9, 12:48 pm, 88888 Dihedral <dihedral88...@googlemail.com>

> > For unicode support in C is documented in C99. In C89 the 8-bit ANSI char

your attributions are screwed I didn't write that

> >the character code you are trying to refer to is "ASCII" not "ANSI"
>
> Furthermore, ASCII is a 7-bit code, not 8.

I thought there was a parity bit?

> It is usually extended in some
> fashion to become eight bits in actual use as opposed to an abstraction.

ASCII wasn't "an abstraction", it was a widely used code. Those codes
using the top bit for data encoding aren't ASCII

<snip>

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

#13023

Nick Keighley wrote:

> On Nov 9, 3:44 pm, "osmium" <r124c4u...@comcast.net> wrote:
>> "Nick Keighley" wrote:
>> On Nov 9, 12:48 pm, 88888 Dihedral <dihedral88...@googlemail.com>
>
>>> For unicode support in C is documented in C99. In C89 the 8-bit
>>> ANSI char
>
> your attributions are screwed I didn't write that

Sorry about that.  I didn't notice you were using google to respond.  My 
email program considers google newsgroup responses as "broken" and I use a 
special program (this one) to respond to those messages.  But I just didn't 
notice that you were using google.

>>> the character code you are trying to refer to is "ASCII" not "ANSI"
>>
>> Furthermore, ASCII is a 7-bit code, not 8.
>
> I thought there was a parity bit?

We all have misinformation in our head.

>> It is usually extended in some
>> fashion to become eight bits in actual use as opposed to an
>> abstraction.
>
> ASCII wasn't "an abstraction", it was a widely used code. Those codes
> using the top bit for data encoding aren't ASCII

I used "abstraction" in the sense that I don't know of any place where pure, 
honest-to-god-ASCII is used.  The interchange hardware I know of, optical 
disks, tapes, external hard drives, are all based on 8-bit bytes.  I guess I 
would grudgingly  accept a code where the top bit was guaranteed to be zero 
or used for parity.  If you can provide a sample or three I would be very 
interested.  Perhaps there is an obscure code point in MS-DOS that you know 
of?

Clinton mode on.  I now note you say "was" rather than "is".  Where _was_ 
real ASCII used?  Was there perhaps a magnetic tape format for 7-bit code 
that two or more organizations agreed to use? 

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

#13028

On Nov 10, 2:56 pm, "osmium" <r124c4u...@comcast.net> wrote:
> Nick Keighley wrote:
> > On Nov 9, 3:44 pm, "osmium" <r124c4u...@comcast.net> wrote:

> >> [...] ASCII is a 7-bit code, not 8.
>
> > I thought there was a parity bit?
>
> We all have misinformation in our head.

from other posters I think the 7-bit stuff is correct. It may have
been transmitted with parity. Ah, wikipedia describes it as a 7-bit
code.

> >> It is usually extended in some
> >> fashion to become eight bits in actual use as opposed to an
> >> abstraction.
>
> > ASCII wasn't "an abstraction", it was a widely used code. Those codes
> > using the top bit for data encoding aren't ASCII
>
> I used "abstraction" in the sense that I don't know of any place where pure,
> honest-to-god-ASCII is used.

it won't be used on anything modern. But there's a lot of old stuff
around.

> The interchange hardware I know of, optical
> disks, tapes, external hard drives, are all based on 8-bit bytes.

think teleprinters and paper tapes.

> I guess I
> would grudgingly  accept a code where the top bit was guaranteed to be zero
> or used for parity.  If you can provide a sample or three I would be very
> interested.

old teleprinter and telex sytesm worked like this.

> Perhaps there is an obscure code point in MS-DOS that you know
> of?

oh, nothing as modern as a PC! Though I've seen PCs linked to such
legacy systems.

Consider:-
http://en.wikipedia.org/wiki/Aeronautical_Fixed_Telecommunication_Network

Parts of it are probably still runnign and using shitty telegraph
lines, because to upgrade would involve upgrading everyone at once.

> Clinton mode on.  I now note you say "was" rather than "is".  Where _was_
> real ASCII used?  Was there perhaps a magnetic tape format for 7-bit code
> that two or more organizations agreed to use?

ASCIII was designed for serial data exchange. Take a look at the codes
below 32. They don't code for playing card suits, line drawing or
obscure european letters- but for SOH and ETX and so on.

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

#13034

Nick Keighley wrote:
<sniüp>
> ASCIII was designed for serial data exchange. Take a look at the codes
> below 32. They don't code for playing card suits, line drawing or
> obscure european letters- but for SOH and ETX and so on.

Obscure European letters??? As opposed to an entirely useless $ sign 
(useless this side of the big pond at least), [], {} and @?

Bye, Jojo

PS: ;-) 

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

#13041

On 11/10/2011 12:34 PM, Joachim Schmitz wrote:
> Nick Keighley wrote:
> <sniüp>
>> ASCIII was designed for serial data exchange. Take a look at the codes
>> below 32. They don't code for playing card suits, line drawing or
>> obscure european letters- but for SOH and ETX and so on.
>
> Obscure European letters??? As opposed to an entirely useless $ sign
> (useless this side of the big pond at least), [], {} and @?

Well, given that the "A" in "ASCII" stands for "American", I think that 
"obscure European letters" is appropriate, as your side of the Big Pond is 
irrelevant.  :-)

> Bye, Jojo
>
> PS: ;-)

Noted.

-- 
Kenneth Brody

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

#13053

Kenneth Brody <kenbrody@spamcop.net> writes:

> On 11/10/2011 12:34 PM, Joachim Schmitz wrote:
>> Nick Keighley wrote:
>> <sniüp>
>>> ASCIII was designed for serial data exchange. Take a look at the codes
>>> below 32. They don't code for playing card suits, line drawing or
>>> obscure european letters- but for SOH and ETX and so on.
>>
>> Obscure European letters??? As opposed to an entirely useless $ sign
>> (useless this side of the big pond at least), [], {} and @?
>
> Well, given that the "A" in "ASCII" stands for "American", I think
> that "obscure European letters" is appropriate, as your side of the
> Big Pond is irrelevant.  :-)

Given that Spanish is moderately widely spoken in the US, it seems odd
(from this side of the Pond) that ñ, á, é, í, ó and ú are considered
to be either obscure or European :-)

-- 
Ben.

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

#13083

On Nov 10, 5:34 pm, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
> Nick Keighley wrote:
>
> <sniüp>
>
> > ASCIII was designed for serial data exchange. Take a look at the codes
> > below 32. They don't code for playing card suits, line drawing or
> > obscure european letters- but for SOH and ETX and so on.
>
> Obscure European letters??? As opposed to an entirely useless $ sign
> (useless this side of the big pond at least), [], {} and @?


how could we write perl if there were no $ sign? Some places reuse it
as an alternative currency sign.
:-)

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

#13033

"osmium" <r124c4u102@comcast.net> writes:

> Nick Keighley wrote:
>
>> On Nov 9, 3:44 pm, "osmium" <r124c4u...@comcast.net> wrote:
>>> Furthermore, ASCII is a 7-bit code, not 8.
>>
>> I thought there was a parity bit?
>
> We all have misinformation in our head.

ASCII was used with and without parity in various applications.
But though a parity bit may have been part of the protocol, 
typical usage of the term wouldn't refer to the parity as part 
of "coding," because it doesn't actually carry information.
-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

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

#13043

osmium <r124c4u102@comcast.net> wrote:
> 
> I used "abstraction" in the sense that I don't know of any place where pure, 
> honest-to-god-ASCII is used.  The interchange hardware I know of, optical 
> disks, tapes, external hard drives, are all based on 8-bit bytes.  I guess I 
> would grudgingly  accept a code where the top bit was guaranteed to be zero 
> or used for parity.  If you can provide a sample or three I would be very 
> interested.

Lots of serial devices (like genuine Teletypes) used 7-bit ASCII with
parity, as did most punched paper tape.
-- 
Larry Jones

I don't want to learn this!  It's completely irrelevant to my life! -- Calvin

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

#13050

lawrence.jones@siemens.com writes:
> osmium <r124c4u102@comcast.net> wrote:
>> I used "abstraction" in the sense that I don't know of any place
>> where pure, honest-to-god-ASCII is used.  The interchange hardware
>> I know of, optical disks, tapes, external hard drives, are all
>> based on 8-bit bytes.  I guess I would grudgingly  accept a code
>> where the top bit was guaranteed to be zero or used for parity.
>> If you can provide a sample or three I would be very interested.
>
> Lots of serial devices (like genuine Teletypes) used 7-bit ASCII with
> parity, as did most punched paper tape.

I remember reading about one system that used 7-bit ASCII in 8-bit bytes
with the high-order bit set to 1.  It made interoperability fun.

-- 
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]

#13086

lawrence.jones@siemens.com wrote:
> osmium <r124c4u102@comcast.net> wrote:
> > 
> > I used "abstraction" in the sense that I don't know of any place where pure, 
> > honest-to-god-ASCII is used.  The interchange hardware I know of, optical 
> > disks, tapes, external hard drives, are all based on 8-bit bytes.  I guess I 
> > would grudgingly  accept a code where the top bit was guaranteed to be zero 
> > or used for parity.  If you can provide a sample or three I would be very 
> > interested.

> Lots of serial devices (like genuine Teletypes) used 7-bit ASCII with
> parity, as did most punched paper tape.

As do lots of devices used in the lab today. They are con-
nected via the serial port (you often can set if parity is
to be used) andthere are still lots of them and even quite
a number of new devices still can be controlled via serial
port, although they normally also have a GPIB or USB con-
nector or are networked. Can be quite useful for debugging:
for USB, GPIB or network you typically need to write pro-
grams to talk to them, while with the serial interface you
plug them in, start a program like 'minicom' and then you
can directly communicate with the device by typing in com-
mands and see what's the reply.
                                 Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#13680

On Thu, 10 Nov 2011 08:56:11 -0600, "osmium" <r124c4u102@comcast.net>
wrote:

> Nick Keighley wrote:
> 
> > On Nov 9, 3:44 pm, "osmium" <r124c4u...@comcast.net> wrote:

> >> [ASCII] is usually extended in some
> >> fashion to become eight bits in actual use as opposed to an
> >> abstraction.
> >
> > ASCII wasn't "an abstraction", it was a widely used code. Those codes
> > using the top bit for data encoding aren't ASCII
> 
> I used "abstraction" in the sense that I don't know of any place where pure, 
> honest-to-god-ASCII is used.  The interchange hardware I know of, optical 
> disks, tapes, external hard drives, are all based on 8-bit bytes.  I guess I 
> would grudgingly  accept a code where the top bit was guaranteed to be zero 
> or used for parity.  If you can provide a sample or three I would be very 
> interested.  Perhaps there is an obscure code point in MS-DOS that you know 
> of?
> 
I would consider any 8-bit (or bigger) format of which a given 7-bits
is always ASCII to be using ASCII. E.g. ASCII + high bit 0, or 1, or
even parity, or odd, or flag, or even just out-of-band noise. 
8-bit codes where 0x00-7f are ASCII but 0x80-ff are something else,
like line-drawing or math or dingbats or European or Greek or Russian
or Arabic or ... are no longer ASCII, although they are related.

But to answer the exact question, DEC PDP-10 computers had a 36-bit
word with (few) special 'byte' instructions that could access *any*
number of bits within a word (and historically on a range of machines
bytes are not always 8 bits). Most software on 10's either divided
each word into 6 characters of 6-bits using the printable uppercase
subset of ASCII (i.e. columns 2 to 5), or into 5 characters of 7-bit
ASCII with 1 bit left over. (In those days nearly all terminals and
printers were uppercase-only anyway.) Some software did use 8-bit
bytes with 4 bits left, or 'spanned' 9 bytes of 8-bits over 2 words,
or had 4 bytes of 9-bits per word. I suppose some software may even
have done 7 bytes of 5-bits leaving 1 using Baudot/ITA2 or similar.

> Clinton mode on.  I now note you say "was" rather than "is".  Where _was_ 
> real ASCII used?  Was there perhaps a magnetic tape format for 7-bit code 
> that two or more organizations agreed to use? 
> 
Early IBM computers did have 7-track magtape, but used with IBM's
'BCDIC' 6-bit code plus parity (formally called Vertical Redundancy
Check). S/360 and later switched to 8-bit EBCDIC, on 9-track tape.

Technically it would have been possible for other (>=7-bit) equipment
to write 7-bit ASCII to 7-track tape with some escaping if necessary
to avoid NULs (because all 0-bits would screw up decode clocking).
But I never heard of anyone doing so. (There were standard formats for
ASCII on 9-track, including labels, but the overwhelming majority of
systems were IBM or wanted IBM compatibility and used EBCDIC.)

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

#13821

On 11/21/2011 2:39 AM, David Thompson wrote:
[...]
> But to answer the exact question, DEC PDP-10 computers had a 36-bit
> word with (few) special 'byte' instructions that could access *any*
> number of bits within a word (and historically on a range of machines
> bytes are not always 8 bits). Most software on 10's either divided
> each word into 6 characters of 6-bits using the printable uppercase
> subset of ASCII (i.e. columns 2 to 5), or into 5 characters of 7-bit
> ASCII with 1 bit left over. (In those days nearly all terminals and
> printers were uppercase-only anyway.) Some software did use 8-bit
> bytes with 4 bits left, or 'spanned' 9 bytes of 8-bits over 2 words,
> or had 4 bytes of 9-bits per word. I suppose some software may even
> have done 7 bytes of 5-bits leaving 1 using Baudot/ITA2 or similar.
[...]

While there were a few PDP-n's on campus as I recall, the main computer lab 
at the college I went to used a KL-10.  While I hadn't heard of C way back 
when, I did some assembly programming on it.

As you say, it had 36-bit words, and 18-bit addresses.  The O/S used six 
6-bit characters per word for filename, which IIRC were in 6.3 format.  (I 
guess they used the other 18 bits for file attributes?)  Text was typically 
stored as five 7-bit characters, with 1 bit padding.

Yet, although addresses were 18 bits wide, and each address pointed to a 
36-bit word, a "pointer" count, in fact, be wider than 18 bits.  For 
example, there were machine instructions for accessing sub-words, including 
things like "take the 7 bits at this address/bit-location, move it to the 
low-order 7 bits at this address, zero-padding it, and then increment the 
pointer by 7 bits".  (Of course, C requires at least 8 bits per char, so I 
guess it would use the same thing, but storing four 8-bit chars per word 
with 4 padding bits.  You could store four 9-bit chars w/o any padding, but 
files on disk were 8-bit characters, so it probably wouldn't make sense to 
do so.)

As I said, I never saw a C compiler for it, but I would suspect that 
sizeof() would be "interesting" on such a system.  The simplest system would 
be to simply store one 8-bit char per 36-bit word, but that seems rather 
inefficient.

-- 
Kenneth Brody

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web