«

"E. Robert Tisdale" <> writes:
> Keith Thompson wrote:
>
> > I've removed comp.std.c and gnu.gcc.help from the Newsgroups header,
> > leaving just comp.lang.c.
>
> I don't understand why you did this.
> It seems to me that your interpretation of the standard
> would benefit from some scrutiny in the comp.std.c newsgroup.
> It seems to me that your claim that there is a bug in the GNU C compiler
> should be discussed in the gnu.gcc.help newsgroup.

First, because I was annoyed that you had added these newsgroups
without bothering to mention it in the body of your message.

Second, I deleted comp.std.c because I felt that this is more a
discussion about the language than about the standard (though I'm not
as certain of that; see below), and I deleted gnu.gcc.help because gcc
is just one of a number of compilers we're discussion, it's not yet
clear to me that gcc has a bug, and gnu.gcc.help probably isn't the
proper forum for gcc bug reports anyway.

As for comp.std.c, I've started a new thread there, subject "Empty
macro arguments", since I now think that there may be an ambiguity in
the wording in the standard itself. No, I haven't been entirely
consistent about whether this discussion belongs in comp.std.c, mostly
because I've seen new issues as the discussion has progressed.

[...]

> > If you have some basis for assuming that
> > the compilers that accept your program are correct, please say so.
>
> Wait a minute. Why were you assuming that
> the compilers that accepted my program were incorrect?

At this point, I'm not assuming anything. When I wrote the above, I
assumed that the compilers were incorrect because they violated my
interpretation of the wording of the standard. At this point, I
believe that (a) the authors of the standard intended your example to
be valid, but (b) they failed to clearly express this intent in the
normative wording of the standard. See the new thread in comp.std.c
for more details.

[...]
> This is what GNU says about C preprocessor macro arguments:
[...]

> The GNU documentation
> does *not* say anything about this being an "extension".
> Evidently, they believe that it is standard.

Ok, I believe that the authors of gcc believe that it's standard.
They're smart folks; they could well be right. What do *you* think,
and can you support your opinion by citing the normative wording of
the standard?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Keith Thompson wrote:

> Ok, I believe that the authors of gcc believe that it's standard.
> They're smart folks; they could well be right.
> What do *you* think, and can you support your opinion
> by citing the normative wording of the standard?

I'm not a language lawyer.
I don't even try to interpret the standards documents.
When I have questions about the standard,
I consult the experts in the comp.std.c newsgroup
as you have done today.

The standards documents are not always a reliable resource
as your experience with this subject illustrates.
They won't make you a much better C programmer.
Reading standards documents to learn how to program is a little like
reading law books to learn how to defend yourself in court --
not generally a good idea.

Also, you need to remember that
standards documents are *not* Holy Scripture.
The were written by mere mortals and fail in many ways.

There are really two standards:

1. the standard de jure

http://en.wikipedia.org/wiki/De_jure and

2. the de facto standard

http://en.wikipedia.org/wiki/De_facto_standard

The standard de jure (as defined by the standards documents)
are meant to *guide* and *influence* the de facto standard
(as defined by implementations and programmers).
The standards documents are *not* language design documents.
At best, they attempt to articulate the de facto standard.
Specifying new language features not already implemented
as language extensions by some C compiler
is a prescription for disaster.

Don't get me wrong.
I think that it's OK to consult the standards documents
but they should *not* be your sole source of information.
At the very least, you need to experiment with one
implementation and, preferably, with several implementations
before coming to any conclusion about the standard.

"E. Robert Tisdale" <> wrote in message news:<>...
> Keith Thompson wrote:
....
> Also, you need to remember that
> standards documents are *not* Holy Scripture.
> The were written by mere mortals and fail in many ways.

Certainly the standards documents can and do contain defects. However,
they have one important characterstic that is very similar to a
characteristic that believers think the Hold Scripture possesses:
insofar as it defines the C language, the C standard can't be wrong.
It defines what C is. That definition might be inconsistent, or
useless, or unimplementable, or in conflict with the Committee's
intent, but it can't be wrong, because there's no "right" it can be
compared with.

> There are really two standards:
>
> 1. the standard de jure
>
> http://en.wikipedia.org/wiki/De_jure and
>
> 2. the de facto standard
>
> http://en.wikipedia.org/wiki/De_facto_standard
>
> The standard de jure (as defined by the standards documents)
> are meant to *guide* and *influence* the de facto standard
> (as defined by implementations and programmers).

Your de facto "standard" lacks one key feature that real standards
have to possess: standardization. It can't be a standard if it's not
de-jure. It's just a description of common features that real-world
implementations possess. It's like talking about a "de facto felony" -
the law defines what a felony is; the word has no meaning other than
it's de jure meaning.

You can compile C99 programs on-line at:

http://www.comeaucomputing.com/tryitout/

Your test program:

#include <stdio.h>
#define str(x) # x
int main(void) {
char c[2][6] = { str(hello), str() };
printf("c[0] = \"%s\"\n", c[0]);
printf("c[1] = \"%s\"\n", c[1]);
return 0;
}

compiles without complaint:

> Your Comeau C/C++ test results are as follows:
>
> Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
> Copyright 1988-2003 Comeau Computing. All rights reserved.
> MODE:strict errors C99

According to Greg Comeau

http://www.comeaucomputing.com/

"This combination of Comeau and Dinkumware is as close as you can get
to full compliance with Standard C++ from 2003 or 1998, Standard C
from 1999 (aka C99) and Standard C from 1990 (aka C90)."

This is *much* more reliable than
your personal interpretation of the ANSI/IOS C 99 standard.

"E. Robert Tisdale" <> writes:
[snip]

According to the References header, this was a response to something I
posted. You did not mention my name, quote anything I wrote, or even
retain the subject header of the article to which you were responding.

If you want to discuss something with me, you should know how to do
so. If you're not willing to make it clear what or whom you're
responding to, I'm not going to waste my time.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Keith Thompson wrote:

> If you want to discuss something with me, you should know how to do
> so. If you're not willing to make it clear what or whom you're
> responding to, I'm not going to waste my time.


What if he wants to troll CLC and stir up trouble?



Brian Rodenborn

Something that call itself Default User wrote:

[snip]

Go away troll.

"E. Robert Tisdale" <> wrote in message
news:...
> Something that call itself Default User wrote:
>
> [snip]
>
> Go away troll.
>

I was following this and a number of recent threads with great interest.
I have to give credit where it is due. ERT's performance on this thread
and others has been exceptionally respectable and accurate. Not only
has he given accurate technical answers but also shown very precise
feeling for trolls, intending to derail discussion by carping on
irrelevencies.

Bravo ERT!!!

I am however still looking for you to complete answer to my original post
on accessing variable size fields of a structure via your offsetOf
function.

c-turtle
--
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv vvvvvvvvvvvvv
flames > /dev/null
I respect you, you respect me - my right to use remailer without abuse.
Courtesy & Sincerity will be returned in kind -- a most workable
nettiquette.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^

-=-
This message was posted via two or more anonymous remailing services.