468,490 Members | 2,555 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,490 developers. It's quick & easy.

Is Chris Hills a troll?

Or, just how low has this group sunk?

Twice in the past couple of days, Default Loser has accused Chris Hills,
member of the ISO C committee, of being a troll (though given that the
former's only "contributions" to this group are "don't top post" and
"plonk" posts, perhaps his opinions shouldn't be given *too* much
weight...)

But Jack Klein, too, has said the same thing in ever-so-slightly more
guarded language. And Heathfield has been hinting at it too in recent
weeks.

So has it really come to this? Is this really the growing consensus of
the regulars?

If so, perhaps they should do a little soul-searching and ask who the
real trolls are. And what the hell their little game is really all
about.

Jan 17 '08
198 4517
On Thu, 24 Jan 2008 14:29:04 -0600, Chris Hills wrote
(in article <Ym**************@phaedsys.demon.co.uk>):
In article
<eb**********************************@1g2000hsl.go oglegroups.com>,
user923005 <dc*****@connx.comwrites
>On Jan 24, 3:26*am, Richard Heathfield <r...@see.sig.invalidwrote:
>>Chris Hills said:

<snip>

OK... Do we want to start a list of things to drop from the next ISO C.

All the C99 additions can go (see elsethread for my very short list of
exceptions).

Whether you use them or not, what conceivable harm is created by their
inclusion? This seems a very strange statement to me.

Because then tools have to include them to be compliant.
>If the
additions made C99 incompatible with C90, then I can imagine some
cause for complaint. If there were (for instance) 10,000 math
functions added to the math library, I do not see how it could cause
any difficulties unless you intended to use them.

Because library writers and compiler companies would have to include
them.
>Here is what I think C is missing {including both C90 & C99} (above
all else):
Complete, thorough Unicode handling.

Not sure on that one. Most of us don't need unicode.
Its lack is a major reason people pick other languages for writing apps
that need to work world-wide. The reason "us" don't need it, is that
we're the ones left. That said, C's primary purpose is device drivers,
system internals and embedded (there's my bias speaking), so unicode is
a don't care. I'm don't see any reason for C to try and compete for
attention amongst higher level GUI developers at this late stage.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 24 '08 #101
Randy Howard wrote:
Malcolm McLean wrote
.... snip ...
>
>strtok() - someone think of a safer toekising replacement.

It's "safe", it just isn't described well enough for a novice to
understand the issues, many of which are around code using
extensions not in standard C, like threads. A better one would
be well-received though.
A replacement can easily be written, but there is no real point in
including it in the standard library. There is no real reason for
including things that can be done efficiently in standard ISO C.
Meanwhile, strtok is there. Leave it alone.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com

Jan 25 '08 #102
"CBFalconer" <cb********@yahoo.comwrote in message
Randy Howard wrote:
>Malcolm McLean wrote
... snip ...
>>
>>strtok() - someone think of a safer toekising replacement.

It's "safe", it just isn't described well enough for a novice to
understand the issues, many of which are around code using
extensions not in standard C, like threads. A better one would
be well-received though.

A replacement can easily be written, but there is no real point in
including it in the standard library. There is no real reason for
including things that can be done efficiently in standard ISO C.
Meanwhile, strtok is there. Leave it alone.
Except things like strcpy(), which are so frequently used it woud be a
nuisance to have to roll your own.
If we are going down the core / extension route, there should also be a
standard 3D library with dot products and matrix operations. it's never a bg
deal, but constantly code needs rewriting to transpose matrices, or use 4x3s
instead of 4x4s, and so on.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jan 25 '08 #103
Chris Hills <ch***@phaedsys.orgwrote:
user923005 <dc*****@connx.comwrites
Here is what I think C is missing {including both C90 & C99} (above
all else):
Complete, thorough Unicode handling.

Not sure on that one. Most of us don't need unicode.
....wrote the Anglophone.

Richard
Jan 25 '08 #104
Malcolm McLean wrote:

<snip>
If we are going down the core / extension route, there should also be
a standard 3D library with dot products and matrix operations. it's
never a bg deal, but constantly code needs rewriting to transpose
matrices, or use 4x3s instead of 4x4s, and so on.
Have you considered C++? It has a much vaster Standard library, not to
mention things like Boost. Do you really need your software to run on
everthing from ICs to supercomputers?

Jan 25 '08 #105
In article
<05**********************************@f10g2000hsf. googlegroups.com>,
user923005 <dc*****@connx.comwrites
>On Jan 24, 12:29*pm, Chris Hills <ch...@phaedsys.orgwrote:
>Here is what I think C is missing {including both C90 & C99} (above
all else):
Complete, thorough Unicode handling.

Not sure on that one. Most of us don't need unicode.

That is hard for me to fathom, unless you deal mainly in toaster ICs.
Most of the world needs Unicode, because so many character sets cannot
be represented in 8 bits. Can you imagine a successful large database
that lacks Unicode? It would never fly.
The vast majority of systems programed in c don't have a screen.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #106
On Fri, 25 Jan 2008 00:31:08 -0600, Malcolm McLean wrote
(in article <jZ******************************@bt.com>):
"CBFalconer" <cb********@yahoo.comwrote in message
>Randy Howard wrote:
>>Malcolm McLean wrote
... snip ...
>>>
strtok() - someone think of a safer toekising replacement.

It's "safe", it just isn't described well enough for a novice to
understand the issues, many of which are around code using
extensions not in standard C, like threads. A better one would
be well-received though.

A replacement can easily be written, but there is no real point in
including it in the standard library. There is no real reason for
including things that can be done efficiently in standard ISO C.
Meanwhile, strtok is there. Leave it alone.
Except things like strcpy(), which are so frequently used it woud be a
nuisance to have to roll your own.
This doesn't even make sense. Why would it be a "nuisance" to roll
your own for a frequently used, simple function? You "roll" it once,
and use it forever.
If we are going down the core / extension route, there should also be a
standard 3D library with dot products and matrix operations. it's never a bg
deal, but constantly code needs rewriting to transpose matrices, or use 4x3s
instead of 4x4s, and so on.
It does?

How about this... don't try and turn the C standard lib into STL.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 25 '08 #107
Chris Hills said:
In article
<05**********************************@f10g2000hsf. googlegroups.com>,
user923005 <dc*****@connx.comwrites
>>On Jan 24, 12:29 pm, Chris Hills <ch...@phaedsys.orgwrote:
>>Here is what I think C is missing {including both C90 & C99} (above
all else):
Complete, thorough Unicode handling.

Not sure on that one. Most of us don't need unicode.

That is hard for me to fathom, unless you deal mainly in toaster ICs.
Most of the world needs Unicode, because so many character sets cannot
be represented in 8 bits. Can you imagine a successful large database
that lacks Unicode? It would never fly.

The vast majority of systems programed in c don't have a screen.
(a) I find that surprising, and would appreciate some independent
verification if possible;
(b) The lack of a screen does not mean the lack of a need for Unicode (or
some other character set that can cope with a great many international
alphabets).
(c) Many people who do not themselves program in C are not averse to
linking to libraries to gain access to existing functionality rather than
write it themselves. Many languages provide facilities for linking to C
libraries, and the number of C libraries out there is truly colossal. Any
C library that supports Unicode is very likely to be considerably more
popular than an otherwise equivalent library that does not.

Admission of hypocrisy coming up: I have myself only needed Unicode on two
or three occasions.

So - does C need to support Unicode? Well, C *already* provides support for
any character set the implementation wants to use, subject only to some
very minimal constraints that Unicode easily meets.

So it's a non-issue, really.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 25 '08 #108
In article <aq******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Chris Hills said:
>In article
<05**********************************@f10g2000hsf .googlegroups.com>,
user923005 <dc*****@connx.comwrites
>>>On Jan 24, 12:29 pm, Chris Hills <ch...@phaedsys.orgwrote:

Here is what I think C is missing {including both C90 & C99} (above
all else):
Complete, thorough Unicode handling.

Not sure on that one. Most of us don't need unicode.

That is hard for me to fathom, unless you deal mainly in toaster ICs.
Most of the world needs Unicode, because so many character sets cannot
be represented in 8 bits. Can you imagine a successful large database
that lacks Unicode? It would never fly.

The vast majority of systems programed in c don't have a screen.

(a) I find that surprising, and would appreciate some independent
verification if possible;
The vast majority of C is for drivers and embedded systems.

I think 2 million lines of C in the average car across 150 MCU's In
fact anything with electrical power near it has an embedded system in it
somewhere using C

BTW the majority of MCU out there are still 8 bit systems that don't
want unuicode.
>(b) The lack of a screen does not mean the lack of a need for Unicode (or
some other character set that can cope with a great many international
alphabets).
True
>(c) Many people who do not themselves program in C are not averse to
linking to libraries to gain access to existing functionality rather than
write it themselves.
So we are now responsible for supporting other languages?
Let them do their own libraries
>Many languages provide facilities for linking to C
libraries, and the number of C libraries out there is truly colossal. Any
C library that supports Unicode is very likely to be considerably more
popular than an otherwise equivalent library that does not.
But there is no need to have it in the standard.

This is the problem with C99 a lot of crap that a few wanted was put in
so the majority did not bother hence virtually no C99 compilers.

Adding Unicode means large numbers of compilers will not bother becoming
ISO-C compliant and you have even fewer people using ISO-C at which
point it becomes a non-issue as Standard C becomes more irrelevant than
it is now.

The Standard needs to move back to the majority user base.
>Admission of hypocrisy coming up: I have myself only needed Unicode on two
or three occasions.
Not needed it at all yet. Though I know others who do.. Hiowever because
a few do does not mean it should go in the standard.
>So - does C need to support Unicode? Well, C *already* provides support for
any character set the implementation wants to use, subject only to some
very minimal constraints that Unicode easily meets.
So it's a non-issue, really.
Yes.. But don't explicitly make it part of the standard or the standard
will be used less than now.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #109
Richard Heathfield wrote:
So - does C need to support Unicode? Well, C *already* provides support for
any character set the implementation wants to use, subject only to some
very minimal constraints that Unicode easily meets.

So it's a non-issue, really.
Does it really? I speak from ignorance here, so questions in the
following text are genuine requests for information rather than
rhetorical devices:

I see from n1256 that C has support for multibyte characters, which I
wasn't previously aware of, which means that both the source and
execution character set can be UTF-8 or UTF-16.

But I was under the impression that the library support isn't there.
However, reading n1256 reveals the following:

"The strncpy function copies not more than n characters"
"The strncat function appends not more than n characters"
"The strncmp function compares not more than n characters"
"The strlen function returns the number of characters that precede the
terminating null character."

Does this mean that if I declare a char array:

char mystr[] = "abcd$";
/* $ may be a multibyte character; the string contains 5 characters not
including \0 */

then the expression sizeof mystr == strlen(mystr)+1 is not guaranteed,
because sizeof counts bytes and strlen counts characters?

Or is it the case (as I previously thought) that strlen() counts bytes
rather than characters?

My reading of n1256 indicates that the former must be the case, because
the definition of "character" explicitly includes multibyte characters,
and the definition of strlen() explicitly counts characters rather than
bytes.

Am I correct on this? If so, I have learned something today.
Jan 25 '08 #110
Philip Potter said:
Richard Heathfield wrote:
>So - does C need to support Unicode? Well, C *already* provides support
for any character set the implementation wants to use, subject only to
some very minimal constraints that Unicode easily meets.

So it's a non-issue, really.

Does it really?
Kinda sorta. I admit to being a little bit disingenuous (but not incorrect)
here. Implementations are free to set CHAR_BIT to 32, in which case a char
can hold any Unicode character you like.

Moving on...
I see from n1256 that C has support for multibyte characters, which I
wasn't previously aware of, which means that both the source and
execution character set can be UTF-8 or UTF-16.
So does C89 (see 2.2.1.2).
But I was under the impression that the library support isn't there.
If you have really wide chars, you can just use the vanilla support. If you
rely on multibyte characters, you're right - the library support is
somewhat lacking (although C99 did try to address this somewhat).
However, reading n1256 reveals the following:

"The strncpy function copies not more than n characters"
"The strncat function appends not more than n characters"
"The strncmp function compares not more than n characters"
"The strlen function returns the number of characters that precede the
terminating null character."

Does this mean that if I declare a char array:

char mystr[] = "abcd$";
/* $ may be a multibyte character; the string contains 5 characters not
including \0 */

then the expression sizeof mystr == strlen(mystr)+1 is not guaranteed,
because sizeof counts bytes and strlen counts characters?

Or is it the case (as I previously thought) that strlen() counts bytes
rather than characters?
They are equivalent statements. One character occupies one byte, by
definition.
4.1.1: "A string is a contiguous sequence of characters terminated by and
including the first null character. It is represented by a pointer to
its initial (lowest addressed) character and its length is the number
of characters preceding the null character."

4.11.6.3: "The strlen function computes the length of the string pointed to
by s. [...] The strlen function returns the number of characters that
precede the terminating null character."
My reading of n1256 indicates that the former must be the case, because
the definition of "character" explicitly includes multibyte characters,
The ANSI C definition of "character" explicitly requires a character to be
a single byte: " * Character --- a single byte representing a member of
the basic character set of either the source or the execution
environment." Whilst it is true that a multibyte character can occupy a
single byte, it is not true that a character can occupy more than one
byte.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 25 '08 #111
Richard Heathfield said:

<snip>
The ANSI C definition of "character" explicitly requires a character to
be a single byte: " * Character --- a single byte representing a member
of the basic character set of either the source or the execution
environment."
Sorry, I posted a bit quick there. I meant to add that they couldn't have
changed this in C99 without breaking everything.

Well, then I looked. And they /have/ changed it, and they /have/ broken
everything. C99 has *two* definitions of "character". Here is the first:

character: "abstract member of a set of elements used for the organization,
control, or representation of data" - which means that just about anything
is a character, including functions!

Here is the second:

character:
single-byte character
C bit representation that fits in a byte

So it seems that C99 has managed to muddy the waters. I'm not sure what
conclusion to draw here, or what the consequences are. What I am sure of
is that it's probably just as well there are hardly any C99
implementations.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 25 '08 #112
In article <47*****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
>Not sure on that one. Most of us don't need unicode.
>...wrote the Anglophone.
Speakers of most other languages don't need Unicode either. Unicode
is most useful when you are trying to support multiple languages;
there's nothing special about English in this respect.

(And of course, it may well be that most C programmers are Anglophones.)

-- Richard

--
:wq
Jan 25 '08 #113
In article <Vc******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Here is the second:

character:
single-byte character
C bit representation that fits in a byte
What is the definition of a byte?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #114
In article <47*****************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
>Chris Hills <ch***@phaedsys.orgwrote:
>user923005 <dc*****@connx.comwrites
>Here is what I think C is missing {including both C90 & C99} (above
all else):
Complete, thorough Unicode handling.

Not sure on that one. Most of us don't need unicode.

...wrote the Anglophone.
Not at all. Many systems don't need string or text output of any kind.
Also they can use any 8 bit character set they like.... there are a fair
few of them about.

We used 8 bit character sets when I programed in Germany..... also with
Italians.

This is where C99 went wrong... things were put in because they were
useful for a small community. Thus compilers for that community were
happy but no one else bothered to implement. Do that a few times and
whilst everyone implements the same subset no one implements the whole
standard.

Ergo no fully complaint tools and the standard falls into darkness.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #115
Chris Hills said:
In article <Vc******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>Here is the second:

character:
single-byte character
C bit representation that fits in a byte

What is the definition of a byte?
What must I deduce from this question? Either that you don't know, or that
you think I don't know, or that you're trying to make some obscure point.

Since you're on the ISO C Committee, I must presume that you know how
"byte" is defined.

Since I've cited the Standard a great many times, you must surely know
that, even if I didn't know, I could look it up (it's actually 3.6(1) in
C99).

So I can only deduce that you're trying to make some obscure point. But I
can't imagine what it is. May I suggest, therefore, that you make your
obscure point somewhat less obscure?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 25 '08 #116
Richard Heathfield wrote:
Richard Heathfield said:

<snip>
>The ANSI C definition of "character" explicitly requires a character to
be a single byte: " * Character --- a single byte representing a member
of the basic character set of either the source or the execution
environment."

Sorry, I posted a bit quick there. I meant to add that they couldn't have
changed this in C99 without breaking everything.

Well, then I looked. And they /have/ changed it, and they /have/ broken
everything. C99 has *two* definitions of "character". Here is the first:

character: "abstract member of a set of elements used for the organization,
control, or representation of data" - which means that just about anything
is a character, including functions!

Here is the second:

character:
single-byte character
C bit representation that fits in a byte

So it seems that C99 has managed to muddy the waters. I'm not sure what
conclusion to draw here, or what the consequences are. What I am sure of
is that it's probably just as well there are hardly any C99
implementations.
I would argue that C89 had pretty muddy waters to begin with, if, as you
say, a character is by definition single-byte and therefore a multi-byte
character is not a character[1]. Presumably this means that a multibyte
character consisting of two bytes also consists of two characters of one
byte each? If it does not, then the definition of strlen cannot possibly
work on a string containing multi-byte characters, because the string is
not a sequence of characters (which are, by definition, single-byte
characters).

Here is something else which muddies the waters (from n1256, 7.1.1p1):

"A string is a contiguous sequence of characters terminated by and
including the first null character. The term multibyte string is
sometimes used instead to emphasize special processing given to
multibyte characters contained in the string or to avoid confusion with
a wide string."

This terminology suggests that a multibyte string is a string, and
therefore a string (which is a contiguous sequence of characters (which
are by definition single-byte)) can contain multibyte characters. But
although a multibyte string is a string, a multibyte character is not a
character!

Can we presume from all this that '\x80' is a character even if it does
not represent a character in the character set, because it forms a
prefix for a multibyte character and changes shift state?

I find it all mind-boggling!

Phil

[1] Though it would have been better for C99 to maintain the status quo
than to make the definitions more confusing!
Jan 25 '08 #117
In article <36******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Chris Hills said:
>In article <Vc******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>>Here is the second:

character:
single-byte character
C bit representation that fits in a byte

What is the definition of a byte?

What must I deduce from this question? Either that you don't know, or that
you think I don't know, or that you're trying to make some obscure point.

Since you're on the ISO C Committee, I must presume that you know how
"byte" is defined.

Since I've cited the Standard a great many times, you must surely know
that, even if I didn't know, I could look it up (it's actually 3.6(1) in
C99).

So I can only deduce that you're trying to make some obscure point. But I
can't imagine what it is. May I suggest, therefore, that you make your
obscure point somewhat less obscure?
Another long post without shedding any light... You and CBF are getting
good at that.

I do know the "definition". That is part of the underlying problem
You are specifying the sizes of characters against a variable.
In fact I think it is recursive... :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #118
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>On Wed, 23 Jan 2008 21:44:43 -0600, CBFalconer wrote
(in article <47***************@yahoo.com>):
>Randy Howard wrote:
>>Richard Heathfield wrote
... snip ...
>>>
So much for compatibility with C90. :-)

Doesn't take a crystal ball to predict that most people will
still be writing basically C89 with minor additions in 2050.

Defining 'most' as including me, wanna bet?

Well, several of us, likely including me, won't be alive that far out.
;-)
I thought about that.... 42 years... It's possible but I can't imagine I
will care. I would be 90.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #119
In article <m3************@Claudio.Messina>, Mark L Pappin <ml*@acm.org>
writes
>Chris Hills <ch***@phaedsys.orgwrites:
>Keith Thompson <ks***@mib.orgwrites
>>Chris Hills <ch***@phaedsys.orgwrites:
comp.std.c is for discussion of standard C
>>No, comp.std.c is for discussion of the C standard.
Which it seems is all you want to do. Standard C

Just in case you are in fact dense and not merely trolling, Chris,
here's the distinction you seem to be missing:
No to both however the following
>The {standard C language} is not the same thing as
the {C language standard}
(even though the two phrases are made of the same words).

The first is what a programmer writes;
the second is what the Committee writes.
comp.lang.c is a place for discussion of the first,
comp.std.c is a place for discussion of the second.
Those things that might appear in a "Real World C" program but are not
defined by any {C language standard} should be discussed elsewhere.
Is a definition that many do not hold with. It is your definition.

I could say
>Just in case you are in fact dense and not merely trolling, Chris,
here's the distinction you seem to be missing:

C.l.c is for discussing C as it is used and c.std.c for Standard C....
there are as many people if not more who would agree with that.

Your definition is no more valid than mine,.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #120
In article <fn**********@registered.motzarella.org>, santosh
<sa*********@gmail.comwrites
>Malcolm McLean wrote:

<snip>
>If we are going down the core / extension route, there should also be
a standard 3D library with dot products and matrix operations. it's
never a bg deal, but constantly code needs rewriting to transpose
matrices, or use 4x3s instead of 4x4s, and so on.

Have you considered C++? It has a much vaster Standard library, not to
mention things like Boost. Do you really need your software to run on
everthing from ICs to supercomputers?
From IC's upwards... certainly 8-32 bit systems

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #121
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>On Fri, 25 Jan 2008 00:31:08 -0600, Malcolm McLean wrote
(in article <jZ******************************@bt.com>):
>"CBFalconer" <cb********@yahoo.comwrote in message
>>Randy Howard wrote:
Malcolm McLean wrote

... snip ...

strtok() - someone think of a safer toekising replacement.

It's "safe", it just isn't described well enough for a novice to
understand the issues, many of which are around code using
extensions not in standard C, like threads. A better one would
be well-received though.

A replacement can easily be written, but there is no real point in
including it in the standard library. There is no real reason for
including things that can be done efficiently in standard ISO C.
Meanwhile, strtok is there. Leave it alone.
Except things like strcpy(), which are so frequently used it woud be a
nuisance to have to roll your own.

This doesn't even make sense. Why would it be a "nuisance" to roll
your own for a frequently used, simple function? You "roll" it once,
and use it forever.
>If we are going down the core / extension route, there should also be a
standard 3D library with dot products and matrix operations. it's never a bg
deal, but constantly code needs rewriting to transpose matrices, or use 4x3s
instead of 4x4s, and so on.

It does?

How about this... don't try and turn the C standard lib into STL.
I agree..

The standard does not want to get too big or no one implements it.

There is nothing stopping people doing their old libraries.... M$ did
then there is boost? Lots of others for graphics etc.

hey don't all need to be in the standard

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #122

"Chris Hills" <ch***@phaedsys.orgwrote in message
>
I thought about that.... 42 years... It's possible but I can't imagine I
will care. I would be 90.
We've a Professor Emeritus of that age still entirely capable of giving a
lecture on animal dynamics. He helped out with some computer-generated
movies.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jan 25 '08 #123
On Fri, 25 Jan 2008 10:25:15 -0600, Chris Hills wrote
(in article <$9**************@phaedsys.demon.co.uk>):
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>On Wed, 23 Jan 2008 21:44:43 -0600, CBFalconer wrote
(in article <47***************@yahoo.com>):
>>Randy Howard wrote:
Richard Heathfield wrote

... snip ...

So much for compatibility with C90. :-)

Doesn't take a crystal ball to predict that most people will
still be writing basically C89 with minor additions in 2050.

Defining 'most' as including me, wanna bet?

Well, several of us, likely including me, won't be alive that far out.
;-)

I thought about that.... 42 years... It's possible but I can't imagine I
will care. I would be 90.
I'd be 86. Either way, I doubt I'd care by then.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 25 '08 #124
Chris Hills <ch***@phaedsys.orgwrites:
In article <36******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites
>>Chris Hills said:
>>In article <Vc******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
Here is the second:

character:
single-byte character
C bit representation that fits in a byte

What is the definition of a byte?

What must I deduce from this question? Either that you don't know, or that
you think I don't know, or that you're trying to make some obscure point.

Since you're on the ISO C Committee, I must presume that you know how
"byte" is defined.

Since I've cited the Standard a great many times, you must surely know
that, even if I didn't know, I could look it up (it's actually 3.6(1) in
C99).

So I can only deduce that you're trying to make some obscure point. But I
can't imagine what it is. May I suggest, therefore, that you make your
obscure point somewhat less obscure?

Another long post without shedding any light... You and CBF are
getting good at that.
Oh, come on. Richard was asking you a question, asking you to clarify
what you had just written. He wasn't trying to shed light, he was
inviting you to do so.
I do know the "definition". That is part of the underlying problem
You are specifying the sizes of characters against a variable.
In fact I think it is recursive... :-)
I must admit that I don't understand this. What "variable" are you
referring to? Where's the recursion? I think you're criticizing the
fact that the definitions of "byte" and "character" refer to each
other. But once an implementation defines how big a byte is (as it
must do by defining CHAR_BIT in <limits.h>, the whole thing is
consistent. (I see the smiley, but if there's a joke I'm missing it.)

What exactly is your point?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 25 '08 #125
Chris Hills said:

<snip>
We just need you and the other half dozen
to butt out and not start screaming OT and doubling the size of the
thread.
It seems to me that you are unable to distinguish between a helpful
response and polite redirection on the one hand, and "screaming OT and
doubling the size of the thread" on the other.

I don't know whether or not you are trolling, but I no longer care. It is
evident that you and I cannot hold a sensible technical discussion because
of your preconceptions (and possibly mine too). So I'm going to stop
trying.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 25 '08 #126
On Fri, 25 Jan 2008 12:04:31 -0600, Keith Thompson wrote
(in article <87************@kvetch.smov.org>):
Randy Howard <ra*********@FOOverizonBAR.netwrites:
>On Fri, 25 Jan 2008 00:31:08 -0600, Malcolm McLean wrote
(in article <jZ******************************@bt.com>):
>>"CBFalconer" <cb********@yahoo.comwrote in message
[...]
>>>A replacement can easily be written, but there is no real point in
including it in the standard library. There is no real reason for
including things that can be done efficiently in standard ISO C.
Meanwhile, strtok is there. Leave it alone.

Except things like strcpy(), which are so frequently used it woud be a
nuisance to have to roll your own.

This doesn't even make sense. Why would it be a "nuisance" to roll
your own for a frequently used, simple function? You "roll" it once,
and use it forever.

Are you really suggesting that strcpy() shouldn't be in the standard
library?
No, I'm suggesting it isn't a nuisance to roll your own. Just as I
wrote above. I didn't say that it isn't handy to have extremely common
stuff in the library.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 25 '08 #127
In article <jr******************************@bt.com>, Malcolm McLean
<re*******@btinternet.comwrites
>
"Chris Hills" <ch***@phaedsys.orgwrote in message
>>
I thought about that.... 42 years... It's possible but I can't
imagine I will care. I would be 90.
We've a Professor Emeritus of that age still entirely capable of giving
a lecture on animal dynamics. He helped out with some
computer-generated movies.
I have other things to do in life :-)

That said Knuth is still working (and living) on campus

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #128
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>On Fri, 25 Jan 2008 10:25:15 -0600, Chris Hills wrote
(in article <$9**************@phaedsys.demon.co.uk>):
>In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.netwrites
>>On Wed, 23 Jan 2008 21:44:43 -0600, CBFalconer wrote
(in article <47***************@yahoo.com>):

Randy Howard wrote:
Richard Heathfield wrote
>
... snip ...
>
>So much for compatibility with C90. :-)
>
Doesn't take a crystal ball to predict that most people will
still be writing basically C89 with minor additions in 2050.

Defining 'most' as including me, wanna bet?

Well, several of us, likely including me, won't be alive that far out.
;-)

I thought about that.... 42 years... It's possible but I can't imagine I
will care. I would be 90.

I'd be 86. Either way, I doubt I'd care by then.
Age is usually very good at putting things into perspective.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #129
In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
>In article <36******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites
>>>Chris Hills said:

In article <Vc******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Here is the second:
>
>character:
>single-byte character
>C bit representation that fits in a byte

What is the definition of a byte?

What must I deduce from this question? Either that you don't know, or that
you think I don't know, or that you're trying to make some obscure point.

Since you're on the ISO C Committee, I must presume that you know how
"byte" is defined.

Since I've cited the Standard a great many times, you must surely know
that, even if I didn't know, I could look it up (it's actually 3.6(1) in
C99).

So I can only deduce that you're trying to make some obscure point. But I
can't imagine what it is. May I suggest, therefore, that you make your
obscure point somewhat less obscure?

Another long post without shedding any light... You and CBF are
getting good at that.

Oh, come on. Richard was asking you a question, asking you to clarify
what you had just written. He wasn't trying to shed light, he was
inviting you to do so.
>I do know the "definition". That is part of the underlying problem
You are specifying the sizes of characters against a variable.
In fact I think it is recursive... :-)

I must admit that I don't understand this. What "variable" are you
referring to? Where's the recursion? I think you're criticizing the
fact that the definitions of "byte" and "character" refer to each
other. But once an implementation defines how big a byte is (as it
must do by defining CHAR_BIT in <limits.h>, the whole thing is
consistent. (I see the smiley, but if there's a joke I'm missing it.)

What exactly is your point?
My point is that contrary to what many people think a byte is not 8
bits.

The size of the char and the size of a byte are mutually linked and both
variable. Though one is usually defined by the hardware.

There have been bytes of 5, 6, 8, 9 and 11 bits I think from memory. I
have no doubt that some one will correct me... CBF probably he has a
good memory for the older and more esoterically hardware that is (was?)
out there.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 25 '08 #130
On Jan 25, 2:39*am, Philip Potter <p...@doc.ic.ac.ukwrote:
Richard Heathfield wrote:
So - does C need to support Unicode? Well, C *already* provides support for
any character set the implementation wants to use, subject only to some
very minimal constraints that Unicode easily meets.
So it's a non-issue, really.

Does it really? I speak from ignorance here, so questions in the
following text are genuine requests for information rather than
rhetorical devices:

I see from n1256 that C has support for multibyte characters, which I
wasn't previously aware of, which means that both the source and
execution character set can be UTF-8 or UTF-16.

But I was under the impression that the library support isn't there.
However, reading n1256 reveals the following:

"The strncpy function copies not more than n characters"
"The strncat function appends not more than n characters"
"The strncmp function compares not more than n characters"
"The strlen function returns the number of characters that precede the
terminating null character."

Does this mean that if I declare a char array:

char mystr[] = "abcd$";
/* $ may be a multibyte character; the string contains 5 characters not
including \0 */

then the expression sizeof mystr == strlen(mystr)+1 is not guaranteed,
because sizeof counts bytes and strlen counts characters?

Or is it the case (as I previously thought) that strlen() counts bytes
rather than characters?

My reading of n1256 indicates that the former must be the case, because
the definition of "character" explicitly includes multibyte characters,
and the definition of strlen() explicitly counts characters rather than
bytes.

Am I correct on this? If so, I have learned something today.
This is what real support for Unicode looks like:
http://www-306.ibm.com/software/glob.../icu/index.jsp

In fact, it is what we use here. I suppose that maybe things like
that are more appropriate for C++ than for C.
Jan 25 '08 #131
Richard Heathfield <rj*@see.sig.invalidwrote:
>
Well, then I looked. And they /have/ changed it, and they /have/ broken
everything. C99 has *two* definitions of "character". Here is the first:

character: "abstract member of a set of elements used for the organization,
control, or representation of data" - which means that just about anything
is a character, including functions!

Here is the second:

character:
single-byte character
C bit representation that fits in a byte
You're apparently using a defective plain-text[1] version of the
standard that is missing some critical punctuation. The actual
definitions as best I can transliterate them are:

3.7
*character*
<abstractmember of a set of elements used for the
organization, control, or representation of data

3.7.1
*character*
single-byte character
<Cbit representation that fits in a byte

The terms in angle brackets qualify the definition to a specific subject
field (granted, you have to read the meta-standards for standards to
find that out), so the first definition is of "character" as an abstract
concept whereas the second definition is the precise meaning for the C
language. Note that it is a subclause of the first definition, meaning
that it is a specialization, not a completely independent concept.
(Also note that "single-byte character" is an accepted synonym for
"character" in the second sense -- you could even argue that it should
be preferred.)

It would be nice if the C standard didn't use the term in both senses,
but it does and it always has (particularly since they weren't really
different when C was first defined). It's usually fairly clear from
context which usage is meant, at least to a knowledgeable reader, and we
did make an effort to disambiguate the uses that seemed most likely to
be misunderstood. Completely teasing the two concepts apart is a big,
and likely thankless, job which no one has thus far volunteered for.

[1] All plain-text versions of the standard are defective, which is why
I stopped producing them.

-Larry Jones

Everybody's a slave to routine. -- Calvin
Jan 25 '08 #132
On Fri, 25 Jan 2008 14:02:59 -0600, Chris Hills wrote
(in article <q2**************@phaedsys.demon.co.uk>):
In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
>>In article <36******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites
Chris Hills said:

In article <Vc******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Here is the second:
>>
>character:
>single-byte character
>C bit representation that fits in a byte
>
What is the definition of a byte?

What must I deduce from this question? Either that you don't know, or that
you think I don't know, or that you're trying to make some obscure point.

Since you're on the ISO C Committee, I must presume that you know how
"byte" is defined.

Since I've cited the Standard a great many times, you must surely know
that, even if I didn't know, I could look it up (it's actually 3.6(1) in
C99).

So I can only deduce that you're trying to make some obscure point. But I
can't imagine what it is. May I suggest, therefore, that you make your
obscure point somewhat less obscure?

Another long post without shedding any light... You and CBF are
getting good at that.

Oh, come on. Richard was asking you a question, asking you to clarify
what you had just written. He wasn't trying to shed light, he was
inviting you to do so.
>>I do know the "definition". That is part of the underlying problem
You are specifying the sizes of characters against a variable.
In fact I think it is recursive... :-)

I must admit that I don't understand this. What "variable" are you
referring to? Where's the recursion? I think you're criticizing the
fact that the definitions of "byte" and "character" refer to each
other. But once an implementation defines how big a byte is (as it
must do by defining CHAR_BIT in <limits.h>, the whole thing is
consistent. (I see the smiley, but if there's a joke I'm missing it.)

What exactly is your point?

My point is that contrary to what many people think a byte is not 8
bits.

The size of the char and the size of a byte are mutually linked and both
variable. Though one is usually defined by the hardware.

There have been bytes of 5, 6, 8, 9 and 11 bits I think from memory. I
have no doubt that some one will correct me... CBF probably he has a
good memory for the older and more esoterically hardware that is (was?)
out there.
Not to mention current dsps with 16, 24 and 32. A recent thread in
comp.programming listed off a bunch of different procs with odd byte
sizes.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 25 '08 #133
ym******@gmail.com said:
On Jan 25, 1:06 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>Chris Hills said:

<snip>
We just need you and the other half dozen
to butt out and not start screaming OT and doubling the size of the
thread.

It seems to me that you are unable to distinguish between a *helpful*
response and *polite* redirection on the one hand, and "screaming OT and
doubling the size of the thread" on the other.

(emphasis mine)

That's what you and friends do: first [expletive deleted]
on one's head,
At least Chris can hold a civilised discussion without resorting to foul
language. Into the killfile with you...

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 25 '08 #134
Chris Hills <ch***@phaedsys.orgwrites:
In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
[...]
>>What exactly is your point?

My point is that contrary to what many people think a byte is not 8
bits.
That's it? I think that everyone taking part in this discussion is
perfectly well aware of this.
The size of the char and the size of a byte are mutually linked and
both variable. Though one is usually defined by the hardware.
Variable across implementations, of course, but constant (CHAR_BIT)
for a given implementation.
There have been bytes of 5, 6, 8, 9 and 11 bits I think from memory. I
have no doubt that some one will correct me... CBF probably he has a
good memory for the older and more esoterically hardware that is
(was?) out there.
I've heard of a system where a "byte" could be anywhere from 1 to 60
bits. Of course anything less than 8 is non-conforming for standard
C.

I presume this relates somehow to whatever this subthread was about,
but I'm not going to bother to traverse up the thread and check.

Incidentally, when you change the subject header, it appears in some
newsreaders as the start of a new thread. Also, I'm sure some people
would like to killfile this thread; I think most newsreaders use the
subject line to do this. It was a stupid subject line to begin with,
but if you must post to the thread, please consider leaving the
subject line alone.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 25 '08 #135
Malcolm McLean wrote:
"CBFalconer" <cb********@yahoo.comwrote in message
>Randy Howard wrote:
>>Malcolm McLean wrote
... snip ...
>>>
strtok() - someone think of a safer toekising replacement.

It's "safe", it just isn't described well enough for a novice to
understand the issues, many of which are around code using
extensions not in standard C, like threads. A better one would
be well-received though.

A replacement can easily be written, but there is no real point in
including it in the standard library. There is no real reason for
including things that can be done efficiently in standard ISO C.
Meanwhile, strtok is there. Leave it alone.

Except things like strcpy(), which are so frequently used it woud
be a nuisance to have to roll your own.
Again, it's there. Leave it alone. I have published a safe strtok
replacement right here, but strcpy is so simple it is pointless.
Simply:

while (*dst++ = *src++) continue;

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 25 '08 #136
Chris Hills wrote:
Randy Howard <ra*********@FOOverizonBAR.netwrites
.... snip ...
>
>How about this... don't try and turn the C standard lib into STL.

I agree..

The standard does not want to get too big or no one implements it.

There is nothing stopping people doing their old libraries....
M$ did then there is boost? Lots of others for graphics etc.
I also agree. But there is lots of space for published and
released to public domain routines, available for inclusion in Joe
Q. Blows library of useful things. And c.l.c is one of the best
locations for publishing such.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 25 '08 #137
Chris Hills wrote:
Richard Heathfield <rj*@see.sig.invalidwrites
>Here is the second:

character:
single-byte character
C bit representation that fits in a byte

What is the definition of a byte?
Nothing has been snipped. I strongly suspect you know the
definition of a byte, and are trying to make a 'subtle' point. It
would work better if you quoted sufficient of the original article
to make sense.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 25 '08 #138
CBFalconer wrote:

I think he is just trying to confirm the subject line. :-)
I am not participating in that discussion. Laughing smugly at my desk,
yes.


Brian
Jan 25 '08 #139
Keith Thompson <ks***@mib.orgwrote:
>
So a "multibyte character" is not necessarily a "character".
It's a character in the abstract sense of "character" but not in the
C-specific sense of "character" (i.e., a single-byte character). As
I've said elsethread, it's unfortunate that the standard uses the same
word in two different senses, but there's lots of history entwined in it
and untangling it now is non-trivial. It's usually clear from context
which sense is meant.

-Larry Jones

I always send Grandma a thank-you note right away. ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin
Jan 25 '08 #140
Chris Hills wrote:
(Whatever. )

I'm sure its hilarious for /you/ to change the subject line randomly,
but some of us have filtered this garbage thread. Grow up please.
Jan 25 '08 #141
Mark McIntyre said:
Chris Hills wrote:
(Whatever. )

I'm sure its hilarious for /you/ to change the subject line randomly,
but some of us have filtered this garbage thread. Grow up please.
Your newsreader may be able to filter on the From: field. (Mine can.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 25 '08 #142
Chris Hills wrote:
>
.... snip ...
>
There have been bytes of 5, 6, 8, 9 and 11 bits I think from
memory. I have no doubt that some one will correct me... CBF
probably he has a good memory for the older and more esoterically
hardware that is (was?) out there.
This being c.l.c, and governed by the ISO standard, there are no
such things as bytes of 5 or 6 bits.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 26 '08 #143
la************@siemens.com wrote:
>
.... snip ...
>
[1] All plain-text versions of the standard are defective, which
is why I stopped producing them.
Yet those 'defects' are relatively minor, and there are great
advantages to having a text version. I suggest it would be
advantageous to continue the production, but maybe add an
introductory line explaining the defects.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 26 '08 #144
On Jan 25, 3:50*pm, Richard Heathfield <r...@see.sig.invalidwrote:
Mark McIntyre said:
Chris Hills wrote:
(Whatever. )
I'm sure its hilarious for /you/ to change the subject line randomly,
but some of us have filtered this garbage thread. Grow up please.

Your newsreader may be able to filter on the From: field. (Mine can.)
Likely, he did a thread plonk. He may still like to read from Mr.
Hills.
Jan 26 '08 #145
CBFalconer <cb********@yahoo.comwrites:
la************@siemens.com wrote:
>>
... snip ...
>>
[1] All plain-text versions of the standard are defective, which
is why I stopped producing them.

Yet those 'defects' are relatively minor, and there are great
advantages to having a text version. I suggest it would be
advantageous to continue the production, but maybe add an
introductory line explaining the defects.
For myself, I see no great advantage in having a text version. I
usually use n1256 for reference, or the C99 or C90 standard if needed,
all in PDF format. Since the tools I use do a perfectly adequate job
on PDF files (displaying, searching, etc), I probably wouldn't use a
plain-text version even if I had it. (I don't think I can do regexp
searches, but I've never felt the need to do so.)

If you lack the hardware resources to run a decent PDF viewer, I'm not
unsympathetic to your situation, but the fact is that PDFs work at
least as well as plain text for most people.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 26 '08 #146
On Jan 26, 4:00 am, user923005 <dcor...@connx.comwrote:
On Jan 25, 3:50 pm, Richard Heathfield <r...@see.sig.invalidwrote:
Mark McIntyre said:
Chris Hills wrote:
(Whatever. )
I'm sure its hilarious for /you/ to change the subject line randomly,
but some of us have filtered this garbage thread. Grow up please.
Your newsreader may be able to filter on the From: field. (Mine can.)

Likely, he did a thread plonk. He may still like to read from Mr.
Hills.
<OT>
Shouldn't a thread-plonk filter on the References header rather than
the Subject header? Many threads can have the same subject, but
messages ids are meant to be unique for this very reason...
</OT>
Jan 26 '08 #147
In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
>In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
[...]
>>>What exactly is your point?

My point is that contrary to what many people think a byte is not 8
bits.

That's it? I think that everyone taking part in this discussion is
perfectly well aware of this.
>The size of the char and the size of a byte are mutually linked and
both variable. Though one is usually defined by the hardware.

Variable across implementations, of course, but constant (CHAR_BIT)
for a given implementation.
>There have been bytes of 5, 6, 8, 9 and 11 bits I think from memory. I
have no doubt that some one will correct me... CBF probably he has a
good memory for the older and more esoterically hardware that is
(was?) out there.

I've heard of a system where a "byte" could be anywhere from 1 to 60
bits. Of course anything less than 8 is non-conforming for standard
C.
Where does it say that?
>I presume this relates somehow to whatever this subthread was about,
but I'm not going to bother to traverse up the thread and check.
>Incidentally, when you change the subject header, it appears in some
newsreaders as the start of a new thread. Also, I'm sure some people
would like to killfile this thread; I think most newsreaders use the
subject line to do this. It was a stupid subject line to begin with,
but if you must post to the thread, please consider leaving the
subject line alone.
OK I won't change it again...

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 26 '08 #148
In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Chris Hills wrote:
>>
... snip ...
>>
There have been bytes of 5, 6, 8, 9 and 11 bits I think from
memory. I have no doubt that some one will correct me... CBF
probably he has a good memory for the older and more esoterically
hardware that is (was?) out there.

This being c.l.c, and governed by the ISO standard,
Which it isn't (you may have that artificial constraint the rest of us
dont
there are no
such things as bytes of 5 or 6 bits.
Really?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 26 '08 #149
In article <TN******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Mark McIntyre said:
>Chris Hills wrote:
(Whatever. )

I'm sure its hilarious for /you/ to change the subject line randomly,
but some of us have filtered this garbage thread. Grow up please.

Your newsreader may be able to filter on the From: field. (Mine can.)
Mine too has kept it as the same thread.

I was not happy about the subject line being a personal attack.
Especially as it has grown to over 200 messages.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 26 '08 #150

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.