twitter: comp.lang.c - 25 new messages in 13 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Decreasing order of address within main - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/db5e52c59036d0d7?hl=en
* CAN I INTEREST YOU IN AN EXTRA $250.00 A DAY...? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/be1b02d307d87663?hl=en
* switch case question - 7 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/e0f2bb9e5e6540fb?hl=en
* union of structs: common variable stored in same address? - 3 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/b96dc02d740c3db8?hl=en
* variadic functions - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c36f0aa20c28fc99?hl=en
* 0ur website www.yellshoe.com wholesale $33jordan shoes,$18tshirt,15
sunglassess, $13cap,$38jean,$38 handbag - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/9dbd8b3d27fa62d8?hl=en
* can a character be negative? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/ef0336d66975924c?hl=en
* 4 Simple Tips To Earn $2,080 Weekly With Part Time Job - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/489811f12f71438e?hl=en
* "error: invalid preprocessing directive #DEFINE" - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/45e8c40b7a06745d?hl=en
* Nike dunk high shoes wholesale\retail - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/4806d2d8db5756b5?hl=en
* ♠♣♥❤ 2009 Cheap Wholesale Brand pants, Shorts,Jeans==A&F Shorts, Bape Shorts,
Evisu Shorts etc.G-Star Jeans, Ecko Unltd Jeans, Evisu Jeans etc.=== WEBSITE:
www.fjrjtrade.com <paypal payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/07cff75e91789678?hl=en
* Definition of language constructs - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/1a4e026124d09af0?hl=en
* Discount Wholesale Nike Air Max Clssic BW Air Max LTD Air Max 90 Air Max TN <
www.dotradenow.com> free shipping - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c1475ffa7ba541c7?hl=en

==============================================================================
TOPIC: Decreasing order of address within main
http://groups.google.com/group/comp.lang.c/t/db5e52c59036d0d7?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 6 2009 4:53 am
From: "Dik T. Winter"

In article <h9stps$b4p$1@news-pa1.hpl.hp.com> Chris Dollin <chris.dollin@hp.com> writes:
> Dik T. Winter wrote:
>
> > Right. But if I remember right, on the ARM memory started always at an
> > address 'below' 0 and continued to an address 'above' 0.
>
> I think that's the Transputer, not the ARM.

I think you are right.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

== 2 of 2 ==
Date: Tues, Oct 6 2009 5:07 am
From: "Dik T. Winter"

In article <87ljjtgyd7.fsf@kilospaz.fatphil.org> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> > Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> >>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
...
> >>>> Well, the first processor I used that had a multiply instruction had
> >>>> both signed and unsigned. The architecture I've used the most since
> >>>> then also had this pair. The two other architectures I've used
> >>>> extensively in that time also have them. Of the two other
> >>>> architectures I've used but not extensively programmed for, one didn't
> >>>> have a muliply at all, the other had both types. Only one architecture
> >>>> I've used that has a multiply instruction at all fails to have the
> >>>> pair.
...
> >> Close. Your presumptions are true for 4 of the 5 archs.
...
> Jeebus. I never thought that _you_ would be >this< close to being
> stuffed in my killfile. Please learn to count before posting to
> usenet again.

Let's count:
#1 had both variants
#2 also had this pair
#3 and #4 also have them
#5 had no multiply at all
#6 had both types
#7 has multiply but only one type

So I come at 5 out of 6.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

==============================================================================
TOPIC: CAN I INTEREST YOU IN AN EXTRA $250.00 A DAY...?
http://groups.google.com/group/comp.lang.c/t/be1b02d307d87663?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 5:04 am
From: "B.ambeth kar B.ambeth kar"

CAN I INTEREST YOU IN AN EXTRA $250.00 A DAY...?

Let me ask you a simple question...
Could you use some extra money?

You could! Great!
And if I could show you how to earn an extra
$250.00 or more per day, and all you'd need
to spend is a couple of hours a day at your
home computer...

Would that intrigue you?

Then read on...
Very few people know what I am going to
share with you now, and those that do are
making a nice living online.
In fact, I've earned over $25,000 since I
discovered this unique opportunity.
And no, it's not like anything else you've
seen before.
I'm going to show you numerous companies
that will pay you good money to post ads
online for them.
* You don't need any experience
* You don't need any special skills
* You don't need a marketing degree

All you need is a computer and internet access.
Let's face it, if these companies did all the work
themselves, it would take forever! That's where
you come in. Companies worldwide are bending
over backwards to find people to post ads for
them, and they'll pay you nicely in return.
Here's how it works...
* You type the ads
* You submit the ads
* You choose your own hours
* You do as many as you want, no restrictions

If you need extra cash, act now... Go straight to..

http://snipurl.com/s4ai6

==============================================================================
TOPIC: switch case question
http://groups.google.com/group/comp.lang.c/t/e0f2bb9e5e6540fb?hl=en
==============================================================================

== 1 of 7 ==
Date: Tues, Oct 6 2009 5:06 am
From: Alessio

Hi, please consider following code:

#include <stdio.h>

int main(void)
{
int i;

for ( i = 0; i < 10; i++ )
{
switch ( i )
{
case 0:
case 1:
case 2:
case 5:
printf("%d is in case!\n", i);
break;

default:
printf("%d is NOT in case!\n", i);
break;
}
}

return 0;
}

What should be correct result ?
With lcc compilier I get that 3 and 4 are "NOT in case", with PelleC
compiler I get that only 6,7,8, and 9 are "NOT in case"...

Thank you,
Alessio.

== 2 of 7 ==
Date: Tues, Oct 6 2009 5:23 am
From: jacob navia

Alessio a écrit :
> Hi, please consider following code:
>
> #include <stdio.h>
>
> int main(void)
> {
> int i;
>
> for ( i = 0; i < 10; i++ )
> {
> switch ( i )
> {
> case 0:
> case 1:
> case 2:
> case 5:
> printf("%d is in case!\n", i);
> break;
>
> default:
> printf("%d is NOT in case!\n", i);
> break;
> }
> }
>
> return 0;
> }
>
> What should be correct result ?
> With lcc compilier I get that 3 and 4 are "NOT in case", with PelleC
> compiler I get that only 6,7,8, and 9 are "NOT in case"...
>

With lcc-win I get:
0 is in case!
1 is in case!
2 is in case!
3 is NOT in case!
4 is NOT in case!
5 is in case!
6 is NOT in case!
7 is NOT in case!
8 is NOT in case!
9 is NOT in case!

and that is the correct output.

== 3 of 7 ==
Date: Tues, Oct 6 2009 6:45 am
From: Kenneth Brody

Alessio wrote:
> Hi, please consider following code:
>
> #include <stdio.h>
>
> int main(void)
> {
> int i;
>
> for ( i = 0; i < 10; i++ )
> {
> switch ( i )
> {
> case 0:
> case 1:
> case 2:
> case 5:
> printf("%d is in case!\n", i);
> break;
>
> default:
> printf("%d is NOT in case!\n", i);
> break;
> }
> }
>
> return 0;
> }
>
> What should be correct result ?
> With lcc compilier I get that 3 and 4 are "NOT in case", with PelleC
> compiler I get that only 6,7,8, and 9 are "NOT in case"...

Only 0, 1, 2, and 5 are "in case". All other numbers are "NOT in case". If
PelleC says that 3 and 4 are "in case" given the exact code above, then it's
broken.

(I am assuming that your reference to lcc with 3 and 4 means that they, _in_
_addition_ _to_ 6, 7, 8, and 9, are "NOT in case", rather than _only_ 3 and 4.)

--
Kenneth Brody

== 4 of 7 ==
Date: Tues, Oct 6 2009 7:08 am
From: Mark Bluemel

On 6 Oct, 13:06, Alessio <f...@fake.org> wrote:
> Hi, please consider following code:
>
> #include <stdio.h>
>
> int main(void)
> {
> int i;
>
> for ( i = 0; i < 10; i++ )
> {
> switch ( i )
> {
> case 0:
> case 1:
> case 2:
> case 5:
> printf("%d is in case!\n", i);
> break;
>
> default:
> printf("%d is NOT in case!\n", i);
> break;
> }
> }
>
> return 0;
>
> }
>
> What should be correct result ?

What does your reading of the language specification and/or a good
reference suggest should be the correct result?

> With lcc compilier I get that 3 and 4 are "NOT in case",

Does "lcc" generate code that reports only 3 and 4 are "NOT in case"?
If so, then it's broken. However, I suspect you mean that with lcc you
get 3,4,6,7,8,9 are "NOT in case", which is correct.

> with PelleC compiler I get that only 6,7,8, and 9 are "NOT in case"...

Then PelleC seems to be generating incorrect code.

Note: it's often clearer to post your source, the output from a
compilation and the output from a run rather than a summary like this.
To illustrate, the example below shows that gcc works as I'd expect :-

$ cat alessio.c
#include <stdio.h>
int main(void) {
int i;
for ( i = 0; i < 10; i++ ) {
switch ( i ) {
case 0:
case 1:
case 2:
case 5:
printf("%d is in case!\n", i);
break;
default:
printf("%d is NOT in case!\n", i);
break;
}
}
return 0;
}

$ cc -o alessio alessio.c
$ ./alessio
0 is in case!
1 is in case!
2 is in case!
3 is NOT in case!
4 is NOT in case!
5 is in case!
6 is NOT in case!
7 is NOT in case!
8 is NOT in case!
9 is NOT in case!

== 5 of 7 ==
Date: Tues, Oct 6 2009 7:09 am
From: Alessio

Kenneth Brody ha scritto:

> (I am assuming that your reference to lcc with 3 and 4 means that they,
> _in_ _addition_ _to_ 6, 7, 8, and 9, are "NOT in case", rather than
> _only_ 3 and 4.)
>

yes, you're right.

Alessio

== 6 of 7 ==
Date: Tues, Oct 6 2009 7:25 am
From: gwowen

Just to confirm the initial bug report...

C:\Program Files\PellesC>type foo.c
#include <stdio.h>
int main(void)
{
int i;
for ( i = 0; i < 10; i++ )
{
switch ( i )
{
case 0:
case 1:
case 2:
case 5:
printf("%d is in case!\n", i);
break;

default:
printf("%d is NOT in case!\n", i);
break;
}
}

return 0;

}

C:\Program Files\PellesC>.\Bin\cc foo.c
foo.c
.\Bin\polink.exe foo.obj

C:\Program Files\PellesC>.\foo.exe
0 is in case!
1 is in case!
2 is in case!
3 is in case!
4 is in case!
5 is in case!
6 is NOT in case!
7 is NOT in case!
8 is NOT in case!
9 is NOT in case!

-----------------------

YIKES!

== 7 of 7 ==
Date: Tues, Oct 6 2009 7:41 am
From: Debanjan

On Oct 6, 5:06 pm, Alessio <f...@fake.org> wrote:
> Hi, please consider following code:
>
> #include <stdio.h>
>
> int main(void)
> {
> int i;
>
> for ( i = 0; i < 10; i++ )
> {
> switch ( i )
> {
> case 0:
> case 1:
> case 2:
> case 5:
> printf("%d is in case!\n", i);
> break;
>
> default:
> printf("%d is NOT in case!\n", i);
> break;
> }
> }
>
> return 0;
>
> }
>
> What should be correct result ?
> With lcc compilier I get that 3 and 4 are "NOT in case", with PelleC
> compiler I get that only 6,7,8, and 9 are "NOT in case"...
>
> Thank you,
> Alessio.

Yes all others will be "in case" that's the correct output.

0 is in case!
1 is in case!
2 is in case!
3 is NOT in case!
4 is NOT in case!
5 is in case!
6 is NOT in case!
7 is NOT in case!
8 is NOT in case!
9 is NOT in case!

What else do you think ?

==============================================================================
TOPIC: union of structs: common variable stored in same address?
http://groups.google.com/group/comp.lang.c/t/b96dc02d740c3db8?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Oct 6 2009 5:14 am
From: James Kuyper

Alan Curry wrote:
> In article <0.47fd72e26a6e0b8ce44c.20091006110934BST.87tyyc7s0x.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> pacman@kosh.dhis.org (Alan Curry) writes:
>>> The definition above looks a lot like an XEvent from X11/Xlib.h, which
>>> starts out:
>>>
>>> typedef union _XEvent {
>>> int type; /* must not be changed; first element */
>>> XAnyEvent xany;
>>> XKeyEvent xkey;
>>> XButtonEvent xbutton;
> [...]
>> This is likely to work, yes, but I don't think is it guaranteed to do
>> what the programmer expects. I think it is permissible for an
>> implementation to align structs and size_ts in such a way that the
>> type members don't coincide. That is a practical matter. More
>> formally, I can't see any text in the standard that assures me that
>> will work as expected.
>>
>
> xkey.type is the first member of a struct, so it has the same address as the
> struct, which is also the address of the union, which is also the address of
> the union's type member.

6.7.2.1p13 says "A pointer to a structure object, suitably converted,
points to its initial member (or if that member is a bit-field, then to
the unit in which it resides), and vice versa."

However, there's no corresponding wording for unions.

> ... The struct if allocated alone might have a different
> alignment requirement than the integer if allocated alone, but the union
> has to be aligned for all of its members. Where's the loophole?

The standard permits padding before union members, though I know of no
reason why any implementation would take advantage of that option.

== 2 of 3 ==
Date: Tues, Oct 6 2009 7:55 am
From: Eric Sosman

James Kuyper wrote:
> [...]
> The standard permits padding before union members, though I know of no
> reason why any implementation would take advantage of that option.

6.7.2.1p14: "[...] A pointer to a union object, suitably
converted, points to each of its members (or if a member is a
bitfield, then to the unit in which it resides), and vice versa."

Where does this leave room for (sorry) padding?

(To forestall a possible objection: I do not believe that
"suitably converted" can be used to smuggle in any sleight of
hand like invisibly adjusting the pointer to hide padding.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 3 of 3 ==
Date: Tues, Oct 6 2009 9:31 am
From: jameskuyper

Eric Sosman wrote:
> James Kuyper wrote:
> > [...]
> > The standard permits padding before union members, though I know of no
> > reason why any implementation would take advantage of that option.
>
> 6.7.2.1p14: "[...] A pointer to a union object, suitably
> converted, points to each of its members (or if a member is a
> bitfield, then to the unit in which it resides), and vice versa."

OK - now I'm feeling pretty stupid. I looked for that text, failed to
find it despited the fact that it immediately follows 6.7.2.1p13,
which I've already cited. Can I claim that this was due to the
lingering aftermath of the flu I just recovered from? :-(.

> Where does this leave room for (sorry) padding?
>
> (To forestall a possible objection: I do not believe that
> "suitably converted" can be used to smuggle in any sleight of
> hand like invisibly adjusting the pointer to hide padding.)

Unfortunately, due to what I consider a defect in the standard, I do
believe that it can.

It is widely understood that a permissible conversion of a pointer to
a given object results in a new pointer value that points at an object
whose initial byte is the same as the initial byte of the object
pointed at by the original pointer - but the standard never actually
says so, except when the destination type is a pointer to a character
type (6.3.2.3p7).

Using the Rui Maciel's cursor_t, given

cursor_t ct;

Then 6.7.2.1p13 says that (int*)&ct == &ct.type, while 6.3.2.3p7 says
that (char*)&ct.type must point at the first byte of ct.type, and that
(char*)&ct must point at the first byte of ct. It might seem that you
can combine these facts to prove that (char*)&ct and (char*)&ct.type
point at the same byte. However, in order to do that, you have to
assume that (char*)(int*)&ct == (char*)&ct; and the standard provides
no guarantees that this will be the case.

The only time that the standard says anything about the result of
chaining two pointer conversions together is when the second
conversion converts back to the type of the original pointer; in some
of those cases, it guarantees that the result will compare equal to
the original pointer value. None of those cases apply here.

==============================================================================
TOPIC: variadic functions
http://groups.google.com/group/comp.lang.c/t/c36f0aa20c28fc99?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 5:30 am
From: Eric Sosman

Frank wrote:
> On Oct 5, 2:57 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> Frank wrote:
>>> [...]
>>> This compiles on lcc.
>> Maybe I'm dense today (it's been a difficult day), but I don't
>> see the relevance of this gobbet of non-portable code.
>
> I thought you said that there existed functions that are different
> than printf() in that you can't duplicate the task of #including the
> appropriate header by writing out the defintion yourself. Lcc's
> stdlib.h seamed to work just as well pasted in globally as opposed to
> #including it.

Okay; it was the reference to a "list" of functions that
threw me, because I don't recall seeing a list.

The Standard library contains some functions that cannot
be correctly declared "free-hand," that is, without their
Standard headers. It also contains functions that *can* be
so declared, although it's silly to do so.

The code you showed seemed to be mostly a copy-and-paste
of some implementation's <stdlib.h>, and I guess you consider
that a "free-hand" declaration of the contained functions. For
some -- atof(), for example -- the declaration is just fine and
you could (if in a silly mood) just write that line in your
code and buzz merrily along. But for many, the declaration is
specific to the implementation at hand, and would not work with
others; you'll have written a declaration of Frobozz Magic C's
version of ldiv(), not of Standard C's ldiv().

Well, actually, it's not the declaration of ldiv() itself
that's the problem -- but what about ldiv()'s result? You know
that it returns a struct ldiv_t, but where can you find that
struct type declared? A struct ldiv_t is quite likely arranged
in a way that's convenient to the hardware, and if you moved
your program to different hardware the arrangement would differ.
Claim: The only way to get a struct ldiv_t declaration that
works everywhere is to include <stdlib.h> and let the header
tell you about the local customs.

Then there's rand() -- easy enough to declare portably, but
what will you do if you need the value of RAND_MAX? And it's
easy to write a portable declaration of exit(), and you could
avoid EXIT_SUCCESS by always using zero, but what if you need
the value of EXIT_FAILURE? How will you write a declaration of
malloc(), without knowing what size_t is? (In this case you
could cheat by including one of the other headers that defines
size_t and then writing your malloc() declaration without using
<stdlib.h> itself, but that's a subterfuge.)

There: I've shown you a few <stdlib.h> functions that cannot
be properly declared without <stdlib.h>, and a few that can be
declared but can't be used to their fullest without it. You will
find other similar examples in other Standard headers -- and some
of those functions are not in the least bit esoteric or odd, but
are functions you encounter every day.

--
Eric Sosman
esosman@ieee-dot-org.invalid

==============================================================================
TOPIC: 0ur website www.yellshoe.com wholesale $33jordan shoes,$18tshirt,15
sunglassess, $13cap,$38jean,$38 handbag
http://groups.google.com/group/comp.lang.c/t/9dbd8b3d27fa62d8?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 5:34 am
From: "yellshoe.com"

Our website http://www.yellshoe.com
"$$$$$$Sports Shoes ,Fashion Shoes
there are many items in our company now ,our goods are both excellent
in quality and reasonable in price ,I think you will like them ,we
have sold lots of the goods now ,if you are interest in our goods ,pls
contact us ,we will supply the best service to you

==============================================================================
TOPIC: can a character be negative?
http://groups.google.com/group/comp.lang.c/t/ef0336d66975924c?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 6 2009 5:35 am
From: "Dik T. Winter"

In article <lnvdj1s2v1.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:
...
> Most of the compilers I've used have char signed, but I've used
> several where it's unsigned (several Cray systems, SGI Irix, IBM AIX).
> And char is almost certainly signed on any EBCDIC-based system.

Should be unsigned. (EBCDIC has standard characters with the high bit
set.)
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

== 2 of 2 ==
Date: Tues, Oct 6 2009 8:12 am
From: Keith Thompson

"Dik T. Winter" <Dik.Winter@cwi.nl> writes:
> In article <lnvdj1s2v1.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:
> ...
> > Most of the compilers I've used have char signed, but I've used
> > several where it's unsigned (several Cray systems, SGI Irix, IBM AIX).
> > And char is almost certainly signed on any EBCDIC-based system.
>
> Should be unsigned. (EBCDIC has standard characters with the high bit
> set.)

Yes, that was a typo, noticed and acknowledged several days ago.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

==============================================================================
TOPIC: 4 Simple Tips To Earn $2,080 Weekly With Part Time Job
http://groups.google.com/group/comp.lang.c/t/489811f12f71438e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 5:48 am
From: priya jain

4 Simple Tips To Earn $2,080 Weekly With Part Time Job

Visit http://megalinesolutions.googlepages.com/ To Start Earning
Now !!!

==============================================================================
TOPIC: "error: invalid preprocessing directive #DEFINE"
http://groups.google.com/group/comp.lang.c/t/45e8c40b7a06745d?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Oct 6 2009 6:37 am
From: Kenneth Brody

jameskuyper wrote:
>
> Kenneth Brody wrote:
[...]
>> While useful as a way of adding implementation-specific features, a
>> catch-all "comment" doesn't sound good to me.
>
> I agree; I was trying to figure out what the standard actually says,
> and to suggest alternative wording that would make it clearer.
> However, all the committee had to do to make a diagnostic mandatory
> would have been to leave out non-directives entirely; they would then
> have constituted syntax errors. In defining a "non-directive", the
> committee went out of their way to make it not be a syntax error; I
> presume they had a reason - I'm curious what it was. Until I know that
> reason, and can judge it's validity, I didn't want to suggest changing
> it to a syntax error.

It doesn't have to be a "syntax error" to be an "error". After all, the
following isn't a "syntax error", either:

fprintf(37,"hello"+"there");

But, the lack of description as to what "non-directive" is for does leave a
bit to be desired. It could be used for implementation-defined extensions,
but it doesn't explicitly state that, nor does it state what to do with
"unknown" "non-directives". For example, 6.10.6p1 says that any #pragma
other than STDC is "implementation-defined".

--
Kenneth Brody

== 2 of 3 ==
Date: Tues, Oct 6 2009 6:51 am
From: James Kuyper

Kenneth Brody wrote:
> jameskuyper wrote:
>>
>> Kenneth Brody wrote:
> [...]
>>> While useful as a way of adding implementation-specific features, a
>>> catch-all "comment" doesn't sound good to me.
>>
>> I agree; I was trying to figure out what the standard actually says,
>> and to suggest alternative wording that would make it clearer.
>> However, all the committee had to do to make a diagnostic mandatory
>> would have been to leave out non-directives entirely; they would then
>> have constituted syntax errors. In defining a "non-directive", the
>> committee went out of their way to make it not be a syntax error; I
>> presume they had a reason - I'm curious what it was. Until I know that
>> reason, and can judge it's validity, I didn't want to suggest changing
>> it to a syntax error.
>
> It doesn't have to be a "syntax error" to be an "error". After all, the
> following isn't a "syntax error", either:

I would want a diagnostic to be mandatory; the simplest way to make that
happen is to make it a syntax error, by removing 'non-directive' from
the grammar. Of course, a constraint violation or an explicit statement
that a diagnostic is required would do just as well.

This would not prevent the development of implementation-specific
preprocessing directives. In conforming mode, a compiler could issue a
diagnostic saying "warning: non-standard feature #explain used", and
that warning could be turned off by an option that would render the
compiler non-conforming.

My point is - the committee went out of their way to put "non-directive"
into the grammar. Why? Until I know why, I don't want to suggest
removing it. Keith's inquiry on comp.std.c has received no authoritative
response yet, which is a bit disappointing.

== 3 of 3 ==
Date: Tues, Oct 6 2009 9:09 am
From: jacob navia

James Kuyper a écrit :
>
> My point is - the committee went out of their way to put "non-directive"
> into the grammar. Why? Until I know why, I don't want to suggest
> removing it. Keith's inquiry on comp.std.c has received no authoritative
> response yet, which is a bit disappointing.
>

Well, this is just a bug.

Nobody is perfect, and committee members aren't either.

The preprocessor of lcc-win uses is a version that was written by Dennis Ritchie.
I have maintained his code for many years, and he does complain at any
directive that is not a known directive. This bug in the specs was introduced
later, and I am glad his version doesn't have it.

==============================================================================
TOPIC: Nike dunk high shoes wholesale\retail
http://groups.google.com/group/comp.lang.c/t/4806d2d8db5756b5?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 7:11 am
From: danfei wang

Nike dunk high shoes wholesale\retail
Our company mainly deal with the import and export of the brand sports
shoes, clothes, jewelry, bags , glasses, etc . Products such as Nike
Jordan sell well in America , Canada , as well as Europe and other
countries. Our objective is to supply products of first-class quality
and advanced technology. Customers satisfaction is our greatest
pursuit. We thank you for your attention and wish having a long time
business relationship with all buyers from all over the world.

we take PAYPAL as the method of payment!
please kindly visite our website: http://www.cnnshoe.com
msn: cnnshoe2008@hotmail.com
email: wclxyj@gmail.com

==============================================================================
TOPIC: ♠♣♥❤ 2009 Cheap Wholesale Brand pants, Shorts,Jeans==A&F Shorts, Bape
Shorts, Evisu Shorts etc.G-Star Jeans, Ecko Unltd Jeans, Evisu Jeans etc.===
WEBSITE: www.fjrjtrade.com <paypal payment>
http://groups.google.com/group/comp.lang.c/t/07cff75e91789678?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 7:18 am
From: fjrjtrade

♠♣♥❤ 2009 Cheap Wholesale Brand pants, Shorts,Jeans==A&F Shorts, Bape
Shorts, Evisu Shorts etc.G-Star Jeans, Ecko Unltd Jeans, Evisu Jeans
etc.=== WEBSITE: www.fjrjtrade.com <paypal payment>

Welcome to visit our website---www.fjrjtrade.com

Website:
http://www.fjrjtrade.com

==============================================================================
TOPIC: Definition of language constructs
http://groups.google.com/group/comp.lang.c/t/1a4e026124d09af0?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 8:16 am
From: Tim Frink

Hi,

is there a formal definition of the high-level language constructs
"expression" and "statement" or are the definitions different depending
on the programming language? For example, in the ANSI-C standard, these
both terms are defined, thus I was wondering if this definition is
valid for any imperative language or just really for ANSI-C.

For example, the definition for an expression is:
An expression is a sequence of operators and operands that specifies
computation of a value, or that designates an object or a function,
or that generates side effects, or that performs a combination thereof.

Regards,
Tim

==============================================================================
TOPIC: Discount Wholesale Nike Air Max Clssic BW Air Max LTD Air Max 90 Air
Max TN <www.dotradenow.com> free shipping
http://groups.google.com/group/comp.lang.c/t/c1475ffa7ba541c7?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 6 2009 8:58 am
From: wendy

Cheap Wholesale Nike Air Max 87 <www.dotradenow.com> free shipping
Cheap Wholesale Nike Air Max 89 <www.dotradenow.com> paypal payment
Cheap Wholesale Nike Air Max 90 <www.dotradenow.com> paypal payment
Cheap Wholesale Nike Air Max 91 <www.dotradenow.com> free shipping
Cheap Wholesale Nike Air Max 92 Man <www.dotradenow.com> paypal
payment
Cheap Wholesale Nike Air Max 93 <www.dotradenow.com> paypal payment
Cheap Wholesale Nike Air Max 95 <www.dotradenow.com> free shipping
Cheap Wholesale Nike Air Max 97 <www.dotradenow.com> paypal payment
Cheap Wholesale Nike Air Max 180 Man <www.dotradenow.com> paypal
payment
Cheap Wholesale Nike Air Max 2006 <www.dotradenow.com> paypal payment
Cheap Wholesale Nike Air Max 2009 <www.dotradenow.com> paypal payment
Cheap Wholesale Nike Air Max Clssic BW <www.dotradenow.com> free
shipping
Cheap Wholesale Nike Air Max LTD <www.dotradenow.com> paypal payment
Cheap Wholesale Nike Air Max Skyline <www.dotradenow.com> paypal
payment
Cheap Wholesale Nike Air Max STAB <www.dotradenow.com> free shipping
Cheap Wholesale Nike Air Max Tailwind <www.dotradenow.com> paypal
payment
Cheap Wholesale Nike Air Max TN <www.dotradenow.com> paypal payment

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, October 6, 2009

comp.lang.c - 25 new messages in 13 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts