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  5098 
In article <13*************@corp.supernews.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>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.
Some of us were not enthralled about the subject line in the first place
it being a personal attack. How would you like it?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
<snip>
>>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?
Section 5.2.4.2.1 of the Standard.
<quote>
? number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
</quote>
In article
<0e**********************************@k39g2000hsf. googlegroups.com>,
user923005 <dc*****@connx.comwrites
>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.
Can't see why... :-)
Actually this thread has got some interesting parts to it.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
In article <13*************@corp.supernews.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>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.
Some of us were not enthralled about the subject line in the first place
it being a personal attack. How would you like it?
I personally think you occasionally /are/ a troll. But responding by
being even more offensive is childish and frankly stupid. Grow up or get
a thicker skin.
Chris Hills wrote:
In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>I think he is just trying to confirm the subject line. :-)
Possibly :-)
Well as far as I'm concerned, you've proved it.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre wrote:
Chris Hills wrote:
Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I personally think you occasionally are a troll. But responding by
being even more offensive is childish and frankly stupid. Grow up or
get a thicker skin.
I'll point out that the thread was started by another troll, not one of
the regulars.
Brian
In article <60*************@mid.individual.net>,
Default User <de***********@yahoo.comwrote:
>Mark McIntyre wrote:
>Chris Hills wrote:
Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I personally think you occasionally are a troll. But responding by
being even more offensive is childish and frankly stupid. Grow up or
get a thicker skin.
I'll point out that the thread was started by another troll, not one of
the regulars.
And I'll point out that it is a good question whether you or MarkyMark
is the more mentally deranged.
You both belong in nice padded cells.
Default User wrote:
Mark McIntyre wrote:
>Chris Hills wrote:
>>Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I personally think you occasionally are a troll. But responding by
being even more offensive is childish and frankly stupid. Grow up or
get a thicker skin.
I'll point out that the thread was started by another troll, not one of
the regulars.
Indeed. And if Chris had had the sense to keep out of hte thread, it'd
have died long hence.
Personally I killed the thread almost immediately, my only gripe was
when CH started annoyingly changing the subject line.
On 26 Jan 2008 at 16:53, Default User wrote:
Mark McIntyre wrote:
>Chris Hills wrote:
Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I personally think you occasionally are a troll. But responding by
being even more offensive is childish and frankly stupid. Grow up or
get a thicker skin.
I'll point out that the thread was started by another troll, not one of
the regulars.
I'll point out that the "personal attack" about which Chris Hills was
"not enthralled" was made twice, by Default Loser, in the days before
this thread began. It was my objection to this idiotic accusation that
started this thread.
Of course, we see here Default Loser's division of the world into "the
regulars" and "the trolls". Gimme a C... gimme an L... etc.
On 26 Jan 2008 at 17:25, Kenny McCormack wrote:
In article <60*************@mid.individual.net>,
Default User <de***********@yahoo.comwrote:
>>Mark McIntyre wrote:
>>Chris Hills wrote:
>Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I personally think you occasionally are a troll. But responding by
being even more offensive is childish and frankly stupid. Grow up or
get a thicker skin.
I'll point out that the thread was started by another troll, not one of
the regulars.
And I'll point out that it is a good question whether you or MarkyMark
is the more mentally deranged.
You both belong in nice padded cells.
It seems to me that the Loser is just a sad, miserable old grump who
probably has a miserable life and would deserve our pity if he wasn't so
damn irritating.
Macintyre OTOH is really quite scary - psychotic tendencies and a
vicious nasty streak.
But yeah, lock them both up, far away from a keyboard and an internet
connection, for the good of all mankind.
In article <13*************@corp.supernews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>Default User wrote:
>Mark McIntyre wrote:
>>Chris Hills wrote:
>>>Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I personally think you occasionally are a troll. But responding by
being even more offensive is childish and frankly stupid. Grow up or
get a thicker skin.
I'll point out that the thread was started by another troll, not one of
the regulars.
Indeed. And if Chris had had the sense to keep out of hte thread, it'd
have died long hence.
Personally I killed the thread almost immediately, my only gripe was
when CH started annoyingly changing the subject line.
Translation: My pathetic newsreader (probably something from MS) doesn't
have any kind of non-trivial filtering capabilities.
Chris Hills <ch***@phaedsys.orgwrites:
In article <13*************@corp.supernews.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>>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.
Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I *didn't* like it, and I've said so more than once. I'm disgusted
that one of the more notorious trolls managed to start a thread with a
stupid and insulting subject line, and that the group fell for it. We
have been successfully trolled.
But now you seem to be the biggest participant in this thread. You
had every right to be upset about its existence, but you hardly have
any right to complain about the fact that it's continued. And you are
*personally* responsible for deliberately spawning multiple new
threads with slightly varying subject lines. (The References: headers
still refer to the original thread, so strictly speaking it's still a
single thread, but many newsreaders, including mine, display them
individually.)
You're doing the trolls' supremely annoying job for them.
Congratulations.
--
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"
Chris Hills <ch***@phaedsys.orgwrites:
[...]
I changed the subject line to something less offensive and more
humorous.
And you did it multiple times. Please stop.
If this is all you have to complain about you have a very sad life.
Your complaint seems to be that you can't set up your news reader
correctly Tell use what it is (I know it is OT ) then we can tell you
where to go... in the nicest possible way of course, to get it set up
correctly.
So everyone should take the time to reconfigure their newsreaders
because *you* insist on changing the subject lines.
--
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"
"Chris Hills" <ch***@phaedsys.orgwrote in message
>
I was not happy about the subject line being a personal attack. Especially
as it has grown to over 200 messages.
You're not just anyone, you're on the committee.
The more famous you are the less protection you have from libel. You can
claim that Gordon Brown is dipping his hands into the government till, you
can't do the same to someone who is a crew member at McDonald's, unless you
can prove it in court.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
On 26 Jan 2008 at 19:34, Keith Thompson wrote:
Chris Hills <ch***@phaedsys.orgwrites:
>In article <13*************@corp.supernews.com>, Mark McIntyre
<ma**********@spamcop.netwrites
>>>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.
Some of us were not enthralled about the subject line in the first
place it being a personal attack. How would you like it?
I *didn't* like it, and I've said so more than once. I'm disgusted
that one of the more notorious trolls managed to start a thread with a
stupid and insulting subject line, and that the group fell for it. We
have been successfully trolled.
A blatant attempt to rewrite history.
The allegation in the subject line was made explicitly by Default Loser
(twice) and Jack Klein, and implicitly by HeathField.
If the group "fell" for anything, it was an attempt to discuss this
allegation in the open. Why should a stupid insult (to use your words)
be allowed to be swept under the carpet?
In article <1v******************************@bt.com>, Malcolm McLean
<re*******@btinternet.comwrites
>"Chris Hills" <ch***@phaedsys.orgwrote in message
>>
I was not happy about the subject line being a personal attack.
Especially as it has grown to over 200 messages.
You're not just anyone, you're on the committee.
That's irrelevant
>The more famous you are the less protection you have from libel.
True. Though my "fame" lies in other areas.
You can claim that Gordon Brown is dipping his hands into the
government till, you can't do the same to someone who is a crew member
at McDonald's, unless you can prove it in court.
I know what you mean. It is an interesting point. Though well and truly
OT here. Though this thread, apart from having several unrelated C
topics in it seems to be in a world of it's own.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <87************@kvetch.smov.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
[...]
>I changed the subject line to something less offensive and more
humorous.
And you did it multiple times. Please stop.
>If this is all you have to complain about you have a very sad life.
Your complaint seems to be that you can't set up your news reader
correctly Tell use what it is (I know it is OT ) then we can tell you
where to go... in the nicest possible way of course, to get it set up
correctly.
So everyone should take the time to reconfigure their newsreaders
because *you* insist on changing the subject lines.
No, I just didn't realise that people still used incorrectly configured
systems. Is it my fault?
But do you really want to continue this thread (with the same subject
line) just to debate the point that some peoples news readers are not
well set up?
Mine is over 10 years old and handles it all correctly.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Keith Thompson <ks***@mib.orgwrites:
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.
How ridiculous. Many of us program in non gui system or in emacs (as you
do I think). A text version is mandatory for most programmers so they
can use the same editor at context to view the necessary information.
In article <fn**********@registered.motzarella.org>, Richard
<rg****@gmail.comwrites
>Keith Thompson <ks***@mib.orgwrites:
>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.
How ridiculous. Many of us program in non gui system or in emacs (as you
do I think). A text version is mandatory for most programmers so they
can use the same editor at context to view the necessary information.
I think that is incorrect. Many do program in emacs, Vi and other non
IDE systems but that does not mean that they don't have a PDF viewer on
the computer as well. (Even my phone has a PDF viewer (not that I have
used it in anger)
Also the VERY IMPORTANT point of PDF is that it is not something you can
causally edit by accident. If I was given a text copy of a standard I
have no way of knowing if it is accurate. It might have been when
downloaded but it may not be now.
I think the majority will find the PDF quite acceptable. (I like my hard
copies but then I'm old fashioned)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills <ch***@phaedsys.orgwrites:
[...]
But do you really want to continue this thread (with the same subject
line) just to debate the point that some peoples news readers are not
well set up?
[...]
No, I really don't want to continue this thread *at all*. This will
be my last post on this thread (or threads). I urge everyone else to
stop posting on this thread as well. (Yes, I've posted too much here
already; feel free to call me a hypocrite if you like.)
--
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" la************@siemens.com wrote:
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.
It doesn't use the same word in two different senses. It uses char
and character.
--
[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
CBFalconer <cb********@yahoo.comwrites:
la************@siemens.com wrote:
>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.
It doesn't use the same word in two different senses. It uses char
and character.
No, it really does use the word "character" in two different senses.
Read C99 3.7, 3.7.1, and 3.7.2, in the "Terms, definitions, and
symbols" section. (The first occurrence of the word "char" is in an
example in 5.1.1.3.)
--
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"
"Chris Hills" <ch***@phaedsys.orgwrote in message
I think that is incorrect. Many do program in emacs, Vi and other non
IDE systems but that does not mean that they don't have a PDF viewer on
the computer as well. (Even my phone has a PDF viewer (not that I have
used it in anger)
Also the VERY IMPORTANT point of PDF is that it is not something you can
causally edit by accident. If I was given a text copy of a standard I
have no way of knowing if it is accurate. It might have been when
downloaded but it may not be now.
I think the majority will find the PDF quite acceptable. (I like my hard
copies but then I'm old fashioned)
Academic papers are generally distributed in PDF.
I tried to write a text sucker, to stream all the English-language strings
in a PDF to a text file. Unfortunately the version of the zlib that I have
seems to lack the uncompress / compress functions. This is reuse all over.
That idea bit the dust.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
Chris Hills wrote:
Keith Thompson <ks***@mib.orgwrites
.... snip ...
>
>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?
>From N869.txt:
5.2.4.2.1 Sizes of integer types <limits.h>
[#1] The values given below shall be replaced by constant
expressions suitable for use in #if preprocessing
directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
the following shall be replaced by expressions that have the
same type as would an expression that is an object of the
corresponding type converted according to the integer
promotions. Their implementation-defined values shall be
equal or greater in magnitude (absolute value) to those
shown, with the same sign.
-- number of bits for smallest object that is not a bit-
field (byte)
CHAR_BIT 8
--
[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
Keith Thompson wrote:
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.
I'm not lacking such space etc. However, in general PDF viewers
are GUI creatures, and it is hard to embed their search and
extraction in a series of operations.
--
[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
Richard wrote:
Keith Thompson <ks***@mib.orgwrites:
>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.
How ridiculous. Many of us program in non gui system or in emacs (as
you do I think). A text version is mandatory for most programmers so
they can use the same editor at context to view the necessary
information.
How would scientific and mathematical symbols be represented in plain
text? The portions of the Standard dealing with maths and complex
functions would not be properly rendered.
Malcolm McLean wrote:
>
"Chris Hills" <ch***@phaedsys.orgwrote in message
>I think that is incorrect. Many do program in emacs, Vi and other
non IDE systems but that does not mean that they don't have a PDF
viewer on the computer as well. (Even my phone has a PDF viewer (not
that I have used it in anger)
Also the VERY IMPORTANT point of PDF is that it is not something you
can
causally edit by accident. If I was given a text copy of a standard
I
have no way of knowing if it is accurate. It might have been when
downloaded but it may not be now.
I think the majority will find the PDF quite acceptable. (I like my
hard copies but then I'm old fashioned)
Academic papers are generally distributed in PDF.
I tried to write a text sucker, to stream all the English-language
strings
in a PDF to a text file. Unfortunately the version of the zlib that I
have seems to lack the uncompress / compress functions. This is reuse
all over. That idea bit the dust.
There is a 'pdf2text' utility which can do this for you.
In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Chris Hills wrote:
>Keith Thompson <ks***@mib.orgwrites
... snip ...
>>
>>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?
>>From N869.txt:
Please quote the standard, not an un-issued draft, if you are going to
be pedantic.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills <ch***@phaedsys.orgwrites:
In article <fn**********@registered.motzarella.org>, Richard
<rg****@gmail.comwrites
>>Keith Thompson <ks***@mib.orgwrites:
>>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.
How ridiculous. Many of us program in non gui system or in emacs (as you
do I think). A text version is mandatory for most programmers so they
can use the same editor at context to view the necessary information.
I think that is incorrect. Many do program in emacs, Vi and other
non IDE systems but that does not mean that they don't have a PDF
viewer on the computer as well. (Even my phone has a PDF viewer (not
that I have used it in anger)
"some". Many do not. Many DO program on character only displays
still. Many do access remote system via ssh in text mode only.
I am not precluding the need for PDF, I am just supporting the need for
text too.
Antoninus Twink wrote:
<snip>
HeathField, CBF and the rest don't give a flying frick about the
actual standard, only their singular clc-interpretation of the
standard. This boils down to their own personal tastes and prejudices
(first among them, outright rejection of the current C standard [C99]
which doesn't suit them)... "standard C" is just a phrase they can
throw around to bolster their own ideas about C, and in turn this
becomes a shibboleth they can use to exclude others from their Clique.
If the "Clique" does exist and is as bad as you portray it, shouldn't it
be a good thing to be excluded from it? :)
santosh <sa*********@gmail.comwrites:
Antoninus Twink wrote:
<snip>
>HeathField, CBF and the rest don't give a flying frick about the
actual standard, only their singular clc-interpretation of the
standard. This boils down to their own personal tastes and prejudices
(first among them, outright rejection of the current C standard [C99]
which doesn't suit them)... "standard C" is just a phrase they can
throw around to bolster their own ideas about C, and in turn this
becomes a shibboleth they can use to exclude others from their Clique.
If the "Clique" does exist and is as bad as you portray it, shouldn't it
be a good thing to be excluded from it? :)
The "clique" does exist. It is worse than he portrays it. Any new
members would surely dilute the rudeness and arrogance which exudes from
it like a putrid vapour.
Richard wrote:
santosh <sa*********@gmail.comwrites:
>Antoninus Twink wrote:
<snip>
>>HeathField, CBF and the rest don't give a flying frick about the
actual standard, only their singular clc-interpretation of the
standard. This boils down to their own personal tastes and
prejudices (first among them, outright rejection of the current C
standard [C99] which doesn't suit them)... "standard C" is just a
phrase they can throw around to bolster their own ideas about C, and
in turn this becomes a shibboleth they can use to exclude others
from their Clique.
If the "Clique" does exist and is as bad as you portray it, shouldn't
it be a good thing to be excluded from it? :)
The "clique" does exist. It is worse than he portrays it. Any new
members would surely dilute the rudeness and arrogance which exudes
from it like a putrid vapour.
I don't know about arrogance, but in the matter of rudeness you are, as
I see it, as bad as this "clique". Just a few posts back you used
the "STFU" acronym, which you, for a long time, complained that a
member of this "clique" had used.
You seem to be fighting fire with fire, but to each his own...
Chris Hills wrote:
Harald van Dijk wrote:
>>So do what I suggested, look in the actual standard for 5.2.4.2.1
instead of a draft.
Yes.
>Does it say a byte is required to contain at least 8 bits, or
not?
However there is more than on definition of a byte. There is also the
hardware definition of a byte
But which is irrelevant as far as the C Standard is concerned.
In any case, for all machines I can think of, the hardware byte is
aliased to the byte defined for it's C implementation.
and that over rules the request from he C Standard.
In exactly what way?
The point is both the character and byte are variable definitions with
a minimum of 8 that depends in turn on the hardware under it. The
hardware definition take precedence obviously.
Yes, in the sense that it is strongly recommended to alias the C's byte
with the underlying hardware byte.
If this isn't what you mean by "The hardware definition take precedence
obviously.", then can you please explain more?
<snip>
On 27 Jan 2008 at 17:28, Malcolm McLean wrote:
"Richard" <rg****@gmail.comwrote in message
>>
The "clique" does exist.
Can I join?
Yes, you're an interesting case. I suspect that The Clique generally see
you as a fellow-traveler, but your barmy opinion on size_t is a
heterodoxy that means you'll never /really/ be accepted.
On Sun, 27 Jan 2008 17:53:09 +0000, Chris Hills wrote:
In article <e3***************************@cache1.tilbu1.nb.ho me.nl>,
=?UTF-8?q?Harald_van_D=C4=B3k?= <tr*****@gmail.comwrites
>>On Sun, 27 Jan 2008 16:39:04 +0000, Chris Hills wrote:
>>In article <be**************************@cache1.tilbu1.nb.hom e.nl>,
=?UTF-8?q?Harald_van_D=C4=B3k?= <tr*****@gmail.comwrites
On Sun, 27 Jan 2008 15:00:38 +0000, Chris Hills wrote:
and CBF ALWAYS requires everyone else to be exact. So quoting the
standard means exactly that. Not quoting some un-issued draft that
may change..
You didn't ask for a quote from the standard. You asked "where" "it"
said a byte of less than 8 bits does not conform to standard C.
We were discussing conforming and standard C . The ONLY place to get
that information is from ISO9899:1999
[...]
So do what I suggested, look in the actual standard for 5.2.4.2.1
instead of a draft.
Yes.
>Does it say a byte is required to contain at least 8 bits, or
not?
However there is more than on definition of a byte. There is also the
hardware definition of a byte and that over rules the request from he C
Standard.
You're contradicting yourself. You explicitly denied any definition of a
byte from anything other than the official C standard, and then decided
to ignore the C standard's definition when you found it unsuitable. Which
is it? Are you going to use the C standard definition of "byte", or some
other definition? And if some other definition, what is it, and why
didn't you say so sooner?
Malcolm McLean wrote:
>
"Richard" <rg****@gmail.comwrote in message
The "clique" does exist.
Can I join?
Sure, as long as you don't try to join The Cabal (There Is No Cabal).
Brian
In article <60*************@mid.individual.net>, Default User
<de***********@yahoo.comwrites
>Malcolm McLean wrote:
>>
"Richard" <rg****@gmail.comwrote in message
>
The "clique" does exist.
Can I join?
Sure, as long as you don't try to join The Cabal (There Is No Cabal).
Is that a USB Cabal? :-)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <fn**********@registered.motzarella.org>, santosh
<sa*********@gmail.comwrites
>Chris Hills wrote:
>Harald van Dijk wrote:
>>>So do what I suggested, look in the actual standard for 5.2.4.2.1
instead of a draft.
Yes.
>>Does it say a byte is required to contain at least 8 bits, or
not?
However there is more than on definition of a byte. There is also the
hardware definition of a byte
But which is irrelevant as far as the C Standard is concerned.
No more need be said... The C standard has no concept of IO in the same
way the hardware has no concept of the C standard.
The C standard can specify anything it likes but it has to fit the
hardware whether it likes it or not. If Char bit is 16 and the hardware
says 12 then 12 it is.
>In any case, for all machines I can think of, the hardware byte is
aliased to the byte defined for it's C implementation.
Even if it is 4,5,6, 7,9, 11 bits? The C implementation has to work
with the hardware not the other way around.
>and that over rules the request from he C Standard.
In exactly what way?
The hardware will not bend, Simple as that. It is like people using 16
bit ints on 8 bit MCU's with no 16 bit registers. It won't work
>The point is both the character and byte are variable definitions with
a minimum of 8 that depends in turn on the hardware under it. The
hardware definition take precedence obviously.
Yes, in the sense that it is strongly recommended to alias the C's byte
with the underlying hardware byte.
Which may be anything from 4 upwards. However "strongly recommended" is
the wrong thing to say. The C implementation has to match the hardware
not the other way around.
So the Char and byte definitions are variable and linked to each other
but the are also overridden by the hardware and the byte might be
anywhere from 4-17 (some one will probably find a mainframe with one at
19 :-)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills wrote:
In article <fn**********@registered.motzarella.org>, santosh
<sa*********@gmail.comwrites
>>Chris Hills wrote:
>>Harald van Dijk wrote:
>>>>So do what I suggested, look in the actual standard for 5.2.4.2.1
instead of a draft.
Yes.
Does it say a byte is required to contain at least 8 bits, or
not?
However there is more than on definition of a byte. There is also
the hardware definition of a byte
But which is irrelevant as far as the C Standard is concerned.
No more need be said... The C standard has no concept of IO in the
same way the hardware has no concept of the C standard.
The C standard can specify anything it likes but it has to fit the
hardware whether it likes it or not. If Char bit is 16 and the
hardware says 12 then 12 it is.
Yes.
>>In any case, for all machines I can think of, the hardware byte is
aliased to the byte defined for it's C implementation.
Even if it is 4,5,6, 7,9, 11 bits? The C implementation has to work
with the hardware not the other way around.
Then such an implementation won't be Standard conforming.
I wonder how many systems there are for which the byte has less than
eight bits? Not much I'd guess.
Keith Thompson wrote:
In a thread that should have died after the first posted article, an
interesting technical point was incidentally raised about the size of
a byte. I won't post to that thread, so I'm starting a new one, with
a new Subject header and all previous References deleted.
Chris Hills <ch***@phaedsys.orgwrites:
>In article <fn**********@registered.motzarella.org>, santosh
<sa*********@gmail.comwrites
>>>Chris Hills wrote:
Harald van Dijk wrote:
>So do what I suggested, look in the actual standard for 5.2.4.2.1
>instead of a draft.
Yes.
Does it say a byte is required to contain at least 8 bits, or
>not?
However there is more than on definition of a byte. There is also
the hardware definition of a byte
Yes, but there is one and only one definition of the word "byte" in
the C standard. I don't claim that the other definitions are wrong,
merely that they are not the definition in the C standard.
>>>But which is irrelevant as far as the C Standard is concerned.
No more need be said... The C standard has no concept of IO in the
same way the hardware has no concept of the C standard.
The C standard can specify anything it likes but it has to fit the
hardware whether it likes it or not. If Char bit is 16 and the
hardware says 12 then 12 it is.
No, a C implementation's choice of CHAR_BIT is not absolutely imposed
by the hardware. In most cases (but not all), CHAR_BIT is set to the
size in bits of the smallest addressible unit of memory, but the C
standard imposes an additional requirement that CHAR_BIT >= 8. There
is no wiggle room; if an implementation has CHAR_BIT < 8, it is not a
conforming C implementation.
>>>In any case, for all machines I can think of, the hardware byte is
aliased to the byte defined for it's C implementation.
Even if it is 4,5,6, 7,9, 11 bits? The C implementation has to work
with the hardware not the other way around.
Presumably santosh was not referring to all possible machines, only
the ones he's aware of. I would guess that he's just never seen a
machine with bytes smaller than 8 bits. On all such machines, a
conforming C implementation *can* make CHAR_BIT the same size as a
hardware byte.
I hope you meant to write can't instead of can above?
<rest of interesting article snipped>
Chris Hills wrote, On 27/01/08 20:07:
In article <fn**********@registered.motzarella.org>, santosh
<sa*********@gmail.comwrites
>Chris Hills wrote:
>>Harald van Dijk wrote:
>>>So do what I suggested, look in the actual standard for 5.2.4.2.1
instead of a draft.
Yes.
Does it say a byte is required to contain at least 8 bits, or
not?
However there is more than on definition of a byte. There is also the
hardware definition of a byte
But which is irrelevant as far as the C Standard is concerned.
No more need be said... The C standard has no concept of IO in the same
way the hardware has no concept of the C standard.
Last time I checked the C standard has stdio.h, not suitable for all
purposes but definitely IO.
The C standard can specify anything it likes but it has to fit the
hardware whether it likes it or not. If Char bit is 16 and the hardware
says 12 then 12 it is.
As you well know the C standard does not specify a specific value.
>In any case, for all machines I can think of, the hardware byte is
aliased to the byte defined for it's C implementation.
Even if it is 4,5,6, 7,9, 11 bits? The C implementation has to work
with the hardware not the other way around.
Yes, which is why the C standard does not specify a specific value.
>>and that over rules the request from he C Standard.
In exactly what way?
The hardware will not bend, Simple as that. It is like people using 16
bit ints on 8 bit MCU's with no 16 bit registers. It won't work
Bollocks. I've done 16 bit arithmetic on an 8 bit CPU. I've also done
floating point arithmetic on processors without any floating point HW.
I'm sure those on the ANSI and ISO committees where fully aware of this,
since the processors I've done this on where common in the 80s.
>>The point is both the character and byte are variable definitions with
a minimum of 8 that depends in turn on the hardware under it. The
hardware definition take precedence obviously.
Yes, in the sense that it is strongly recommended to alias the C's byte
with the underlying hardware byte.
Which may be anything from 4 upwards. However "strongly recommended" is
the wrong thing to say. The C implementation has to match the hardware
not the other way around.
Others have previously posted about implementations where the C
implementation used an 8 bit byte but the HW did not understand anything
other than 64 bit. Explain that if the C implementation has to match the HW.
So the Char and byte definitions are variable and linked to each other
but the are also overridden by the hardware and the byte might be
anywhere from 4-17 (some one will probably find a mainframe with one at
19 :-)
Greater than 8 bits is allowed by the C standard as well you know. Now
do you have any real examples of something claiming to be a C
implementation (or something not conforming but getting close) where
char was less than 8 bits?
--
Flash Gordon
santosh <sa*********@gmail.comwrites:
Keith Thompson wrote:
[...]
>Presumably santosh was not referring to all possible machines, only
the ones he's aware of. I would guess that he's just never seen a
machine with bytes smaller than 8 bits. On all such machines, a
conforming C implementation *can* make CHAR_BIT the same size as a
hardware byte.
I hope you meant to write can't instead of can above?
<rest of interesting article snipped>
Yes, I did, thanks.
--
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"
On Jan 28, 10:31 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
Chris Hills wrote, On 27/01/08 20:07:
The hardware will not bend, Simple as that. It is like people using 16
bit ints on 8 bit MCU's with no 16 bit registers. It won't work
Bollocks. I've done 16 bit arithmetic on an 8 bit CPU. I've also done
floating point arithmetic on processors without any floating point HW.
I'm sure those on the ANSI and ISO committees where fully aware of this,
since the processors I've done this on where common in the 80s.
To back that up, I've done 32-bit arithmetic on an 8-bit CPU!
(using 'long' on a compiler for the Z80). It worked just fine.
Perhaps Chris Hills should consult with some embedded
programmers before making these outlandish claims.
Malcolm McLean wrote:
"Richard" <rg****@gmail.comwrote in message
>The "clique" does exist.
Can I join?
Sure. All you need to do is send me the entrance fee, via Paypal.
--
[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
In article <fn**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>How would scientific and mathematical symbols be represented in plain
text?
TeX notation?
The portions of the Standard dealing with maths and complex
functions would not be properly rendered.
I believe the Standard is generated from [t]roff(-ish) source (I have
vague memories of Somebody Who Would Know saying so, and at the very
least, the text version of n869 looks suspiciously like nroff output),
so there's a (sorta-)human-readable text representation at the input
end. Whether it would make sense to carry that representation through
to the text output is a Very Good Question, though.
dave
(likes having n869 around because it's greppable, but usually only uses
it for searching and take-a-quick-look)
--
Dave Vandervies dj3vande at eskimo dot com
BTW, bottlenecks are Good: Unless I can find one or a few, speeding up a
procedure/algorithm/program is _much_ harder.
--Terje Mathisen in comp.arch dj******@csclub.uwaterloo.ca.invalid wrote:
>
I believe the Standard is generated from [t]roff(-ish) source
It is.
so there's a (sorta-)human-readable text representation at the input
end. Whether it would make sense to carry that representation through
to the text output is a Very Good Question, though.
There's no convenient facility for doing that, even if it makes sense.
-Larry Jones
I keep forgetting that rules are only for little nice people. -- Calvin
In article <Fn**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
....
>No, I just didn't realise that people still used incorrectly configured
systems. Is it my fault?
One of the basic rules of computer support is that, yes, it is your
problem (not necessarily your fault, per se) if you are the one who can
do something about it (because you possess the skills necessary to do
something and they don't - because, after all, they're just dumb users
who don't know anything).
>But do you really want to continue this thread (with the same subject
line) just to debate the point that some peoples news readers are not
well set up?
Mine is over 10 years old and handles it all correctly.
That's the whole point. You and I are both using good, solid, old
newsreaders (trn in my case) that work, and have good, solid, filtering
capabilities. Most of these people (if they're not using - gack -
Google) are probably using Outhouse Express or ThunderCrack or something
like that. What is so funny, of course, is that these guys (the Clique)
are supposedly such old grizzled computer veterans (that's what they'd
have us believe), but the reality, as seen by their choice of
newsreaders - and their utter inability to deal with anything more
complicated than the above mentioned newbie junk - shows what pretenders
they really are.
Richard Bos wrote:
<about unicode>
[1] Any single Indian script will fit in 8, probably in 7 bits;
I think a few of them won't fit in 7 bits.
but I doubt you would get far in that country supporting only the one.
Yes. At a minimum you need to support about 7 scripts. This thread has been closed and replies have been disabled. Please start a new discussion. |
