why still use C?

[Mike Cowlishaw]

Re: Decimal Floating Point (was Re: why still use C?)

>>>> There are a few constraints, though. For example, the ISO[color=blue][color=green][color=darkred]
>>>> COBOL 2002 standard specifies that intermediate calculations
>>>> be done using 32 decimal digits of precision. 32 digits of BCD
>>>> into a 128-bit register leaves very little room for a sign and
>>>> exponent.
>>>
>>> I still have never written a COBOL program, but is that fixed point
>>> or floating point?[/color]
>>
>> 'Standard' COBOL arithmetic. Calculate as well as possible and then
>> assign to a fixed-point variable. Best ask COBOL folk what that is
>> :-).[/color]
>
> As you say COBOL requires 32 decimal digits of precision. Would that
> be _exactly_ 32 digits of precision or _at least_ 32 digits of
> precision? I think producing _exactly_ 32 digits if what you have
> available is 34 digits could be difficult.[/color]

I forget the actual wording. The final draft is on the web, somewhere,
if you want to check.

Mike Cowlishaw
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[David R Tribble]

Re: Decimal Floating Point (was Re: why still use C?)

"Mike Cowlishaw" <mfcowli@attglo bal.net> wrote[color=blue][color=green][color=darkred]
>>> There are a few constraints, though. For example, the ISO
>>> COBOL 2002 standard specifies that intermediate calculations
>>> be done using 32 decimal digits of precision. 32 digits of BCD
>>> into a 128-bit register leaves very little room for a sign and
>>> exponent.[/color][/color][/color]
[color=blue][color=green][color=darkred]
>>> I still have never written a COBOL program, but is that fixed point
>>> or floating point?[/color][/color][/color]
[color=blue][color=green]
>> 'Standard' COBOL arithmetic. Calculate as well as possible and then
>> assign to a fixed-point variable. Best ask COBOL folk what that is
>> :-).[/color][/color]
[color=blue][color=green]
>> As you say COBOL requires 32 decimal digits of precision. Would that
>> be _exactly_ 32 digits of precision or _at least_ 32 digits of
>> precision? I think producing _exactly_ 32 digits if what you have
>> available is 34 digits could be difficult.[/color][/color]
[color=blue]
> I forget the actual wording. The final draft is on the web, somewhere,
> if you want to check.[/color]

This precision requirement could be based on IBM's COBOL arithmetic, which
uses 30 or 31 decimal digits (I don't remember which) for all intermediate
results in fixed-point arithmetic expressions. If any floating-point
values are present in a given expression, the whole thing is done in
floating-point instead.

Anyway, 30 or 31 BCD digits plus a sign nibble fit quite naturally into
128 bits (16 bytes). IBM stipulated additional rules for handling gradual
loss of precision (i.e., truncation of least sigificant digits) for the
arithmetic operators, so that no high-order digits are lost (this differs
from PL/1 semantics).

It just so happens that IBM 360 (370, 390, etc.) hardware directly supports
signed BCD arithmetic of up to 31 digits (as do some other systems, e.g.
VAX).

-drt
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Mike Cowlishaw]

Re: Decimal Floating Point (was Re: why still use C?)

David R Tribble wrote:[color=blue]
> "Mike Cowlishaw" <mfcowli@attglo bal.net> wrote[color=green][color=darkred]
>>>> There are a few constraints, though. For example, the ISO
>>>> COBOL 2002 standard specifies that intermediate calculations
>>>> be done using 32 decimal digits of precision. 32 digits of BCD
>>>> into a 128-bit register leaves very little room for a sign and
>>>> exponent.[/color][/color]
>[color=green][color=darkred]
>>>> I still have never written a COBOL program, but is that fixed point
>>>> or floating point?[/color][/color]
>[color=green][color=darkred]
>>> 'Standard' COBOL arithmetic. Calculate as well as possible and
>>> then assign to a fixed-point variable. Best ask COBOL folk what
>>> that is :-).[/color][/color]
>[color=green][color=darkred]
>>> As you say COBOL requires 32 decimal digits of precision. Would that
>>> be _exactly_ 32 digits of precision or _at least_ 32 digits of
>>> precision? I think producing _exactly_ 32 digits if what you have
>>> available is 34 digits could be difficult.[/color][/color]
>[color=green]
>> I forget the actual wording. The final draft is on the web,
>> somewhere, if you want to check.[/color]
>
> This precision requirement could be based on IBM's COBOL arithmetic,
> which uses 30 or 31 decimal digits (I don't remember which) for all
> intermediate results in fixed-point arithmetic expressions. If any
> floating-point values are present in a given expression, the whole
> thing is done in floating-point instead.
>
> Anyway, 30 or 31 BCD digits plus a sign nibble fit quite naturally
> into 128 bits (16 bytes). IBM stipulated additional rules for
> handling gradual loss of precision (i.e., truncation of least
> sigificant digits) for the arithmetic operators, so that no
> high-order digits are lost (this differs from PL/1 semantics).
>
> It just so happens that IBM 360 (370, 390, etc.) hardware directly
> supports signed BCD arithmetic of up to 31 digits (as do some other
> systems, e.g. VAX).[/color]

We're talking about COBOL 2002. This specifies 32-digit
intermediate results, not 31. (The conspiracy theorists suggest
that this is so that IBM BCD hardware cannot be used :-).)

mfc


[color=blue]
>
> -drt[/color]
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Clark S. Cox III]

Re: why still use C?

On 2003-10-12 18:49:40 -0400, Jerry Feldman <gaf-noSPAM@blu.orgs aid:

On 08 Oct 2003 05:35:19 GMT
"cody" <dont.spam.me.d eutronium@gmx.d ewrote:
>

>i though in standard C, there isn't such a thing like "const" you can
>only use macros to fake them.

Maybe you should read the standard. The const keyword is certainly
defined, but it has a different meaning
than in C++. const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf = (int *)&foo;
*pf = x;

You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Robert Seacord]

Re: why still use C?

Clark,

Comment/question below.

>const int foo = 4;
>In C, foo is a variable and will be treated as such. int *pf =
>(int *)&foo;
> *pf = x;

>
You are mistaken. You cannot legally do that in either language.
>
From the standard:
>
6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

I lifted the following example from c99 6.5.16.1 Simple assignment:

const char **cpp;
char *p;
const char c = 'A';

printf("c = %c.\n", c);

cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid

printf("c = %c.\n", c);

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.

gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

rCs
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Flash Gordon]

Re: why still use C?

[mod note: I received something like 200 submissions of this post, and
there's no contact address for the author. This is the second or third time.
If I can't contact someone, I will happily just add mail filters to deal
with stuff like this. Be contactable. -mod]

Robert Seacord wrote:

Clark,
>
Comment/question below.
>

>>const int foo = 4;
>>In C, foo is a variable and will be treated as such. int *pf =
>>(int *)&foo;
>> *pf = x;

>You are mistaken. You cannot legally do that in either language.
>>
>From the standard:
>>
>6.7.3 5
>"If an attempt is made to modify an object defined with a
>const-qualified type through use of an lvalue with non-const-qualified
>type, the behavior is undefined."

>
I lifted the following example from c99 6.5.16.1 Simple assignment:
>
const char **cpp;
char *p;
const char c = 'A';
>
printf("c = %c.\n", c);
>
cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid
>
printf("c = %c.\n", c);
>
It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.

In that case you need to make sure you are compiling it as C code and
make sure you have told the compiler to follow the C standard. I don't
currently have my Windows notebook with me to test it myself since it
did not catch the same plain as me.

gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

The C standard does not mandate that programs fail to compile after
producing and required diagnostics (Warnings, Information messages,
Error, insults about your coding abilities, and of these could be issued
as a "diagnostic "). Also, once undefined behaviour is invoked, the
program is allowed to do anything. One of the infinitely many "any
things" it can do is exactly what you expect. However, tomorrow it might
not change the value of C, or after you upgrade the compiler the
behaviour might change (this does happen to people), or it might decide
to report you to the CIA for spying.

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

At its simplest, a constraint violation is where the standard places a
constraint (limitation) on what you are allowed in your code, and you
violate that constraint in your code.

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

See above. Any form of "diagnostic " message is allowed, even something like:
Write out 1000 time "I will not write code with errors"
The compiler could even just fart in your general direction.

After issuing some form of message the compiler is allowed to continue
to compiler the program (although it does not matter what the program
then does) or reject the program.
--
Flash Gordon
Still sigless on this computer.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Keith Thompson]

Re: why still use C?

Robert Seacord <rcs@sei.cmu.ed uwrites:
[...]

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.
>
But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

C99 5.1.1.3p1:

A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner) if a
preprocessing translation unit or translation unit contains a
violation of any syntax rule or constraint, even if the behavior
is also explicitly specified as undefined or
implementation-defined. Diagnostic messages need not be produced
in other circumstances.

Footnote:

The intent is that an implementation should identify the nature
of, and where possible localize, each violation. Of course, an
implementation is free to produce any number of diagnostics as
long as a valid program is still correctly translated. It may also
successfully translate an invalid program.

So a compiler is allowed to produce a non-fatal warning in response to
a constraint violation.

--
Keith Thompson (The_Other_Keit h) 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.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[kuyper@wizard.net]

Re: why still use C?

Robert Seacord wrote:
....

I lifted the following example from c99 6.5.16.1 Simple assignment:
>
const char **cpp;
char *p;
const char c = 'A';
>
printf("c = %c.\n", c);
>
cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid
>
printf("c = %c.\n", c);
>
It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.
>
gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.
>
I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.
>
But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

When a translation unit (TU) contains one or more constraint
violations, a diagnostic message is mandatory. That's the single most
important thing you need to know about constraint violations. It's
usually the case that when there's a constraint violation, the behavior
is undefined and the program is not strictly conforming (but I suspect
that there might be subtle cases where this isn't true). Therefore,
terminating translation of a TU is permitted. However, it's not
mandatory. The only case where the C standard prohibits an
implementation from translating a TU is if it contains a #error
directive which survives conditional compilation.
As a practical matter, changing the value of an object declared
constant is a problem only in two cases:
1. The implementation places the object in read-only memory.
2. The implementation makes optimizations based upon the assumption
that the value of the object can't change.

If neither of those cases applies, and the compiler chooses to
translate your program, and you choose to execute it, it might even
work as you might expect it to work. You shouldn't be surprised by that
result; but I would not recommend counting on it.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Clark S. Cox III]

Re: why still use C?

On 2006-08-18 04:53:41 -0400, Robert Seacord <rcs@sei.cmu.ed usaid:

Clark,
>
Comment/question below.
>

>>const int foo = 4;
>>In C, foo is a variable and will be treated as such. int *pf =
>>(int *)&foo;
>>*pf = x;

>>
>You are mistaken. You cannot legally do that in either language.
>>
>From the standard:
>>
>6.7.3 5
>"If an attempt is made to modify an object defined with a
>const-qualified type through use of an lvalue with non-const-qualified
>type, the behavior is undefined."

>
I lifted the following example from c99 6.5.16.1 Simple assignment:
>
const char **cpp;
char *p;
const char c = 'A';
>
printf("c = %c.\n", c);
>
cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid
>
printf("c = %c.\n", c);
>
It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.
>
gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.
>
I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.
>
But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?
>
rCs

Yes, according to 5.1.1.3:
"A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner) if a
preprocessing translation unit or translation unit contains a
violation of any syntax rule or constraint, even if the behavior is
also explicitly specified as undefined or implementation-defined.
Diagnostic messages need not be produced in other circumstances."

So, a conforming compiler has to at least produce a warning message
for the "cpp = &p" line. In this instance, gcc is conforming, VC++ is
not.


--
Clark S. Cox, III
clarkcox3@gmail .com
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Douglas A. Gwyn]

Re: why still use C?

Robert Seacord wrote:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified

It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.
gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.

Yes, one form of "undefined behavior" is to go ahead and produce
some kind of result, which may or may not be what the programmer
naively was expecting.

Some compilers, such as those for embedded systems, may allocate
"const"-qualified objects in a read-only program section, which
in the final product might be burned into ROM. On more general-
purpose platforms, it is possible that read-only segments of a
task image might not have the "writable" bit set in the page
descriptors, in which case attempts to write to that storage
would result in an illegal-access trap (and probably task
termination).

I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.

A "constraint violation" is a violation of some requirement
specified in a subclaused entitled "Constraint s".

But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?

Yes, constraint violations require a diagnostic.
However, the example was an instance of *undefined behavior*,
which is a different category of transgression.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Malcolm]

Re: why still use C?

"Robert Seacord" <rcs@sei.cmu.ed uwrote in message
news:clcm-20060818-0019@plethora.n et...

Clark,
>
Comment/question below.
>

>>const int foo = 4;
>>In C, foo is a variable and will be treated as such. int *pf =
>>(int *)&foo;
>> *pf = x;

>>
>You are mistaken. You cannot legally do that in either language.
>>
>From the standard:
>>
>6.7.3 5
>"If an attempt is made to modify an object defined with a
>const-qualified type through use of an lvalue with non-const-qualified
>type, the behavior is undefined."

>
I lifted the following example from c99 6.5.16.1 Simple assignment:
>
const char **cpp;
char *p;
const char c = 'A';
>
printf("c = %c.\n", c);
>
cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid
>
printf("c = %c.\n", c);
>
It compiles without warning on Microsoft Visual C++ .NET (2003) and on
MS Visual Studio 2005. In both cases, the resulting program changes the
value of c.
>
gcc version 3.2.2 generates a warning but compiles. The resulting
program changes the value of c.
>
I guess I'm wondering what a constraint violation is. I know a
constraint is defined as a restriction, either syntactic or semantic, by
which the exposition of language elements is to be interpreted.
>
But doesn't a compliant compiler need to issue a fatal diagnostic for a
constraint violation. Or maybe even a warning?
>

A compiler can accept anything and remain conforming. This is partly because
it is impossible to test that every contorted example of bad syntax will be
caught, parlty because so many compilers allow extensions.

Constraint violations are examples of "bad grammar". For instance assigning
an integer a pointer value. However often there is god reason for doing
this, because integers and pointers are often stored in exactly the same
registers, and it might be important to get the absolute value of a pointer,
for instance implementing a %p option in a printf-like function.
--

https://www.personal.leeds.ac.uk/~bgy1mm

freeware games to download.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Mark McIntyre]

Re: why still use C?

On 18 Aug 2006 08:53:41 GMT, in comp.lang.c , Robert Seacord
<rcs@sei.cmu.ed uwrote:

>>
>You are mistaken. You cannot legally do that in either language.
>>

>I lifted the following example from c99 6.5.16.1 Simple assignment:

(snip example of constraint violation)

>It compiles without warning on Microsoft Visual C++ .NET (2003) and on
>MS Visual Studio 2005.

Thats a QOI issue, and may be because you didn't set VC into
"conforming mode". Most compilers come with lots of extensions to the
standard, and you need to turn them all off.

>But doesn't a compliant compiler need to issue a fatal diagnostic for a
>constraint violation. Or maybe even a warning?

Its obligated to do so, but only if in conforming mode.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Hans-Bernhard Broeker]

Re: why still use C?

In comp.lang.c.mod erated Robert Seacord <rcs@sei.cmu.ed uwrote:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

I guess I'm wondering what a constraint violation is.

[...]

Something that has less to do with undefined behaviour than you appear
to believe. That statement up there is crystal clear: modifying a
const-qualified object, by any means expressable in C, is as illegal
as anything in a C programming context can be: it causes undefined
behaviour.

But doesn't a compliant compiler need to issue a fatal diagnostic
for a constraint violation. Or maybe even a warning?

Of course it does. So all you've just demonstrated is that MS
compilers aren't compliant with the standard (at least not in the
operational modes you tested). That's hardly newsworthy.

--
Hans-Bernhard Broeker (broeker@physik .rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Herbert Rosenau]

Re: why still use C?

On Fri, 18 Aug 2006 08:53:41 UTC, Robert Seacord <rcs@sei.cmu.ed u>
wrote:

Clark,
>
Comment/question below.
>

const int foo = 4;
In C, foo is a variable and will be treated as such. int *pf =
(int *)&foo;
*pf = x;

You are mistaken. You cannot legally do that in either language.

From the standard:

6.7.3 5
"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined."

>
I lifted the following example from c99 6.5.16.1 Simple assignment:

No example will do against the standard.

Undefined behavior lives as undefined behavior ALWAYS.

There is nothing you can do against undefined behavior as avoid it
under all circumstances.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Brian Inglis]

Re: why still use C?

On 18 Aug 2006 08:53:41 GMT in comp.lang.c.mod erated, Robert Seacord
<rcs@sei.cmu.ed uwrote:

>Clark,
>
>Comment/question below.
>

>>const int foo = 4;
>>In C, foo is a variable and will be treated as such. int *pf =
>>(int *)&foo;
>> *pf = x;

>>
>You are mistaken. You cannot legally do that in either language.
>>
>From the standard:
>>
>6.7.3 5
>"If an attempt is made to modify an object defined with a
>const-qualified type through use of an lvalue with non-const-qualified
>type, the behavior is undefined."

>
>I lifted the following example from c99 6.5.16.1 Simple assignment:
>
const char **cpp;
char *p;
const char c = 'A';
>
printf("c = %c.\n", c);
>
cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 'B'; // valid
>
printf("c = %c.\n", c);
>
>It compiles without warning on Microsoft Visual C++ .NET (2003) and on
>MS Visual Studio 2005. In both cases, the resulting program changes the
>value of c.

MS supports C89 and stated it has no intention of supporting C99.

>gcc version 3.2.2 generates a warning but compiles. The resulting
>program changes the value of c.
>
>I guess I'm wondering what a constraint violation is. I know a
>constraint is defined as a restriction, either syntactic or semantic, by
>which the exposition of language elements is to be interpreted.
>
>But doesn't a compliant compiler need to issue a fatal diagnostic for a
>constraint violation. Or maybe even a warning?

More recent versions of gcc (4+) have tightened up considerably on
what they will accept.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis@CS i.com (Brian[dot]Inglis{at}Syste maticSW[dot]ab[dot]ca)
fake address use address above to reply
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.