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

#13823

"Kenneth Brody" <kenbrody@spamcop.net> wrote in message 
news:1c2dnbdXBN9MvFDTnZ2dnUVZ_i2dnZ2d@bestweb.net...
> 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*

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

'SIXBIT' format. Very handy, and probably also used for identifiers for 
compilers (so you were limited to rather short names, but string matching 
was very quick).

> 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" [could], in fact, be wider than 18 bits.  For

The address was 18-bits (for 256KWords of memory per task; just over 1MB!). 
But there was also an 'indirect' bit which could be used for repeated 
pointer operations, all automatic on any instruction. I believe another 
4-bits was an extra index register for each level of pointers.

> 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".

There were a dozen or so bits left over, which were used by byte-pointers, 
but these needed special instructions to make use of.

> (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.

I'd imagine C with it's various kinds of pointers would be a nightmare to 
implement, if packed char arrays were to be used. I remember using Pascal 
which offered a choice of unpacked (fast) or packed (slow) arrays, records 
and (presumably) strings.

-- 
Bartc 

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

#13825

On 2011-11-23, BartC <bc@freeuk.com> wrote:
> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message 
> news:1c2dnbdXBN9MvFDTnZ2dnUVZ_i2dnZ2d@bestweb.net...
>> 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*
>
>> 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,
>
> 'SIXBIT' format. Very handy, and probably also used for identifiers for 
> compilers (so you were limited to rather short names, but string matching 
> was very quick).

At that time, symbol interning had already been invented by the Lispers,
by which any length identifier is reduced to a one-word symbol atom thereafter
used in its place.

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

#13827

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

> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
> news:1c2dnbdXBN9MvFDTnZ2dnUVZ_i2dnZ2d@bestweb.net...
>> As you say, it had 36-bit words, and 18-bit addresses.  The O/S used
>> six 6-bit characters per word for filename,
>
> 'SIXBIT' format. Very handy, and probably also used for identifiers
> for compilers (so you were limited to rather short names, but string
> matching was very quick).

This idea was reincarnated, badly, in the "AML" language used by
ACPI, which has 32-bit identifiers that are limited to 4 8-bit
characters.
-- 
Ben Pfaff 
http://benpfaff.org

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

#13991

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

> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
> news:1c2dnbdXBN9MvFDTnZ2dnUVZ_i2dnZ2d@bestweb.net...
>> 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*
>
>> 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,
>
> 'SIXBIT' format. Very handy, and probably also used for identifiers
> for compilers (so you were limited to rather short names, but string
> matching was very quick).
>
>> 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" [could], in fact, be wider than 18
>> bits.  For
>
> The address was 18-bits (for 256KWords of memory per task; just over
> 1MB!). But there was also an 'indirect' bit which could be used for
> repeated pointer operations, all automatic on any instruction. I
> believe another 4-bits was an extra index register for each level of
> pointers.
>
>> 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".
>
> There were a dozen or so bits left over, which were used by
> byte-pointers, but these needed special instructions to make use of.
>
>> (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.
>
> I'd imagine C with it's various kinds of pointers would be a nightmare
> to implement, if packed char arrays were to be used. I remember using
> Pascal which offered a choice of unpacked (fast) or packed (slow)
> arrays, records and (presumably) strings.

There has been at least one C compiler for the PDP-10.  It uses four
9-bit chars per word.

The biggest model of PDP-10 supported extended addressing, with 23 bit
wide addresses.  That is word addresses, multiply by 4.5 to get the
capacity in 8-bit bytes.

-- Patrick

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

#15940

On Wed, 23 Nov 2011 17:15:27 -0000, "BartC" <bc@freeuk.com> wrote:

> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message 
> news:1c2dnbdXBN9MvFDTnZ2dnUVZ_i2dnZ2d@bestweb.net...
> > 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*
> 
> > 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.
> >
Not really -n. There were four implementations of PDP-10 by DEC (KA,
KI, KL, KS) and at least one competitive clone, plus PDP-6, with
basically the same instruction set. Other machines in the series were
(quite) different; PDP-5/8/12 and PDP-11 were the more widely used,
and unlike each other or PDP-6/10 or the other less-known PDP's.

> > As you say, it had 36-bit words, and 18-bit addresses.  The O/S used six 
> > 6-bit characters per word for filename,
> 
> 'SIXBIT' format. Very handy, and probably also used for identifiers for 
> compilers (so you were limited to rather short names, but string matching 
> was very quick).
> 
> > 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.
> >
TOPS-10 (DEC's initial OS) was 6.3 filenames, with one directory per
user (basically). TENEX, developed by BBN and adopted (more or less)
by DEC as TOPS-20, had variable-length filenames (plus version
numbers), in hierarchical directories with variable-length names. 

> > Yet, although addresses were 18 bits wide, and each address pointed to a 
> > 36-bit word, a "pointer" [could], in fact, be wider than 18 bits.  For
> 
> The address was 18-bits (for 256KWords of memory per task; just over 1MB!). 
> But there was also an 'indirect' bit which could be used for repeated 
> pointer operations, all automatic on any instruction. I believe another 
> 4-bits was an extra index register for each level of pointers.
> 
1-bits address plus 1-bit indirect and 4-bit _optional_ index, yes.
Directly in instruction, and indirect pointer in 'memory' if used.

'memory' in quotes because the 16 registers (usually called ACs) can
be accessed as the first 16 locations in memory also.

> > 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".
> 
> There were a dozen or so bits left over, which were used by byte-pointers, 
> but these needed special instructions to make use of.
> 
Exactly. Because byte-pointer needs those extra bits, _and_ because it
can be modified (incremented), it is only in 'memory'.

The special instructions are: load byte (any contiguous bits up to
wordsize) from memory to register, zero-padded, without or with
incrementing the pointer (but not to arbitrary location as BartC seems
to say); store register to byte in memory without or with incrementing
the pointer; increment or 'adjust' (multiple-increment) the pointer.

> > (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.)
> >
Files on disk were 36-bit words, and could have characters in any
format supported by software. 6x6 and 5x7 were most common in my
experience, although I think 4x8 and 9x8 were used for file exchange
with other systems (especially in ARPAnet and early Internet).

> > 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.
> 
Not really. C requires that any data type (any object) be accessible
as an array of unsigned char (e.g. for memcpy) so 4x9 seems to be 
the most reasonable choice. Although nowadays with Unicode finally
becoming really widespread, you could make an argument for 2x18 
(and use the halfword instructions to optimize some cases).

> I'd imagine C with it's various kinds of pointers would be a nightmare to 
> implement, if packed char arrays were to be used. I remember using Pascal 
> which offered a choice of unpacked (fast) or packed (slow) arrays, records 
> and (presumably) strings.

C's allowance of different pointer formats (size and representation)
to different target types works excellently here.

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

#12968

On Nov 9, 3:53 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
>
> 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.
>
Sometimes it's harder than it looks.

For instance IFF files have 4-letter ASCII tags which indicate what
sort of "chunk" you are reading. So the obvious thing to write is

fread(chunk, 1, 4, fp);
if(!strncmp(chunk, "DATA", 4))
  /* we've got a data chunk */

That will break on a non-ascii system. The solution is to hardcode the
values. But then you can no longer read the word "DATA" and it becomes
a lot harder to see that the chunk identifier is correct.

--
MiniBasic - a simple script interpreter
http://www.malcolmmclean.site11.com/www

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

#12969

On 11/09/2011 10:48 AM, Malcolm McLean wrote:
...
> For instance IFF files have 4-letter ASCII tags which indicate what
> sort of "chunk" you are reading. So the obvious thing to write is
> 
> fread(chunk, 1, 4, fp);
> if(!strncmp(chunk, "DATA", 4))
>   /* we've got a data chunk */
> 
> That will break on a non-ascii system. The solution is to hardcode the
> values. But then you can no longer read the word "DATA" and it becomes
> a lot harder to see that the chunk identifier is correct.

You can make it a macro, whose name is more informative than the
hardcoded values. However, the better solution (though not always
feasible) is to convert those files from ASCII to the native encoding on
that platform, as part of the process of porting them to that platform.
If a C implementation uses a non-ascii encoding when targeting that
platform, then it's likely to be the case that the local text oriented
utilities (such as file editors or browsers) will do so, as well.

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

#12971

James Kuyper wrote:
) On 11/09/2011 10:48 AM, Malcolm McLean wrote:
) ...
)> For instance IFF files have 4-letter ASCII tags which indicate what
)> sort of "chunk" you are reading. So the obvious thing to write is
)> 
)> fread(chunk, 1, 4, fp);
)> if(!strncmp(chunk, "DATA", 4))
)>   /* we've got a data chunk */
)> 
)> That will break on a non-ascii system. The solution is to hardcode the
)> values. But then you can no longer read the word "DATA" and it becomes
)> a lot harder to see that the chunk identifier is correct.
)
) You can make it a macro, whose name is more informative than the
) hardcoded values. However, the better solution (though not always
) feasible) is to convert those files from ASCII to the native encoding on
) that platform,

They are not ASCII files.  They are binary files with chunks that are
identified by a 4-byte header which has meaning when read as ASCII.


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

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

#12972

On 11/09/2011 11:24 AM, Willem wrote:
> James Kuyper wrote:
> ) On 11/09/2011 10:48 AM, Malcolm McLean wrote:
> ) ...
> )> For instance IFF files have 4-letter ASCII tags which indicate what
> )> sort of "chunk" you are reading. So the obvious thing to write is
> )> 
> )> fread(chunk, 1, 4, fp);
> )> if(!strncmp(chunk, "DATA", 4))
> )>   /* we've got a data chunk */
> )> 
> )> That will break on a non-ascii system. The solution is to hardcode the
> )> values. But then you can no longer read the word "DATA" and it becomes
> )> a lot harder to see that the chunk identifier is correct.
> )
> ) You can make it a macro, whose name is more informative than the
> ) hardcoded values. However, the better solution (though not always
> ) feasible) is to convert those files from ASCII to the native encoding on
> ) that platform,
> 
> They are not ASCII files.  They are binary files with chunks that are
> identified by a 4-byte header which has meaning when read as ASCII.

That makes it harder; the conversion utility would have to know about
the file format. It's still not impossible, but obviously far less
convenient.

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

#12973

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:4EBAAAAB.5080308@verizon.net...
> On 11/09/2011 11:24 AM, Willem wrote:
>> James Kuyper wrote:
>> ) On 11/09/2011 10:48 AM, Malcolm McLean wrote:
>> ) ...
>> )> For instance IFF files have 4-letter ASCII tags which indicate what
>> )> sort of "chunk" you are reading. So the obvious thing to write is
>> )>
>> )> fread(chunk, 1, 4, fp);
>> )> if(!strncmp(chunk, "DATA", 4))
>> )>   /* we've got a data chunk */
>> )>
>> )> That will break on a non-ascii system. The solution is to hardcode the
>> )> values. But then you can no longer read the word "DATA" and it becomes
>> )> a lot harder to see that the chunk identifier is correct.

>> They are not ASCII files.  They are binary files with chunks that are
>> identified by a 4-byte header which has meaning when read as ASCII.
>
> That makes it harder; the conversion utility would have to know about
> the file format. It's still not impossible, but obviously far less
> convenient.

You just use an a macro or function such as:

 if(!strncmp(chunk,ASCII("DATA"),4)

That's if you're worried that your program might not work on a non-ASCII C 
system. On an ASCII one, then the function or macro will do nothing.

-- 
Bartc
 

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

#12974

James Kuyper wrote:
) That makes it harder; the conversion utility would have to know about
) the file format. It's still not impossible, but obviously far less
) convenient.

And it would likely go against the spec of the file format.


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

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

#12978

On Nov 9, 6:30 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 11/09/2011 11:24 AM, Willem wrote:
>
> > They are not ASCII files.  They are binary files with chunks that are
> > identified by a 4-byte header which has meaning when read as ASCII.
>
> That makes it harder; the conversion utility would have to know about
> the file format. It's still not impossible, but obviously far less
> convenient.
>
It would be easy enough to write such a utility for IFF files, because
they have a  structure whereby you have a "chunk" length, and
identifier telling you what sort of chunk it is. So you can just skip
through all the chunks, changing the identifier tags from ASCII to
EBCDIC.

But then you'd have two file formats, identical except for the tags,
and the potential for extra costs and incompatibilities would be
large. A bit like the decision to encode newline/carriage return as
just a newline. It saved a byte, but to this day text files won't
display properly on Windows as a result.
--
MiniBasic - a fully functional Basic interpreter, written in ANSI C.
http://www.malcolmmclean.site11.com/www

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

#12980

On 2011-11-09, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Nov 9, 6:30 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 11/09/2011 11:24 AM, Willem wrote:
>>
>> > They are not ASCII files.  They are binary files with chunks that are
>> > identified by a 4-byte header which has meaning when read as ASCII.
>>
>> That makes it harder; the conversion utility would have to know about
>> the file format. It's still not impossible, but obviously far less
>> convenient.
>>
> It would be easy enough to write such a utility for IFF files, because
> they have a  structure whereby you have a "chunk" length, and
> identifier telling you what sort of chunk it is. So you can just skip
> through all the chunks, changing the identifier tags from ASCII to
> EBCDIC.
>

Wouldn't it be easier to use a text file, so the program checks for
"DATA" and you encode your file in EBDIC for EBDIC systems and in ASCII
for ASCII systems... (if you can't change the file format, well I liked
the function like macro idea elsewhere in this thread)
> But then you'd have two file formats, identical except for the tags,
> and the potential for extra costs and incompatibilities would be
> large. A bit like the decision to encode newline/carriage return as
> just a newline. It saved a byte, but to this day text files won't
> display properly on Windows as a result.

Well Windows developed after UNIX, so they could have adopted the \n
encoding if they wanted to. You could as well reverse your argument and
say "but to this day text files won't display properly on *NIX as a
result" (most *NIX utilities can handle \r\n encodings, though). I also
don't think \n was used to save a byte(CMIIW).  \n is more "natural" (you
want a newline, so you add a newline character), but \r\n is more natural
if you are used to typewriters. Since typewriters are quite rare these
days I think the *NIX way makes more sense, but YMMV.

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

#12982

"Tobias Blass" <tobiasblass@gmx.net> wrote in message
news:j9epne$12h$1@dont-email.me...
> On 2011-11-09, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

>> large. A bit like the decision to encode newline/carriage return as
>> just a newline. It saved a byte, but to this day text files won't
>> display properly on Windows as a result.
>
> Well Windows developed after UNIX, so they could have adopted the \n
> encoding if they wanted to. You could as well reverse your argument and
> say "but to this day text files won't display properly on *NIX as a
> result" (most *NIX utilities can handle \r\n encodings, though). I also
> don't think \n was used to save a byte(CMIIW).  \n is more "natural" (you
> want a newline, so you add a newline character), but \r\n is more natural
> if you are used to typewriters. Since typewriters are quite rare these
> days I think the *NIX way makes more sense, but YMMV.

Anyone who's used a teletype will know that both carriage return and
linefeed are usually necessary!

So it made sense to include both of those characters in text files, and this
was long before Windows.

On input of course, only one character is transmitted (when Return is
pressed), and the TTY software ensures it would be echoed as CR followed by 
LF. Perhaps Unix modelled the input sequence rather than output.

-- 
Bartc 

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

#13006

On Nov 9, 9:26 pm, "BartC" <b...@freeuk.com> wrote:
> "Tobias Blass" <tobiasbl...@gmx.net> wrote in message
> news:j9epne$12h$1@dont-ema.me...
> > On 2011-11-09, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:


> >> large. A bit like the decision to encode newline/carriage return as
> >> just a newline. It saved a byte, but to this day text files won't
> >> display properly on Windows as a result.
>
> > Well Windows developed after UNIX, so they could have adopted the \n
> > encoding if they wanted to. You could as well reverse your argument and
> > say "but to this day text files won't display properly on *NIX as a
> > result" (most *NIX utilities can handle \r\n encodings, though). I also
> > don't think \n was used to save a byte(CMIIW).  \n is more "natural" (you
> > want a newline, so you add a newline character), but \r\n is more natural
> > if you are used to typewriters. Since typewriters are quite rare these
> > days I think the *NIX way makes more sense, but YMMV.
>
> Anyone who's used a teletype will know that both carriage return and
> linefeed are usually necessary!

sometimes two carriage returns to give the teletype the time it needs
to do this

> So it made sense to include both of those characters in text files, and this
> was long before Windows.

yes but some terminals need \r\n some need \r\r\n and glass ttys don't
need both. The Unix decision to use a single logical end-of-line
character is the sane answer. The driver sorts out the display
problems.

I think I've seen \r used as a line terminator on DEC(?) machines.

> On input of course, only one character is transmitted (when Return is
> pressed), and the TTY software ensures it would be echoed as CR followed by
> LF. Perhaps Unix modelled the input sequence rather than output.

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

#13681

On Thu, 10 Nov 2011 01:11:26 -0800 (PST), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

> On Nov 9, 9:26 pm, "BartC" <b...@freeuk.com> wrote:
> > "Tobias Blass" <tobiasbl...@gmx.net> wrote in message
> > news:j9epne$12h$1@dont-ema.me...
> > > On 2011-11-09, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
<snip: Windows CRLF vs Unix \n>

> > Anyone who's used a teletype will know that both carriage return and
> > linefeed are usually necessary!
> 
> sometimes two carriage returns to give the teletype the time it needs
> to do this
> 
Or other padding, as discussed nearby. A person punching tape would
find CR easiest to use, but automation mostly used NUL or DEL. 

To answer another question nearby, real Teletypes did not have flow
control, although they had an (extra cost) option to stop and start
the *Teletype* reading paper tape, which could be used by a receiving
computer or other automated equipment to slow that input (only).
Some other terminals, especially some video terminals (next), did
extend these characters (DC1 aka XON, DC3 aka XOFF) for flow control
from the computer or similar sender, but because of roundtrip delay
this only works if the terminal has at least some buffering (about 2-4
characters) and Teletypes didn't. And some terminal modems of the day
were half-duplex (doesn't allow back traffic) or even if they were
nominally full-duplex didn't always reliably work that way.

> > So it made sense to include both of those characters in text files, and this
> > was long before Windows.
> 
> yes but some terminals need \r\n some need \r\r\n and glass ttys don't
> need both. The Unix decision to use a single logical end-of-line

Video terminals aka glass TTYs varied widely. Some used CR LF
separate, some had CR do LF, some had LF do CR, some had switch or
jumper or even PROM options. Some needed padding, some  didn't -- some
early ones even needed *more* padding than mechanical TTYs!

> character is the sane answer. The driver sorts out the display
> problems.
> 
Exactly.

> I think I've seen \r used as a line terminator on DEC(?) machines.
> 
I assume you mean storage, since most systems used lone CR input.

Apple MacOS (at least classic) stored CR (reverse from what Keith (no
relation!) said nearby). I don't know any DEC *software* that did;
most used CR LF and some used counts or reassigned meanings within a
6-bit code. Much DEC *hardware* ran Unix and stored \n=LF.

> > On input of course, only one character is transmitted (when Return is
> > pressed), and the TTY software ensures it would be echoed as CR followed by
> > LF. Perhaps Unix modelled the input sequence rather than output.

Kind of, except \n was and still canonically is ASCII LF not CR.

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

#13684

David Thompson <dave.thompson2@verizon.net> writes:
[...]
> Apple MacOS (at least classic) stored CR (reverse from what Keith (no
> relation!) said nearby).

Actually, I think that is what I said:

| But we're stuck with the current situation.  MacOS managed to change
| its end-of-line marker from CR to LF, but I don't know if Windows
| could (or would) to do the same thing.

[...]
> Kind of, except \n was and still canonically is ASCII LF not CR.

The C standard doesn't actually require \n to be LF (it doesn't even
mention ASCII outside a couple of footnotes).  \n probably couldn't be
CR, since that's \r (presumably '\n' == '\r' would be non-conforming).
But in EBCDIC \n could plausibly be NL, which is distinct from both CR
and LF.

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

#12991

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> But then you'd have two file formats, identical except for the tags,
> and the potential for extra costs and incompatibilities would be
> large. A bit like the decision to encode newline/carriage return as
> just a newline. It saved a byte, but to this day text files won't
> display properly on Windows as a result.

IMHO it would have been far better to define a single character that
marks the end of a line in a text file.  In an ASCII-like encoding, for
example, you might keep the existing CR and LF characters (CR specifies
moving the cursor to the beginning of the current line, LF specifies
moving it down to the next line) and add a NL character that's
specifically for use in text files.  (EBCDIC has distinct CR, LF, and NL
characters; I don't know if they're used this way.)

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.

But we're stuck with the current situation.  MacOS managed to change
its end-of-line marker from CR to LF, but I don't know if Windows
could (or would) to do the same thing.

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

#12995

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.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#13001

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.

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

-- 
Ben.

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

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

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

csiph-web