COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### checking double for Inf or NaN - how?

• Follow

```Hi,

I found the code below from
http://www.blitzbasic.com/Community/posts.php?topic=55633

------
' Check if number is finite.

Local u:Double = 2   ' also works for floats

For Local n = 1 To 12
Print isfinite(u) + "  " + u
u :* u
Next

Print
Print

u = u - u
Print isfinite(u) + "  " + u

Function isfinite( x:Double )    ' assumes Intel byte order

Const EXP_BITS = %01111111111100000000000000000000

Local bits = ( Int Ptr Varptr x )[1]  ' [0] for Mac?

Return ( bits & EXP_BITS ) <> EXP_BITS   ' exponent is all 1s for
infinity or NaN

End Function

------

I need something like that - but the author writes that "This is intel
only. Anybody want to make it multiplatform? It shouldn't be difficult,
but I don't have a Mac".

The code above doesn't look like "standard C" to me... But I would like
this function to work *preferable* under both linux, mac and windows
pc's....

My guess is that the code should be changed to something like:

int(double testval)
{
Const EXP_BITS = %01111111111100000000000000000000

return (testval && EXP_BITS); /* returns either 0 or 1 ? */
}

But I guess EXP_BITS is completely wrong defined, so how to make it work
- and are there better existing ways to check for Inf or NaN???

It would be nice with 2 functions: One that tests for plus/minus Inf and
one that checks for NaN, if there's any difference? I didn't really
understood the bit-pattern-difference between NaN and Inf...

Best regards / Med venlig hilsen
Martin J�rgensen

--
---------------------------------------------------------------------------
Home of Martin J�rgensen - http://www.martinjoergensen.dk
```
 0
Reply unoder.spam (554) 5/18/2006 3:27:16 PM

```Martin J�rgensen wrote:
-snip-

> It would be nice with 2 functions: One that tests for plus/minus Inf and
> one that checks for NaN, if there's any difference? I didn't really
> understood the bit-pattern-difference between NaN and Inf...

Basically I have a variable that contains -1.#IND00000000000...
according to MS visual studio 2005... I thought that this was (-inf) so

....
if( val < 0)
do something <- never got here....

I hope somebody can figure this out?

Best regards / Med venlig hilsen
Martin J�rgensen

--
---------------------------------------------------------------------------
Home of Martin J�rgensen - http://www.martinjoergensen.dk
```
 0
Reply unoder.spam (554) 5/18/2006 3:38:52 PM

```"Martin J�rgensen" <unoder.spam@spam.jay.net> wrote in message
news:lbguj3-1nr.ln1@news.tdc.dk...
> Hi,
>
> I found the code below from
> http://www.blitzbasic.com/Community/posts.php?topic=55633
>
> ------
> ' Check if number is finite.
>
>
> Local u:Double = 2   ' also works for floats
>
> For Local n = 1 To 12
> Print isfinite(u) + "  " + u
> u :* u
> Next
>
> Print
> Print
>
> u = u - u
> Print isfinite(u) + "  " + u
>
>
> Function isfinite( x:Double )    ' assumes Intel byte order
>
> Const EXP_BITS = %01111111111100000000000000000000
>
> Local bits = ( Int Ptr Varptr x )[1]  ' [0] for Mac?
>
> Return ( bits & EXP_BITS ) <> EXP_BITS   ' exponent is all 1s for infinity
> or NaN
>
> End Function
>
>
> ------
>
> I need something like that - but the author writes that "This is intel
> only. Anybody want to make it multiplatform? It shouldn't be difficult,
> but I don't have a Mac".
>
> The code above doesn't look like "standard C" to me... But I would like
> this function to work *preferable* under both linux, mac and windows
> pc's....
>
> My guess is that the code should be changed to something like:
>
> int(double testval)
> {
> Const EXP_BITS = %01111111111100000000000000000000
>
> return (testval && EXP_BITS); /* returns either 0 or 1 ? */
> }
>
> But I guess EXP_BITS is completely wrong defined, so how to make it work -
> and are there better existing ways to check for Inf or NaN???
>
> It would be nice with 2 functions: One that tests for plus/minus Inf and
> one that checks for NaN, if there's any difference? I didn't really
> understood the bit-pattern-difference between NaN and Inf...

The source snippet might look different to you than me, but it seems to be
missing about ten tokens in order to be C.  joe

```
 0
Reply grumpy196884 (155) 5/18/2006 3:41:18 PM

```Martin J�rgensen wrote:
-snip-

> understood the bit-pattern-difference between NaN and Inf...

Addition: You can generate -1.#IND000000... by:

#include math.h

....
var = sqrt (-10);
....

var = -1.#IND000000.., according to MS visual studio 2005 (just in case
somebody wants to try it out).

Best regards / Med venlig hilsen
Martin J�rgensen

--
---------------------------------------------------------------------------
Home of Martin J�rgensen - http://www.martinjoergensen.dk
```
 0
Reply unoder.spam (554) 5/18/2006 3:42:40 PM

```Martin J=F8rgensen wrote:
> Martin J=F8rgensen wrote:
> -snip-
>
> > It would be nice with 2 functions: One that tests for plus/minus Inf and
> > one that checks for NaN, if there's any difference? I didn't really
> > understood the bit-pattern-difference between NaN and Inf...
>
> Basically I have a variable that contains -1.#IND00000000000...
> according to MS visual studio 2005... I thought that this was (-inf) so
>
> ...
>    if( val < 0)
>       do something <- never got here....
>
> I hope somebody can figure this out?
> Martin J=F8rgensen

The IEEE floating point standard says that any comparison
in which one operand is a NaN should evaluate to FALSE.
So the following counter-intuitive test meets your needs:

if (val =3D=3D val)
do_nothing ( );
else
report_NaN (val);

unless an over-eager (and incorrect) compiler optimises
half of it away . . .
--

```
 0
Reply bert.hutchings (56) 5/18/2006 3:59:05 PM

```Martin J�rgensen wrote:

> Basically I have a variable that contains -1.#IND00000000000...
> according to MS visual studio 2005...
> I thought that this was (-inf) so
>
> ...
>    if( val < 0)
>       do something <- never got here....
>
> I hope somebody can figure this out?

exp(DBL_MAX) is a range error.
sqrt(-1) is a domain error.

/* BEGIN new.c */

#include <math.h>
#include <float.h>
#include <stdio.h>

int main(void)
{
double x = -exp(DBL_MAX);
double y = sqrt(-1);

printf("-exp(DBL_MAX) is %f\n", x);
printf("sqrt(-1)      is %f\n", y);
return 0;
}

/* END new.c */

N869
7.12.1  Treatment of error conditions
[#1]  The  behavior  of each of the functions in <math.h> is
specified  for  all  representable  values  of   its   input
arguments, except where stated otherwise.
[#2]  For  all  functions, a domain error occurs if an input
argument is outside the domain over which  the  mathematical
function is defined.  The description of each function lists
any required domain errors;  an  implementation  may  define
additional  domain  errors,  provided  that  such errors are
consistent  with  the   mathematical   definition   of   the
function.182)  On a domain error, the  function  returns  an
implementation-defined value; whether the integer expression
errno acquires the value EDOM is implementation-defined.
[#3] Similarly, a range error  occurs  if  the  mathematical
result of the function cannot be represented in an object of
the specified type, due to extreme  magnitude.   A  floating
result overflows if the magnitude of the mathematical result
is finite but so large that the mathematical  result  cannot
be  represented, without extraordinary roundoff error, in an
object  of  the  specified  type.   If  a  floating   result
overflows  and  default  rounding  is  in  effect, or if the
mathematical  result  is  an  exact  infinity  (for  example
log(0.0)),  then the function returns the value of the macro
HUGE_VAL, HUGE_VALF, or HUGE_VALL according  to  the  return
type,  with  the  same  sign  as  the  correct  value of the
function; whether errno acquires the  value  ERANGE  when  a
range  error  occurs  is implementation-defined.  The result
underflows if the magnitude of the mathematical result is so
small  that  the  mathematical result cannot be
represented,             without extraordinary roundoff error, in an
object  of  the
specified  type.  If the result underflows, the function
returns a value whose  magnitude  is  no  greater  than  the
smallest  normalized  positive  number in the specified type
and  is  otherwise  implementation-defined;  whether   errno
acquires the value ERANGE is implementation-defined.

--
pete
```
 0
Reply pfiland (6614) 5/18/2006 4:06:56 PM

```pete wrote:
> Martin J�rgensen wrote:
>
>
>>Basically I have a variable that contains -1.#IND00000000000...
>>according to MS visual studio 2005...
>>I thought that this was (-inf) so
>>
>>...
>>   if( val < 0)
>>      do something <- never got here....
>>
>>I hope somebody can figure this out?
>
>
> exp(DBL_MAX) is a range error.
> sqrt(-1) is a domain error.
-snip-

Yes, thanks but you're only printing out the values using printf(). You
didn't make the if-test...

Best regards / Med venlig hilsen
Martin J�rgensen

--
---------------------------------------------------------------------------
Home of Martin J�rgensen - http://www.martinjoergensen.dk
```
 0
Reply unoder.spam (554) 5/18/2006 5:36:50 PM

```bert wrote:
> Martin J�rgensen wrote:
>
>>Martin J�rgensen wrote:
>>-snip-
>>
>>
>>>It would be nice with 2 functions: One that tests for plus/minus Inf and
>>>one that checks for NaN, if there's any difference? I didn't really
>>>understood the bit-pattern-difference between NaN and Inf...
>>
>>Basically I have a variable that contains -1.#IND00000000000...
>>according to MS visual studio 2005... I thought that this was (-inf) so
>>
>>...
>>   if( val < 0)
>>      do something <- never got here....
>>
>>I hope somebody can figure this out?
>>Martin J�rgensen
>
>
> The IEEE floating point standard says that any comparison
> in which one operand is a NaN should evaluate to FALSE.
> So the following counter-intuitive test meets your needs:
>
>     if (val == val)
>         do_nothing ( );
>     else
>         report_NaN (val);

Ok, thanks a lot - it works here and it was a lot easier than I
feared... And how do I check for plus/minus inf ?

Best regards / Med venlig hilsen
Martin J�rgensen

--
---------------------------------------------------------------------------
Home of Martin J�rgensen - http://www.martinjoergensen.dk
```
 0
Reply unoder.spam (554) 5/18/2006 5:45:13 PM

```Martin J�rgensen a �crit :
> Hi,
>
> I found the code below from
> http://www.blitzbasic.com/Community/posts.php?topic=55633
>
> ------
> ' Check if number is finite.
>
>
> Local u:Double = 2   ' also works for floats
>
> For Local n = 1 To 12
>     Print isfinite(u) + "  " + u
>     u :* u
> Next
>
> Print
> Print
>
> u = u - u
> Print isfinite(u) + "  " + u
>
>
> Function isfinite( x:Double )    ' assumes Intel byte order
>
>     Const EXP_BITS = %01111111111100000000000000000000
>
>     Local bits = ( Int Ptr Varptr x )[1]  ' [0] for Mac?
>
>     Return ( bits & EXP_BITS ) <> EXP_BITS   ' exponent is all 1s for
> infinity or NaN
>
> End Function
>
>
> ------
>
> I need something like that - but the author writes that "This is intel
> only. Anybody want to make it multiplatform? It shouldn't be difficult,
> but I don't have a Mac".
>
> The code above doesn't look like "standard C" to me... But I would like
> this function to work *preferable* under both linux, mac and windows
> pc's....
>
> My guess is that the code should be changed to something like:
>
> int(double testval)
> {
>     Const EXP_BITS = %01111111111100000000000000000000
>
>     return (testval && EXP_BITS); /* returns either 0 or 1 ? */
> }
>
> But I guess EXP_BITS is completely wrong defined, so how to make it work
> - and are there better existing ways to check for Inf or NaN???
>
> It would be nice with 2 functions: One that tests for plus/minus Inf and
> one that checks for NaN, if there's any difference? I didn't really
> understood the bit-pattern-difference between NaN and Inf...
>
>
> Best regards / Med venlig hilsen
> Martin J�rgensen
>

Standard C has several functions for this:
1) isfinite: returns true if its argument is finite
2) isinf: returns true if its argument is infinite
3) isnormal: returns true if its argument is normal
4) fpclassify returns the type of its argument.

See the documentation of your compiler system.

P.S. This will work in standard C, not in Visual Studio.
```
 0
Reply jacob (2538) 5/18/2006 5:53:19 PM

```jacob navia wrote:
-snip-

> Standard C has several functions for this:
> 1) isfinite: returns true if its argument is finite
> 2) isinf: returns true if its argument is infinite
> 3) isnormal: returns true if its argument is normal
> 4) fpclassify returns the type of its argument.
>
> See the documentation of your compiler system.

Ok.

> P.S. This will work in standard C, not in Visual Studio.

Is visual studio 2005 not standard C? I think I disabled something
that's on by default so I think it understands standard C at least... At
least I've had no problems yet with standard C on it (or is it ANSI C?
Don't know if there's any difference)....

Best regards / Med venlig hilsen
Martin J�rgensen

--
---------------------------------------------------------------------------
Home of Martin J�rgensen - http://www.martinjoergensen.dk
```
 0
Reply unoder.spam (554) 5/18/2006 9:48:14 PM

```Martin J�rgensen said:

> jacob navia wrote:
> -snip-
>
>> Standard C has several functions for this:
>> 1) isfinite: returns true if its argument is finite
>> 2) isinf: returns true if its argument is infinite
>> 3) isnormal: returns true if its argument is normal
>> 4) fpclassify returns the type of its argument.
>>
>> See the documentation of your compiler system.
>
> Ok.
>
>> P.S. This will work in standard C, not in Visual Studio.
>
> Is visual studio 2005 not standard C?

Yes and no. VStudio conforms to ISO/IEC 9899:1990 (when you "disable
Microsoft extensions" in the project settings), modulo some trivial and
much-unused dark corners of the language. (Never come across these myself
AFAICR, but people here in clc have occasionally waxed lyrical on the
subject.)

But it doesn't conform to ISO/IEC 9899:1999, which is what you'd need if you
wanted to use Jacob Navia's suggestions. Having said that, almost no C
compilers conform to that later spec - and so, even if VStudio did give you

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/18/2006 10:05:30 PM

```Richard Heathfield wrote:
> Martin J�rgensen said:
-snip-

>>Is visual studio 2005 not standard C?
>
>
> Yes and no. VStudio conforms to ISO/IEC 9899:1990 (when you "disable
> Microsoft extensions" in the project settings), modulo some trivial and

Exactly! That is what I did (disabled those stupid extensions).

> much-unused dark corners of the language. (Never come across these myself
> AFAICR, but people here in clc have occasionally waxed lyrical on the
> subject.)
>
> But it doesn't conform to ISO/IEC 9899:1999, which is what you'd need if you
> wanted to use Jacob Navia's suggestions. Having said that, almost no C
> compilers conform to that later spec - and so, even if VStudio did give you

isinf and isfinite looks to me like they also exists under unix, so
doesn't that mean it would probably be portable?

Best regards / Med venlig hilsen
Martin J�rgensen

--
---------------------------------------------------------------------------
Home of Martin J�rgensen - http://www.martinjoergensen.dk
```
 0
Reply unoder.spam (554) 5/18/2006 10:49:47 PM

```Martin J�rgensen said:

> isinf and isfinite looks to me like they also exists under unix, so
> doesn't that mean it would probably be portable?

That depends entirely on your definition of "portable". :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/18/2006 11:05:45 PM

```Martin J�rgensen a �crit :
> Richard Heathfield wrote:
>
>> Martin J�rgensen said:
>
> -snip-
>
>>> Is visual studio 2005 not standard C?
>>
>>
>>
>> Yes and no. VStudio conforms to ISO/IEC 9899:1990 (when you "disable
>> Microsoft extensions" in the project settings), modulo some trivial and
>
>
> Exactly! That is what I did (disabled those stupid extensions).
>
>> much-unused dark corners of the language. (Never come across these
>> myself AFAICR, but people here in clc have occasionally waxed lyrical
>> on the subject.)
>>
>> But it doesn't conform to ISO/IEC 9899:1999, which is what you'd need
>> if you wanted to use Jacob Navia's suggestions. Having said that,
>> almost no C compilers conform to that later spec - and so, even if
>> portable.
>
>
> isinf and isfinite looks to me like they also exists under unix, so
> doesn't that mean it would probably be portable?
>
>
> Best regards / Med venlig hilsen
> Martin J�rgensen
>

Visual studio conforms to the obsolete C standard of 1989.
It has:
isnan(double)
isnanf(float)
finitef(float)
finite(double)

Those functions can solve your problem too.

```
 0
Reply jacob (2538) 5/19/2006 6:51:18 AM

```jacob navia <jacob@jacob.remcomp.fr> writes:
[...]
> Visual studio conforms to the obsolete C standard of 1989.
> It has:
> isnan(double)
> isnanf(float)
> finitef(float)
> finite(double)
>
> Those functions can solve your problem too.

To be clear, the C89/C90 standard doesn't define those functions.
(I won't comment on whether the C89/C90 standard is "obsolete".)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
```
 0
Reply kst-u (21545) 5/19/2006 7:08:57 AM

```jacob navia said:

> Visual studio conforms to the obsolete C standard of 1989.

The 1989 Standard is far from obsolete. It is still the current de facto
Standard, and will remain so until C99 is widely implemented. That day
appears to be some way off - the GNU people have shied away from full
conformance to C99, and Microsoft have ignored it completely.

The C Standard is of no value unless it enables us to write portable code.
C99 features are, quite simply, not even remotely as portable as C89
features.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/19/2006 7:13:51 AM

```Richard Heathfield a �crit :
> jacob navia said:
>
>
>>Visual studio conforms to the obsolete C standard of 1989.
>
>
> The 1989 Standard is far from obsolete. It is still the current de facto
> Standard, and will remain so until C99 is widely implemented. That day
> appears to be some way off - the GNU people have shied away from full
> conformance to C99,

The issues with gcc are VERY minor. It is a good C99 implementation, and
can be used without any problems.

and Microsoft have ignored it completely.

Yes

>
> The C Standard is of no value unless it enables us to write portable code.

This is your opinion. Your are entitled to it Mr Heathfield, but it is
not mine anyway. There are people that will stay in the past, longing
for the lost "golden times"...

"Portability" for you means "taking the worst features of each
implementation".

There are C99 compilers under windows, and under Unix.

```
 0
Reply jacob (2538) 5/19/2006 7:20:32 AM

```jacob navia said:

> There are C99 compilers under windows, and under Unix.

ROTFL! Well, that's all right then!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/19/2006 7:56:54 AM

```Richard Heathfield a �crit :
> jacob navia said:
>
>
>>There are C99 compilers under windows, and under Unix.
>
>
> ROTFL! Well, that's all right then!
>

Those are the operating systems mentioned in the original poster's
message.

You speak about "portability", as it was necessary for every piece of
code to be potentially portable to all possible machines. This is mostly
never the case. Many people do not care at all if their code can run
without modifications at some embedded system with a 15 year old
compiler you see?

Some code running with visual studio or under a Mac OSx or similar
will make so many hidden assumptions about RAM size, disk space, etc etc
that it will NEVER run in the "System X" running in the toaster
with 16k of ram.

So What?

```
 0
Reply jacob (2538) 5/19/2006 9:28:35 AM

```jacob navia said:

> Richard Heathfield a �crit :
>> jacob navia said:
>>
>>
>>>There are C99 compilers under windows, and under Unix.
>>
>>
>> ROTFL! Well, that's all right then!
>>
>
> Those are the operating systems mentioned in the original poster's
> message.

He also mentioned the Mac.

> You speak about "portability", as it was necessary for every piece of
> code to be potentially portable to all possible machines.

The general assumption in comp.lang.c is that the code is targeted at a
hosted implementation of unknown provenance (unless it is specifically
mentioned that a freestanding implementation is targeted). If the platform
matters, well, there are other newsgroups where such discussions can be
held.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/19/2006 9:40:02 AM

```In article <QoKdnfmukN9k8vDZRVnyhQ@bt.com>, Richard Heathfield
<invalid@invalid.invalid> writes
>jacob navia said:
>
>> Visual studio conforms to the obsolete C standard of 1989.
>
>The 1989 Standard is far from obsolete. It is still the current de facto
>Standard,

I think you mean ISO 9899:1990 + A1 and the TC's aka C95

C89 is a local US standard that was superseded by the ISO standard in
1990.

> and will remain so until C99 is widely implemented. That day
>appears to be some way off - the GNU people have shied away from full
>conformance to C99, and Microsoft have ignored it completely.
>
>The C Standard is of no value unless it enables us to write portable code.

I don't agree there. There are few truly portable apps. However I agree
that the c standard is of little use unless the language as defined in
the standard is of use and implimentable in the majority of compilers.
Or the majority of it implimentable in All compilers.

>C99 features are, quite simply, not even remotely as portable as C89
>features.

Neither, it appears,  are they wanted by the majority.

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

```
 0
Reply chris32 (3350) 5/19/2006 10:03:19 AM

```In article <446d71bf\$0\$18324\$8fcfb975@news.wanadoo.fr>, jacob navia
<jacob@jacob.remcomp.fr> writes
>Richard Heathfield a �crit :
>> jacob navia said:
>>
>> The C Standard is of no value unless it enables us to write portable code.
>
>This is your opinion. Your are entitled to it Mr Heathfield, but it is
>not mine anyway. There are people that will stay in the past, longing
>for the lost "golden times"...

In some cases fools rush in where angles fear to tread.

The problem is AFAICS that C99 contains things that are broken and not a
good idea which is why the compiler vendors did not rush to implement
it. Neither have the majority of users demanded them.

If you look at the recent argument about the "Spawn of Satan M\$" who are
working with ECMA on C++/CLI  (also C#) for desktop use and then note
that MISRA took C90 as a base for embedded use. Put that against the
fact that several of the ISO C panel have said they regret several
features got into C99 you have to ask what is the point of C99?

It appears that the ISO standards have departed from industry usage and
practice. There are other "standards" being developed by the industry
that are in use or the de-facto standards.

ISO BASIC died whilst VB is widely used.

>"Portability" for you means "taking the worst features of each
>implementation".
>
>There are C99 compilers under windows, and under Unix.

Very few but we have been here before. :-( Let's not argue that again.

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

```
 0
Reply chris32 (3350) 5/19/2006 10:05:14 AM

```In article <S7mdnUEUPumgD_DZnZ2dnUVZ8qadnZ2d@bt.com>, Richard Heathfield
<invalid@invalid.invalid> writes
>jacob navia said:
>
>> Richard Heathfield a �crit :
>>> jacob navia said:
>>>
>>>
>>>>There are C99 compilers under windows, and under Unix.
>>>
>>>
>>> ROTFL! Well, that's all right then!
>>>
>>
>> Those are the operating systems mentioned in the original poster's
>> message.
>
>He also mentioned the Mac.
>
>> You speak about "portability", as it was necessary for every piece of
>> code to be potentially portable to all possible machines.
>
>The general assumption in comp.lang.c is that the code is targeted at a
>hosted implementation

Only by some people.

The other thing to consider is that the majority of C implimentations
are more likely to be in the embedded space (there are probably at least
4 compilers for any embedded target and dozens of targets) since AFAIK
most desktop systems have moved to C++, C# and C++/CLI  etc

>of unknown provenance (unless it is specifically
>mentioned that a freestanding implementation is targeted). If the platform
>matters, well, there are other newsgroups where such discussions can be
>held.

However the language as defined should be implimentable on the majority
of compilers/platforms or the majority of the language on all of the
compilers/platforms.

As I have said before if you only want to discus PURE ISO c (ie C99) on
a hosted target then you are very sorely limited.

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

```
 0
Reply chris32 (3350) 5/19/2006 10:38:05 AM

```In article <S7mdnUEUPumgD_DZnZ2dnUVZ8qadnZ2d@bt.com>,
Richard Heathfield  <invalid@invalid.invalid> wrote:

>>>>There are C99 compilers under windows, and under Unix.

>> Those are the operating systems mentioned in the original poster's
>> message.

>He also mentioned the Mac.

Macs run unix these days.

-- Richard
```
 0
Reply richard91 (3683) 5/19/2006 11:09:12 AM

```In article <e4k90o\$t5n\$1@pc-news.cogsci.ed.ac.uk>, Richard Tobin
<richard@cogsci.ed.ac.uk> writes
>Richard Heathfield  <invalid@invalid.invalid> wrote:
>
>>>>>There are C99 compilers under windows, and under Unix.
>
>>> Those are the operating systems mentioned in the original poster's
>>> message.
>
>>He also mentioned the Mac.
>
>Macs run unix these days.
>
>-- Richard

AFAIK
OSX was developed from NEXT Step OS which was developed from BSD Unix.

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

```
 0
Reply chris32 (3350) 5/19/2006 11:20:22 AM

```Richard Tobin a �crit :
> Richard Heathfield  <invalid@invalid.invalid> wrote:
>
>
>>>>>There are C99 compilers under windows, and under Unix.
>
>
>>>Those are the operating systems mentioned in the original poster's
>>>message.
>
>
>>He also mentioned the Mac.
>
>
> Macs run unix these days.
>

Yes but he is using a mac vintage 1989...

:-)

jacob
```
 0
Reply jacob (2538) 5/19/2006 11:31:03 AM

```Richard Heathfield wrote:

> C99 features are, quite simply, not even remotely as portable as C89
> features.

I like the added restrictions of C99,
such as no implicit int
and requiring protypes for all functions.

C89 code, written with the additional restrcitions of C99,
is better formatted C89 code.

--
pete
```
 0
Reply pfiland (6614) 5/19/2006 11:48:24 AM

```Richard Heathfield wrote:
>
> jacob navia said:

> > You speak about "portability",
> > as it was necessary for every piece of
> > code to be potentially portable to all possible machines.

That's just for code posted to the newsgroup.

The group is about the language,
not "your" implmentation,
("your", for all possible values of "you").

--
pete
```
 0
Reply pfiland (6614) 5/19/2006 11:51:47 AM

```jacob navia wrote:

> "Portability" for you means "taking the worst features of each
> implementation".

That is what it means.

The C programming language (the topic of the group),
is defined in terms of the abstract machine.

--
pete
```
 0
Reply pfiland (6614) 5/19/2006 11:57:11 AM

```pete wrote:
>
> Richard Heathfield wrote:
> >
> > jacob navia said:
>
> > > You speak about "portability",
> > > as it was necessary for every piece of
> > > code to be potentially portable to all possible machines.
>
> That's just for code posted to the newsgroup.
>
> The group is about the language,
> not "your" implmentation,
> ("your", for all possible values of "you").

I don't have a problem with posted code
that is for specific implementation defined situations
such as where CHAR_BIT equals eight and sizeof(int) equals four,
and as long as the implementation defined restrictions
for the code are completely specified, in the post.

I'm only interested in the name of a compiler
when the issue is
whether or not it is a conforming implementation.

--
pete
```
 0
Reply pfiland (6614) 5/19/2006 12:41:18 PM

```Chris Hills said:

> In article <QoKdnfmukN9k8vDZRVnyhQ@bt.com>, Richard Heathfield
> <invalid@invalid.invalid> writes
>>jacob navia said:
>>
>>> Visual studio conforms to the obsolete C standard of 1989.
>>
>>The 1989 Standard is far from obsolete. It is still the current de facto
>>Standard,
>
> I think you mean ISO 9899:1990 + A1 and the TC's aka C95

Quite so. Shorthand, my dear chap, shorthand. (And, of course, I was echoing
JN's use of "1989".)

>> and will remain so until C99 is widely implemented. That day
>>appears to be some way off - the GNU people have shied away from full
>>conformance to C99, and Microsoft have ignored it completely.
>>
>>The C Standard is of no value unless it enables us to write portable code.
>
> I don't agree there. There are few truly portable apps.

I didn't say "apps". I said "code". Personally, I write a lot of portable
programs, but that's neither here nor there. The value of the Standard is
that it allows us to divide our application code into portable and
non-portable parts, so that only the non-portable part need be rewritten
for each port to a new platform. If this is done well, as much as 99% of a
GUI application can be ported without change (I've certainly experienced
this with a half-million-line set-top-box application, which had to be
ported to all manner of platforms, including those with weird CHAR_BITs and
the like).

The Standard helps us to divide the code appropriately. If the Standard is
not /implemented/ (sufficiently widely), though, there isn't much point in
paying attention to it. That is the position C99 is in.

>>C99 features are, quite simply, not even remotely as portable as C89
>>features.
>
> Neither, it appears,  are they wanted by the majority.

Right - so I see no reason to bother with C99 at all.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/19/2006 1:03:29 PM

```Richard Tobin said:

> Richard Heathfield  <invalid@invalid.invalid> wrote:
>
>>>>>There are C99 compilers under windows, and under Unix.
>
>>> Those are the operating systems mentioned in the original poster's
>>> message.
>
>>He also mentioned the Mac.
>
> Macs run unix these days.

Well, they *can*, but that doesn't mean that all of them *do*. The OP
(rightly) did not say which OS he was running on his Mac. Rightly, because
it is irrelevant in this newsgroup.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/19/2006 1:06:20 PM

```pete said:

> Richard Heathfield wrote:
>
>> C99 features are, quite simply, not even remotely as portable as C89
>> features.
>
> I like the added restrictions of C99,
> such as no implicit int
> and requiring protypes for all functions.

Likewise. Shame about the return value from main, but I stick it in anyway,
of course.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/19/2006 1:08:14 PM

```In article <h62dnQ2_uYhxXPDZnZ2dnUVZ8qadnZ2d@bt.com>,
Richard Heathfield  <invalid@invalid.invalid> wrote:
>Chris Hills said:
>
>> In article <QoKdnfmukN9k8vDZRVnyhQ@bt.com>, Richard Heathfield
>> <invalid@invalid.invalid> writes

>>>The C Standard is of no value unless it enables us to write portable code.
>>
>> I don't agree there. There are few truly portable apps.
>
>I didn't say "apps". I said "code".

Datum:
The code I'm currently working on at my day job breaks down as:
1399 lines of portable will-end-up-as-production code
349 lines of portable offline test drivers
60-ish lines of DLL entry points and interfacing for the live version

(The first two numbers came from wc -l, so include comments and
whitespace; the last is an estimate, since I don't have that code on
the laptop I'm using right now.)

It's not done yet, but most of the code that's yet to be written
(probably not more than another 100 lines or so; the part that does the
heavy lifting is done) will go in the first line in my summary.

dave

--
Dave Vandervies                   dj3vande@csclub.uwaterloo.ca

The full rant is left as an exercise for the motivated reader.
--David Rush in comp.lang.scheme
```
 0
Reply dj3vande (656) 5/19/2006 1:16:43 PM

```In article <h62dnQy_uYgFX_DZnZ2dnUVZ8qadnZ2d@bt.com>,
Richard Heathfield  <invalid@invalid.invalid> wrote:

>> Macs run unix these days.

>Well, they *can*, but that doesn't mean that all of them *do*.

More than 99% of those still in use, I would guess.  The newer ones
can't run pre-unix MacOS.

>The OP
>(rightly) did not say which OS he was running on his Mac. Rightly, because
>it is irrelevant in this newsgroup.

I was not addressing the OP, just your implication that "mac" was not
covered by "unix".

-- Richard
```
 0
Reply richard91 (3683) 5/19/2006 1:43:21 PM

```Chris Hills <chris@phaedsys.org> writes:
> In article <QoKdnfmukN9k8vDZRVnyhQ@bt.com>, Richard Heathfield
> <invalid@invalid.invalid> writes
>>jacob navia said:
>>
>>> Visual studio conforms to the obsolete C standard of 1989.
>>
>>The 1989 Standard is far from obsolete. It is still the current de facto
>>Standard,
>
> I think you mean ISO 9899:1990 + A1 and the TC's aka C95
>
> C89 is a local US standard that was superseded by the ISO standard in
> 1990.

Yes, but the 1989 ANSI standard and the 1990 ISO standard are
virtually identical; the only differences are the section numbers and
some non-normative introductory material.  A conforming C89 compiler
is a conforming C90 compiler, and vice versa.

As for C95, that raises a (possibly) interesting question.  Are there
any C implementations currently in significant use that support C90
but not C95?  Does the use of features introduced in C95 make code
significantly non-portable?

>> and will remain so until C99 is widely implemented. That day
>>appears to be some way off - the GNU people have shied away from full
>>conformance to C99, and Microsoft have ignored it completely.
>>
>>The C Standard is of no value unless it enables us to write portable code.
>
> I don't agree there. There are few truly portable apps. However I agree
> that the c standard is of little use unless the language as defined in
> the standard is of use and implimentable in the majority of compilers.
> Or the majority of it implimentable in All compilers.
>
>>C99 features are, quite simply, not even remotely as portable as C89
>>features.
>
> Neither, it appears,  are they wanted by the majority.

In my opinion, features defined by either the C90 or C99 standard are
perfectly appropriate for discussion here.  (I don't quite share
Richard's disdain for C99.)  On the other hand, it's also perfectly
appropriate to point out that certain features are defined in C99 but
not in C90 or C95, and that code that depends on C99 features is less
portable than code that doesn't.  On this point, I strongly disagree
with jacob; C90 is *not* obsolete.

I'd be happier if C99 had caught on more widely, and C90 were
relegated to the same kind of historical discussion as pre-ANSI K&R C
(which is still a legitimate topic here).  But that's not the reality,
and it's foolish to pretend that it is.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
```
 0
Reply kst-u (21545) 5/19/2006 7:31:28 PM

```"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnbqttvmjz.fsf@nuthaus.mib.org...

> Chris Hills <chris@phaedsys.org> writes:
>> In article <QoKdnfmukN9k8vDZRVnyhQ@bt.com>, Richard Heathfield
>> <invalid@invalid.invalid> writes
>>>jacob navia said:
>>>
>>>> Visual studio conforms to the obsolete C standard of 1989.
>>>
>>>The 1989 Standard is far from obsolete. It is still the current de facto
>>>Standard,
>>
>> I think you mean ISO 9899:1990 + A1 and the TC's aka C95
>>
>> C89 is a local US standard that was superseded by the ISO standard in
>> 1990.
>
> Yes, but the 1989 ANSI standard and the 1990 ISO standard are
> virtually identical; the only differences are the section numbers and
> some non-normative introductory material.  A conforming C89 compiler
> is a conforming C90 compiler, and vice versa.
>
> As for C95, that raises a (possibly) interesting question.  Are there
> any C implementations currently in significant use that support C90
> but not C95?  Does the use of features introduced in C95 make code
> significantly non-portable?

Yes to both. See:

http://www.dinkumware.com/conform_c.html

It's several years old now, but still remarkably accurate. Note that
C++98 requires C95, not just C90; very few Standard C++ libraries
conform in this area, however, because they depend on the underlying
C library to deliver the goods.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

```
 0
Reply pjp (713) 5/19/2006 7:49:07 PM

```"Richard Heathfield" <invalid@invalid.invalid> wrote
> pete said:
>
>> Richard Heathfield wrote:
>>
>>> C99 features are, quite simply, not even remotely as portable as C89
>>> features.
>>
>> I like the added restrictions of C99, such as no implicit int
>> and requiring protypes for all functions.
>
> Likewise. Shame about the return value from main, but I stick it in
> anyway,
> of course.
>
Implicit int was a fossil and it's time it went.
However prototypes are just a nuisance. There's some case for them in a
header file, where they describe the interface to the file, but the only
reason for them in other places is to allow the compiler to check arguments
on one pass. A modern compiler should be intelligent enough to do this
without a prototype to help it along.
--
www.personal.leeds.ac.uk/~bgy1mm

```
 0
Reply regniztar (3128) 5/20/2006 8:16:15 AM

```

"Chris Hills" <chris@phaedsys.org> wrote in message
news:sfYJ0cBNAabEFAmK@phaedsys.demon.co.uk...
> In article <S7mdnUEUPumgD_DZnZ2dnUVZ8qadnZ2d@bt.com>, Richard Heathfield
> <invalid@invalid.invalid> writes
>>jacob navia said:
>>
>>> Richard Heathfield a �crit :
>>>> jacob navia said:
>>>>
>>>>
>>>>>There are C99 compilers under windows, and under Unix.
>>>>
>>>>
>>>> ROTFL! Well, that's all right then!
>>>>
>>>
>>> Those are the operating systems mentioned in the original poster's
>>> message.
>>
>>He also mentioned the Mac.
>>
>>> You speak about "portability", as it was necessary for every piece of
>>> code to be potentially portable to all possible machines.
>>
>>The general assumption in comp.lang.c is that the code is targeted at a
>>hosted implementation
>
> Only by some people.
>
> The other thing to consider is that the majority of C implimentations
> are more likely to be in the embedded space (there are probably at least
> 4 compilers for any embedded target and dozens of targets) since AFAIK
> most desktop systems have moved to C++, C# and C++/CLI  etc
>
Also at the other end.
Parallel machines use MPI (Message Passing Interface) these days as the
standard. It comes in C or, you've guessed, it, Fortran 77. So those are the
languages I use.
--
www.personal.leeds.ac.uk/~bgy1mm

```
 0
Reply regniztar (3128) 5/20/2006 8:22:37 AM

```"jacob navia" <jacob@jacob.remcomp.fr> wrote
> Richard Heathfield a �crit :
>> jacob navia said:
>
> "Portability" for you means "taking the worst features of each
> implementation".
>
That's inevitable. The convoy travels at the speed of the slowest ship.

--
www.personal.leeds.ac.uk/~bgy1mm

```
 0
Reply regniztar (3128) 5/20/2006 8:25:54 AM

```Malcolm a �crit :
> "Richard Heathfield" <invalid@invalid.invalid> wrote
>
>>pete said:
>>
>>
>>>Richard Heathfield wrote:
>>>
>>>
>>>>C99 features are, quite simply, not even remotely as portable as C89
>>>>features.
>>>
>>>I like the added restrictions of C99, such as no implicit int
>>>and requiring protypes for all functions.
>>
>>Likewise. Shame about the return value from main, but I stick it in
>>anyway,
>>of course.
>>
>
> Implicit int was a fossil and it's time it went.
> However prototypes are just a nuisance. There's some case for them in a
> header file, where they describe the interface to the file, but the only
> reason for them in other places is to allow the compiler to check arguments
> on one pass. A modern compiler should be intelligent enough to do this
> without a prototype to help it along.

To know the argument for a function without prototypes the compiler
should have the source code for all functions, including those in the
libraries the program is using. This would imply that the source code
for all the system would have to be processed, loaded into memory,
before any checks could be done.

This is completely impossible, so *some* type of prototype declaration
is needed. In Pascal you have the 'interface' declarations, in C# you
have a similar construct... etc!

```
 0
Reply jacob (2538) 5/20/2006 1:58:17 PM

```On 2006-05-20, jacob navia <jacob@jacob.remcomp.fr> wrote:
> Malcolm a �crit :
>> Implicit int was a fossil and it's time it went.
>> However prototypes are just a nuisance. There's some case for them in a
>> header file, where they describe the interface to the file, but the only
>> reason for them in other places is to allow the compiler to check arguments
>> on one pass. A modern compiler should be intelligent enough to do this
>> without a prototype to help it along.
>
> Please think a bit Malcom.
>
> To know the argument for a function without prototypes the compiler
> should have the source code for all functions, including those in the
> libraries the program is using. This would imply that the source code
> for all the system would have to be processed, loaded into memory,
> before any checks could be done.
>
> This is completely impossible, so *some* type of prototype declaration
> is needed. In Pascal you have the 'interface' declarations, in C# you
> have a similar construct... etc!
>
Not to mention the fact that maintenance programmers want a prototype
to give them some idea of how a function works!

--
Andrew Poelstra  < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
Get your game faces on, because this is not a game.
```
 0
Reply apoelstra (387) 5/20/2006 5:12:32 PM

```"jacob navia" <jacob@jacob.remcomp.fr> wrote
> Malcolm a �crit :
>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>>
>> However prototypes are just a nuisance. There's some case for them in a
>> header file, where they describe the interface to the file, but the only
>> reason for them in other places is to allow the compiler to check
>> arguments on one pass. A modern compiler should be intelligent enough to
>> do this without a prototype to help it along.
>
> Please think a bit Malcom.
>
> To know the argument for a function without prototypes the compiler should
> have the source code for all functions, including those in the libraries
> the program is using. This would imply that the source code for all the
> system would have to be processed, loaded into memory, before any checks
> could be done.
>
> This is completely impossible, so *some* type of prototype declaration is
> needed. In Pascal you have the 'interface' declarations, in C# you have a
> similar construct... etc!
>
The library should contain information about the signature of the functions
it contains.

The problem might be the weight of libraries without this feature, and no
way of retrieving information from them.
--
www.personal.leeds.ac.uk/~bgy1mm

```
 0
Reply regniztar (3128) 5/21/2006 9:13:09 AM

```Malcolm said:

> "jacob navia" <jacob@jacob.remcomp.fr> wrote
>> Malcolm a �crit :
>>> "Richard Heathfield" <invalid@invalid.invalid> wrote

No, Richard Heathfield didn't write any of the stuff quoted in your article.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/21/2006 7:55:18 PM

```"Richard Heathfield" <invalid@invalid.invalid> wrote in message
news:0KWdnbbHmZnlWO3ZnZ2dnUVZ8sidnZ2d@bt.com...
> Malcolm said:
>
>> "jacob navia" <jacob@jacob.remcomp.fr> wrote
>>> Malcolm a �crit :
>>>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>
> No, Richard Heathfield didn't write any of the stuff quoted in your
> article.
>
Think of the attribution lines as prototypes.
Initially I included the bit about implicit int, but then I realised that
mentioned that point, so I snipped it. But I forgot to update the

That's the problem when you have information in two places at once.
--
www.personal.leeds.ac.uk/~bgy1mm

```
 0
Reply regniztar (3128) 5/21/2006 9:53:21 PM

```Richard Heathfield wrote:

> Malcolm said:
>
> > "jacob navia" <jacob@jacob.remcomp.fr> wrote
> >> Malcolm a �crit :
> >>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>
> No, Richard Heathfield didn't write any of the stuff quoted in your
> article.

You going to sue him?

Brian

```
 0
Reply defaultuserbr (3657) 5/21/2006 10:24:46 PM

```Default User said:

> Richard Heathfield wrote:
>
>> Malcolm said:
>>
>> > "jacob navia" <jacob@jacob.remcomp.fr> wrote
>> >> Malcolm a �crit :
>> >>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>>
>> No, Richard Heathfield didn't write any of the stuff quoted in your
>> article.
>
> You going to sue him?

I wasn't planning on it, no. I don't consider litigation to be the best way
to settle Usenet disagreements.

But having said that... with a name like Malcolm, he's probably Scottish -
so maybe I'll make an exception in his case. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 5/21/2006 10:47:56 PM

```In article <0KWdnbbHmZnlWO3ZnZ2dnUVZ8sidnZ2d@bt.com>,
Richard Heathfield  <invalid@invalid.invalid> wrote:

>Malcolm said:
>
>> "jacob navia" <jacob@jacob.remcomp.fr> wrote
>>> Malcolm a �crit :
>>>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>
>No, Richard Heathfield didn't write any of the stuff quoted in your article.
>

and I didn't have anything to do with prior articles in this thread.

Also, this is off-topic for comp.lang.c.  Is there a alt.flame.attributions?

Gordon L. Burditt
```
 0

```Gordon Burditt wrote:
> In article <0KWdnbbHmZnlWO3ZnZ2dnUVZ8sidnZ2d@bt.com>,
> Richard Heathfield  <invalid@invalid.invalid> wrote:
>
>> Malcolm said:
>>
>>> "jacob navia" <jacob@jacob.remcomp.fr> wrote
>>>> Malcolm a �crit :
>>>>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>> No, Richard Heathfield didn't write any of the stuff quoted in your article.
>>
>
> and I didn't have anything to do with prior articles in this thread.
>
> Also, this is off-topic for comp.lang.c.  Is there a alt.flame.attributions?

It was a simple case of forgetting to do a final snip after deleting the
last piece of Richard's text. It did not lead to major disputes the way
you claim.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
```
 0
Reply spam331 (4024) 6/3/2006 2:11:08 PM

```Gordon Burditt wrote:
> Richard Heathfield  <invalid@invalid.invalid> wrote:
>> Malcolm said:
>>> "jacob navia" <jacob@jacob.remcomp.fr> wrote
>>>> Malcolm a �crit :
>>>>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>>
>> No, Richard Heathfield didn't write any of the stuff quoted in
>
> and I didn't have anything to do with prior articles in this thread.

If you look back at the original (long gone from here), you will
find their is no material preceded by n+1 '>'s, where n is the
number of '>'s preceding the Heathfield attribution.  The system is
self correcting, and has sufficient redundancy to detect careless
snipping, as above.

Proper netiquette is always topical.  Think correcting children.

--
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

```
 0
Reply cbfalconer (19183) 6/3/2006 3:16:41 PM

```2006-06-03 <12831rnsbri580b@corp.supernews.com>, Gordon Burditt wrote:
> In article <0KWdnbbHmZnlWO3ZnZ2dnUVZ8sidnZ2d@bt.com>,
> Richard Heathfield  <invalid@invalid.invalid> wrote:
>
>
>
>>Malcolm said:
>>
>>> "jacob navia" <jacob@jacob.remcomp.fr> wrote
>>>> Malcolm a �crit :
>>>>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>>
>>No, Richard Heathfield didn't write any of the stuff quoted in your article.
>>
>
> and I didn't have anything to do with prior articles in this thread.

The problem is that your solution [snip all attributions] is worse than
the problem. You should ONLY snip attributions that don't apply to
quoted text.
```
 0
Reply random21 (344) 6/3/2006 5:28:41 PM

```gordonb.38ch9@burditt.org (Gordon Burditt) writes:
> In article <0KWdnbbHmZnlWO3ZnZ2dnUVZ8sidnZ2d@bt.com>,
> Richard Heathfield  <invalid@invalid.invalid> wrote:
>
>>Malcolm said:
>>
>>> "jacob navia" <jacob@jacob.remcomp.fr> wrote
>>>> Malcolm a �crit :
>>>>> "Richard Heathfield" <invalid@invalid.invalid> wrote
>>
>>No, Richard Heathfield didn't write any of the stuff quoted in your article.
>>
>
> and I didn't have anything to do with prior articles in this thread.

Somebody made the minor mistake of failing to snip a single
attribution line after having snipped all the corresponding text.
Richard pointed it out, and the whole thing was resolved without
threats or lawsuits.

You, on the other hand, repeatedly, consistently, and *deliberately*
make the far worse mistake of snipping all attributions, making
discussions more difficult to follow for everyone.  I don't quite
agree with CBFalconer's statement in another thread that this is
plagiarism, but it is extremely rude.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
```
 0
Reply kst-u (21545) 6/3/2006 7:50:21 PM

```Keith Thompson wrote:
>
.... snip ...
>
> You, on the other hand, repeatedly, consistently, and *deliberately*
> make the far worse mistake of snipping all attributions, making
> discussions more difficult to follow for everyone.  I don't quite
> agree with CBFalconer's statement in another thread that this is
> plagiarism, but it is extremely rude.

I said it "was tantamount to plagiarism".  Several nits there.

--
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

```
 0
Reply cbfalconer (19183) 6/3/2006 8:30:58 PM

```[Attributions have received a shave and a haircut.]

Gordon Burditt said:
> Richard Heathfield wrote:
>>Malcolm said:
>>> jacob navia wrote
>>>> Malcolm a �crit :
>>>>> "Richard Heathfield" wrote
>>
>>No, Richard Heathfield didn't write any of the stuff quoted in your
>>article.
>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
```
 0
Reply invalid171 (6614) 6/3/2006 9:29:18 PM

```CBFalconer <cbfalconer@yahoo.com> writes:
> Keith Thompson wrote:
>>
> ... snip ...
>>
>> You, on the other hand, repeatedly, consistently, and *deliberately*
>> make the far worse mistake of snipping all attributions, making
>> discussions more difficult to follow for everyone.  I don't quite
>> agree with CBFalconer's statement in another thread that this is
>> plagiarism, but it is extremely rude.
>
> I said it "was tantamount to plagiarism".  Several nits there.

You also wrote:

| As I pointed out, quoting without attribution is effectively
| plagiarism.  Every newsreader of which I am aware will construct the
| attribution lines automatically.  There is no need to steal the
| words of others.

which is a stronger claim than "tantamount to plagiarism".

If he were posting others' remarks without marking them as quotations,
making them appear to be his own words, that would be plagiarism.  In
my humble opinion, what he's actually doing is merely rude; there's no
appearance that other poster's words are actually his.

But I acknowedge that you didn't say that it actually *is* plagiarism,
and I don't think it's that important a point anyway.  Plagiarism is a
legal term, and nobody is seriously threatening legal action.  We're
both in complete agreement that he needs to stop snipping attributions
and/or give us a decent explanation (which he has so far failed to
do).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
```
 0
Reply kst-u (21545) 6/3/2006 10:00:13 PM

54 Replies
58 Views

Similiar Articles:

7/24/2012 8:42:40 AM