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

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

comp.lang.c@googlegroups.com

Today's topics:

* Efficency and the standard library - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* Scope of a variable declared in for loop - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
* Any exit status without explicitely using return /exit - 8 messages, 6
authors
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
* help: gcc compilation difference - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
* Watch nude girls fucking and sucking the cocks. Girls shaving their pussies,
boys giving shots on the pussies and licking them. Also watch girls getting
fucked on a car roof, a girl banged by a gang of four members. At the end the
girl collect - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/9975896d42811417?hl=en
* usage of size_t - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 24 2010 12:11 am
From: Ian Collins

Richard Heathfield wrote:
> spinoza1111 wrote:
>
>> and follows the lead of most other
>> compilers, which don't get "picky" by default.
>
> Would that they did. Then the quality of software might improve a bit.

Why should they? If you want to analyse code, use a tool like lint.
Let the compiler focus on compiling legal code quickly and accurately.

--
Ian Collins

== 2 of 4 ==
Date: Wed, Feb 24 2010 12:29 am
From: Nick Keighley

On 23 Feb, 20:16, Nick <3-nos...@temporary-address.org.uk> wrote:
> Seebs <usenet-nos...@seebs.net> writes:

> > This is then followed by the "corresponding" example:
>
> > ch = getc(fp); /* read one character */
> > while (ch!=EOF) {
> > putchar(ch); /* print on screen */
> > ch = getc(fp);
> > }
>
> > This is actually probably correct, though horribly unidiomatic. Oh, wait,
> > found the bug; it's worse. "ch" is declared as a "char", meaning that on
> > many systems, it will spew an infinite stream of characters which have the
> > value you would get if you converted EOF to char. Since the entire POINT
> > of EOF is that it's a value which cannot be a character returned by getc,
> > and thus, is outside the range of unsigned char, that's sort of bad.
>
> Putting the bug aside, I had experience of people writing C like that
> around 1990. They'd been on some sort of course in some sort of
> programming methodology (maybe SSADM, maybe not - it was a long time
> ago). In this case, they ended up writing something like:
>
> a = fgets(buff, SIZE, stdin)
> while(a) {
> do_things_with_a;
> a = fgets(buff, SIZE, stdin);
>
> }
>
> All perfectly logical, but utterly un-idiomatic and (particularly when
> things were a bit more complicated) it led you to looking at the two
> identical lines wondering if they were in any way different.

it's idiomatic in a language that doesn't allow assignment in the
test. Removing the duplicated line was one reason I liked C!

== 3 of 4 ==
Date: Wed, Feb 24 2010 12:36 am
From: Keith Thompson

Ian Collins <ian-news@hotmail.com> writes:
> Richard Heathfield wrote:
>> spinoza1111 wrote:
>>> and follows the lead of most other
>>> compilers, which don't get "picky" by default.
>>
>> Would that they did. Then the quality of software might improve a bit.
>
> Why should they? If you want to analyse code, use a tool like
> lint. Let the compiler focus on compiling legal code quickly and
> accurately.

Analysis tools *can* be distinct from the compiler, but they don't
have to be. There's no fundamental reason why a compiler can't do as
much analysis as it likes, perhaps optionally. Much of the analysis
is necessary for optimization anyway.

My understanding is that lint was originally implemented as a
separate tool (sharing some code with the compiler) because of
memory constraints.

--
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"

== 4 of 4 ==
Date: Wed, Feb 24 2010 12:46 am
From: Nick Keighley

On 23 Feb, 16:52, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-23, blmblm myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <210fec94-aa97-4b77-a239-668539100...@c37g2000prb.googlegroups.com>,
> > spinoza1111 <spinoza1...@yahoo.com> wrote:

> >> I'd been laboring under an incorrect presumption, which was that the
> MS is not famous for great compiler work,

I thought these days they were. Apparently they "eat their own dog
food". Though some would argue failure to support C99 is a gaping
hole.

> or for reasonable default options.

which compiler *does* come with reasonable default options!

==============================================================================
TOPIC: Scope of a variable declared in for loop
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Feb 24 2010 12:18 am
From: santosh

lovecreatesbeauty@gmail.c0m <lovecreatesbeauty@gmail.com> writes:
> On Feb 23, 11:00 pm, Keith Thompson <ks...@mib.org> wrote:
>> There are plenty of compilers that don't implement, or don't fully
>> implement, the C99 standard.
>>
>
> People are busy making new C standard while the old one arent'
> fully implemented. What will the new one do - withdraw some odd
> features in the old one?

As I understand from previous discussions here and in c.s.c, a
feature has to first be deprecated, before it can be removed.

AFAIK, gets will no longer be present in the next C standard, but
I've no idea about other withdrawals, if any.

What's interesting is that it's going to have support for concurrent
programming. For more discussions, better post in c.s.c.

== 2 of 8 ==
Date: Wed, Feb 24 2010 12:25 am
From: Michael Tsang

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenny McCormack wrote:

> In article <ko2e57-q2n.ln1@news.eternal-september.org>,
> Richard <rgrdev_@gmail.com> wrote:
>>Mark Bluemel <mark.bluemel@googlemail.com> writes:
>>
>>> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>>>> Hi,
>>>> A)Is it possible to declare a variable inside for loop like
>>>> for(int i=100;i>=0;i--);
>>>
>>> Not in C.
>>
>>Huh? What C do you use?
>>
>>Not only can you, its recommended.
>
> In the religion of comp.lang.c, nothing exists past C89.
>
> Therefore, it (the declarations which are the subject of this thread)
> does not exist.

C99 is not C?! READ THE STANDARD!
According to the standard:

This second edition cancels and replaces the first edition, ISO/IEC
9899:1990, as
amended and corrected by ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and
ISO/IEC 9899/COR2:1996. Major changes from the previous edition include:

That is, C99 is the ONLY standard NOW. The previous version has been
replaced by this version. If a C compiler does not fully implement this
standard, then it is not a fully-compliant C compiler.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkuE4l0ACgkQm4klUUKw07DVuQCfVcWTj8FIjvnwvDuWk3TzGNR7
kVAAn3fRpg7e23W0Jm7Ub7abiRkFXaxD
=ctIT
-----END PGP SIGNATURE-----

== 3 of 8 ==
Date: Wed, Feb 24 2010 12:29 am
From: gwowen

On Feb 24, 8:01 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:

> you sure they were actually wrong? I thought the definition of C++
> changed. C++ wasn't actually standardised at the time, but was defined
> by Stroustrup's book.

Correct (though the "Stroustrop's book" in this context isn't D&E,
which is being discussed else-thread.) Standard C++ has always been
"scope is just the loop", but pre-standard C++ -- that described in
The C++ Programming Language 2nd Ed, it lasts till the end of the
inner block in which the for() lives (r6.5.3).

for(init;exp1;exp2)
statement;

used to be equivalent to

init;
while(exp1){
statement;
exp2;
}

Now its equivalent to

{
init;
while(exp1){
statement;
exp2;
}
}

Some compilers (e.g. g++ ) implement both with a switch to select
between them (-ffor-scope)

== 4 of 8 ==
Date: Wed, Feb 24 2010 12:38 am
From: Mark Bluemel

On 23 Feb, 16:08, santosh <santosh....@gmail.com> wrote:
> Mark Bluemel <mark.blue...@googlemail.com> writes:
> > On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
> >> Hi,
> >> A)Is it possible to declare a variable inside for loop like
> >> for(int i=100;i>=0;i--);
>
> > Not in C.
>
> > Variables can be declared inside a block (i.e. between braces) but
> > not in the context you are talking about.
>
> I'm sure it's just a case of over-looking, but just for lurkers'
> benefit, the first code snippet shown by the OP, which you've quoted
> above is correct C, though "C99 only", one should qualify.

Thanks for the correction. I should have checked C99, but given its
absence from my day-to-day existence, I tend to forget about it.

== 5 of 8 ==
Date: Wed, Feb 24 2010 12:51 am
From: Keith Thompson

"lovecreatesbeauty@gmail.c0m" <lovecreatesbeauty@gmail.com> writes:
> On Feb 23, 11:00 pm, Keith Thompson <ks...@mib.org> wrote:
>> There are plenty of compilers that don't implement, or don't fully
>> implement, the C99 standard.
>
> People are busy making new C standard while the old one arent' fully
> implemented. What will the new one do - withdraw some odd features in
> the old one?

Chris Hills, who is a member of the committee, has stated here
that C1X is likely to drop a number of C99 features, for example
in Message-ID: <+UTJjlIs20tKFAMT@phaedsys.demon.co.uk>.
I've seen no confirmation of this from anyone
else, and the C201X committee drafts (the latest is
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1425.pdf>) have
shown no signs of such an effort; they're based on the C99 standard
with clarifications and new features (including threading).

Personally, I think dropping C99-specific features from C201X would
be a bad idea. Though C99 as a whole isn't as widely available
as I'd like, there are *some* conforming or nearly conforming
implementations, and there's code that depends on the new features.
Breaking existing code is not absolutely prohibited, but it's
something the committee has gone to great lengths to avoid.

== 6 of 8 ==
Date: Wed, Feb 24 2010 12:53 am
From: Keith Thompson

Michael Tsang <miklcct@gmail.com> writes:
> Kenny McCormack wrote:
[the usual]
>
> C99 is not C?! READ THE STANDARD!
> According to the standard:
[snip]

Don't worry about what Kenny says. He's lying.

== 7 of 8 ==
Date: Wed, Feb 24 2010 1:09 am
From: santosh

Michael Tsang <miklcct@gmail.com> writes:
> Kenny McCormack wrote:
[ ... ]
>> In the religion of comp.lang.c, nothing exists past C89.
>>
>> Therefore, it (the declarations which are the subject of this
>> thread) does not exist.
>
> C99 is not C?! READ THE STANDARD!
> According to the standard:
>
> This second edition cancels and replaces the first edition, ISO/IEC
> 9899:1990, as amended and corrected by ISO/IEC 9899/COR1:1994,
> ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996. Major changes
> from the previous edition include:
>
> That is, C99 is the ONLY standard NOW. The previous version has
> been replaced by this version. If a C compiler does not fully
> implement this standard, then it is not a fully-compliant C
> compiler.

Strictly speaking, I guess you're right. But real world is "fuzzier."

A Standard's aim and reason for coming into existence is to get
widely, if not unanimously, implemented. Otherwise it can be regarded
as not having achieved it's purpose. Implementations always have the
final say, since it's they which ultimately get the job done, not the
standards.

Arguably, the large portion of the reason for why Standard C has not
been widely implemented has to be borne by the ISO committee, for
standardising features lacking broad consensus across atleast most
implementations out there. This was I guess the key difference from
the C90 standardisation.

Let's hope the upcoming standard meets with better success than
C99:-)

And Kenny was being sarcastic there. He full well knows that C99 is
the current C Standard.

== 8 of 8 ==
Date: Wed, Feb 24 2010 1:35 am
From: jacob navia

Keith Thompson a écrit :
> Michael Tsang <miklcct@gmail.com> writes:
>> Kenny McCormack wrote:
> [the usual]
>> C99 is not C?! READ THE STANDARD!
>> According to the standard:
> [snip]
>
> Don't worry about what Kenny says. He's lying.
>
Don't worry about Thomson, he is just obsolete.
He thinks anybody that doesn't agree with the C89 clique here
is lying...

==============================================================================
TOPIC: Any exit status without explicitely using return /exit
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Feb 24 2010 12:27 am
From: Debanjan

This actually bugging me from quite sometime now.The question is like
this : How to set the the exit status of a program to any value
without explicitly using return/exit in gcc ?

Let us consider this piece of code : (Takes input from stdin and print
it to the stdout until a zero input 0 is encountered)

#include <stdio.h>

int main(){
int n;
while(scanf("%d",&n) && n>0 )
printf("%d\n",n);
}

In my system (which is windows + mingw) it is returning 1,How to make
it to return 0 or anything else implicitly without explicitly using
exit/return ?

== 2 of 8 ==
Date: Wed, Feb 24 2010 12:39 am
From: Mark Bluemel

On 24 Feb, 08:27, Debanjan <debanjan4...@gmail.com> wrote:
> This actually bugging me from quite sometime now.The question is like
> this : How to set the the exit status of a program to any value
> without explicitly using return/exit in gcc ?

And later in tonight's program, how to drive nails using a wrench...

== 3 of 8 ==
Date: Wed, Feb 24 2010 12:41 am
From: jacob navia

Debanjan a écrit :
> This actually bugging me from quite sometime now.The question is like
> this : How to set the the exit status of a program to any value
> without explicitly using return/exit in gcc ?
>
> Let us consider this piece of code : (Takes input from stdin and print
> it to the stdout until a zero input 0 is encountered)
>
> #include <stdio.h>
>
> int main(){
> int n;
> while(scanf("%d",&n) && n>0 )
> printf("%d\n",n);
> }
>
> In my system (which is windows + mingw) it is returning 1,How to make
> it to return 0 or anything else implicitly without explicitly using
> exit/return ?

Standard C guarantees a return of zero for a main() function that
doesn't explicitly assign a return value.

== 4 of 8 ==
Date: Wed, Feb 24 2010 12:51 am
From: Debanjan

On Feb 24, 1:41 pm, jacob navia <ja...@spamsink.net> wrote:
> Debanjan a écrit :
>
>
>
> > This actually bugging me from quite sometime now.The question is like
> > this : How to set the the exit status of a program to any value
> > without explicitly using return/exit in gcc ?
>
> > Let us consider this piece of code : (Takes input from stdin and print
> > it to the stdout until a zero input 0 is encountered)
>
> > #include <stdio.h>
>
> > int main(){
> > int n;
> > while(scanf("%d",&n) && n>0 )
> > printf("%d\n",n);
> > }
>
> > In my system (which is windows + mingw) it is returning 1,How to make
> > it to return 0 or anything else implicitly without explicitly using
> > exit/return ?
>
> Standard C guarantees a return of zero for a main() function that
> doesn't explicitly assign a return value.

Yes that I know but in some gcc version it is not the actual case,like
the one I showed above.

== 5 of 8 ==
Date: Wed, Feb 24 2010 12:54 am
From: santosh

Debanjan <debanjan4you@gmail.com> writes:

> This actually bugging me from quite sometime now.The question is
> like this : How to set the the exit status of a program to any
> value without explicitly using return/exit in gcc ?
>
> Let us consider this piece of code : (Takes input from stdin and
> print it to the stdout until a zero input 0 is encountered)
>
> #include <stdio.h>
>
> int main(){
> int n;
> while(scanf("%d",&n) && n>0 )
> printf("%d\n",n);
> }
>
> In my system (which is windows + mingw) it is returning 1,How to
> make it to return 0 or anything else implicitly without explicitly
> using exit/return ?

_Exit(ANY_VALUE);

should do the trick, and it answers what you asked.

Seriously though, even if there is some hackery to get this done, it
isn't likely to be portable or consistent between compilers or
systems. And the even bigger question is why you want to do this in
the first place. Is it simple curiosity? If it's for any practical
purposes, there's very likely to be better way to do what you want.

== 6 of 8 ==
Date: Wed, Feb 24 2010 12:57 am
From: Keith Thompson

jacob navia <jacob@spamsink.net> writes:
[...]
> Standard C guarantees a return of zero for a main() function that
> doesn't explicitly assign a return value.

By "Standard C", of course, jacob means C99. In C90, which jacob
insists on ignoring, the exit status of such a program is undefined.
(Yes, C99 superseded C90. Yes, C99 is the one and only official
C standard. We know, jacob, we know.)

== 7 of 8 ==
Date: Wed, Feb 24 2010 1:03 am
From: ike@localhost.claranet.nl (Ike Naar)

In article <63e0a5ad-ed4f-440f-9182-821650e82b39@u19g2000prh.googlegroups.com>,
Debanjan <debanjan4you@gmail.com> wrote:
>Let us consider this piece of code : (Takes input from stdin and print
>it to the stdout until a zero input 0 is encountered)
>
>#include <stdio.h>
>
>int main(){
> int n;
> while(scanf("%d",&n) && n>0 )
> printf("%d\n",n);
>}
>
>In my system (which is windows + mingw) it is returning 1,How to make
>it to return 0 or anything else implicitly without explicitly using
>exit/return ?

That program will not do the required job; it will not only terminate
if input 0 is encountered, but also if an input error occurs or if a
negative input is encountered.

If you compile it with a C89 compiler, it may return anything, and, in
fact, on my implementation (gcc compiler running on NetBSD) the program
returns 1 when it terminates because of an input <=0, and it returns 0
if it terminates because of an input error (when the input is not a
valid integer). Of course the return values may be different on another
implementation, this is only to illustrate that the return value can be
anything at all.

If you compile the program with a C99 compiler, it will implicitly return 0
if you don't specify a return value.

If you're using C89, or if you're using C99 and want a return value other
than 0, just use an explicit return or exit.

== 8 of 8 ==
Date: Wed, Feb 24 2010 1:02 am
From: Keith Thompson

Debanjan <debanjan4you@gmail.com> writes:
> This actually bugging me from quite sometime now.The question is like
> this : How to set the the exit status of a program to any value
> without explicitly using return/exit in gcc ?
[...]

Some equally interesting questions:

How can you add two numbers without using the "+" operator?

How can you call a function without using a function call?

How can you pound a nail without using a hammer?

A more relevant question: Why don't you want to use return or exit?
That's what they're for.

==============================================================================
TOPIC: help: gcc compilation difference
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 12:33 am
From: Keith Thompson

"paul" <no@email> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnocjf2tzm.fsf@nuthaus.mib.org...
>> new <luvraghu@gmail.com> writes:
[...]
>>> #include<stdio.h>
>>> #include<malloc.h>
>>>
>>> int main()
>>> {
>>> char *s;
>>> char p[] = "abcda";
>>> s = malloc(sizeof(char) *256);
>>> s[p[0]]++;
>>> s[p[2]]++;
>>> return 0;
>>> }
[...]
>>
>> Nothing is done with the results of the computations; the entire
>> program could legitimately be optimized down to:
>>
>> int main(void) { return 0; }
>
> Surely this optimisation will behave differently from the
> above code since it will not call malloc?

Calling malloc is not part of the program's behavior, which is defined
by the standard as "external appearance or action".

> How/why does the compiler know/assume that the call
> can be optimised away?

Because malloc is part of the standard library, the implementation
is free to assume that it behaves as the standard specifies.
If the call succeeds, then the program continues to execute and
produces no output. If the call fails, then the behavior of the
following statements is undefined -- and one possible behavior
is continuing to execute and producing no output. If the program
calls a different function with the same name (say, one declared
in the non-standard header <malloc.h> and perhaps implemented in
some non-standard library), then again, the behavior is undefined,
and the implementation is free to assume that it will produce
no output. (If <malloc.h> defines "malloc" as a macro that does
something other than calling malloc, then this doesn't apply,
but I implicitly assumed that that wasn't the case.)

If the call were to some external function that's not part of the C
standard library, the compiler wouldn't be free to perform this kind
of optimization unless it happened to know what the function does;
for example, an implementation might perform some optimizations at
link time.

== 2 of 2 ==
Date: Wed, Feb 24 2010 1:11 am
From: santosh

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-02-24, paul <no@email> wrote:
>>
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnocjf2tzm.fsf@nuthaus.mib.org...
>>> new <luvraghu@gmail.com> writes:
>>>> Hi C Experts,
>>>>
>>>> I have the following program:
>>>>
>>>> poitr.c
>>>> ----------------------------------
>>>> #include<stdio.h>
>>>> #include<malloc.h>
>>>>
>>>> int main()
>>>> {
>>>> char *s;
>>>> char p[] = "abcda";
>>>> s = malloc(sizeof(char) *256);
>>>> s[p[0]]++;
>>>> s[p[2]]++;
>>>> return 0;
>>>> }
>>>
>>> Really? Where did you get it?
>><snip>
>>>
>>> Nothing is done with the results of the computations; the entire
>>> program could legitimately be optimized down to:
>>>
>>> int main(void) { return 0; }
>>>
>>
>> Surely this optimisation will behave differently from the
>> above code since it will not call malloc?
>>
>> How/why does the compiler know/assume that the call
>> can be optimised away?
>>
>> Paul.
>>
>>
>>
>>
>
>

Seems as if your follow-up was "optimised away." ;-)

==============================================================================
TOPIC: Watch nude girls fucking and sucking the cocks. Girls shaving their
pussies, boys giving shots on the pussies and licking them. Also watch girls
getting fucked on a car roof, a girl banged by a gang of four members. At the
end the girl collect
http://groups.google.com/group/comp.lang.c/t/9975896d42811417?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 12:59 am
From: hhuifhiu ijuihuh

Watch nude girls fucking and sucking the cocks. Girls shaving their
pussies, boys giving shots on

the pussies and licking them. Also watch girls getting fucked on a car
roof, a girl banged by a gang

of four members. At the end the girl collects sperms from all four
mens penis in her mouth and

swallows it.

http://sites.google.com/site/niceglamourz

==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 1:24 am
From: Nick Keighley

On 23 Feb, 10:00, Richard Heathfield <r...@see.sig.invalid> wrote:
> Nick Keighley wrote:
> > On 22 Feb, 22:29, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> >> "Richard" <rgrd...@gmail.com> wrote in message
> >>news:bnga57-5i8.ln1@news.eternal-september.org...

> >>> That doesnt wash with me.
> >>> Putting the decrement in the body makes it less clear.
> >>> If a post decrement is too clever for the reader then so is using C.
>
> >> Use a debugger.
>
> > no, don't
> > a debugger is not the right tool to learn what C constructs do
>
> I'm *reasonably* sure he was joking - yanking Richard NoName
> MyHammerIsADebuggerAndEveryProblemIsANail Riley's chain a little.

I didn't think Bill was that witty.

I must confess I was expecting a response from /a/ Richard, just not
from you!

== 2 of 2 ==
Date: Wed, Feb 24 2010 1:33 am
From: Nick Keighley

On 23 Feb, 21:20, ralt...@xs4all.nl (Richard Bos) wrote:

> And yet, I would prefer a novel written in English for literate readers
> _not_ to eschew idioms. You should compare C to a Shaw play or a book by
> Joyce.

'Sir Tristram, violer d'amores, fr'over the short sea, has passencore
rearrived from North Armorica on this side the scraggy isthmus of
Europe Minor to wielderfight his penisolate war; nor had topsawyer's
rocks by the stream Oconee exaggerated themselse to Laurens County's
giorgios while the went doubling their mumper all the time'

> Do not write C as if you are Dr. Seuss - that's what BASIC is for.

I would not, could not, in a box.
I could not, would not, with a fox.
I will not eat them with a mouse.
I will not eat them in a house.
I will not eat them here or there.
I will not eat them anywhere.
I do not eat green eggs and ham.
I do not like them, Sam-I-am.

no contest really...

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

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

Wednesday, February 24, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts