On Wed, 31 Jan 2001, Peter Ajamian wrote:
> Absolutely not, since any program that conforms to the old ANSI
> standard will also conform to the newer C99 standard how can I
> possibly be advocating non-conformance to C99 by advocating
> conformance to the older ANSI?
Because you're advocating avoidance of C99-specific features that are
recommended for use. See 'restrict' pointers, which are recommended where
appropriate. You're saying, "Avoid using anything C99-specific." Now,
you can split hairs all you want and say that because C99 is inclusive of
C89, you're still conforming to C99. But that's a technicality and a
rather useless point. If you're only using aspects of C89, then you're
conforming to C89 and avoiding the C99 standard.
> It's not a matter of it being "thier kick", some people have little
> choice in the matter.
I meant porting the code to their legacy platform, not using the legacy
platform. If that's their kick, they're free to do it. Supporting these
platforms sacrifices too much for too little.
> By "the opposite" I mean that any program which conforms to C99 will
> also conform to ANSI which most ceartainly is _not_ true.
I know what you meant. It can be true. For instance:
#ifndef HAS_RESTRICT
#ifdef HAS_SUN_RESTRICT
#define restrict __restrict
#else
#define restrict
#endif
#endif
int main()
{
some_type *restrict ptr;
. . .
}
conforms to both C99 and C89. The behavior is not strictly the same, but
the program will work right in both cases.
> They are created with the expressed intent of allowing for
> portability.
And they aren't adhered to strictly by most platforms. Note the huge
amount of portability hacks and kluges CircleMUD employs (by way of
configure). The majority of these address some platforms failure to
conform to some standard or another. In a utopia, standards have
everything to do with portability. In the real world, standards aren't
adhered to strictly, sometimes for "good" reasons, sometimes for "bad"
reasons, sometimes for no reason. Portability, then, often requires
ignoring, bypassing, or working around standards.
> If there is a significant advantage to be had. I still haven't seen
> one.
The advantage is that they want to. That they prefer it. And that they
can do it how they want according to the new standard. That's more
significant than any advantage I'll be able to convince you of, here.
> If there's any possibility of having to port to a platform without a
> C99 compiler then I would find it much preferable to keep my code
> conforming to the older ANSI standard now than to have to drudge
> through the code later and fix all the non-compliant parts.
Which is why you make a note of that (as I did) and let them decide for
themselves what to do. And if they make what is ultimately the wrong
decision, then they'll learn from it.
> I never said they were, however, standards are made to allow for
> portability.
But, you see, you are saying it. Regardless of what standards are made
for, the fact stands: standards don't necessarily get you portability,
portability doesn't necessarily get you standards. Standards and
portability are not one in the same.
-dak
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/03/01 PST