Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3941 > unrolled thread

I need help

Back to article view | Back to comp.lang.c

Contents

  I need help janus <emekamicro@gmail.com> - 2011-05-14 04:05 -0700
    Re: I need help "Heinrich Wolf" <invalid@invalid.invalid> - 2011-05-14 13:30 +0200
      Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-14 13:46 +0200
        Re: I need help "Heinrich Wolf" <invalid@invalid.invalid> - 2011-05-14 14:20 +0200
      Re: I need help Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-14 04:48 -0700
    Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-14 13:39 +0200
      Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-14 13:44 +0200
      Re: I need help "Heinrich Wolf" <invalid@invalid.invalid> - 2011-05-14 14:23 +0200
        Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-16 16:47 +0200
      Re: I need help James Kuyper <jameskuyper@verizon.net> - 2011-05-14 09:14 -0400
        Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-16 16:43 +0200
          Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 08:23 -0700
            Re: I need help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 23:00 +0100
              Rationale for Shao Miller <sha0.miller@gmail.com> - 2011-05-16 23:40 -0500
                Re: Rationale for Some of 6.7.3p9? Shao Miller <sha0.miller@gmail.com> - 2011-05-16 23:43 -0500
                  Re: Rationale for Some of 6.7.3p9? Heikki Kallasjoki <see@end.of.message.invalid> - 2011-05-17 06:06 +0000
                    Re: Rationale for Some of 6.7.3p9? Heikki Kallasjoki <see@end.of.message.invalid> - 2011-05-17 06:13 +0000
                      Re: Rationale for Some of 6.7.3p9? Angel <angel+news@spamcop.net> - 2011-05-17 14:03 +0000
                      Re: Rationale for Some of 6.7.3p9? Shao Miller <sha0.miller@gmail.com> - 2011-05-17 10:19 -0400
                Re: Rationale for Ike Naar <ike@iceland.freeshell.org> - 2011-05-17 06:09 +0000
                  Re: Rationale for Shao Miller <sha0.miller@gmail.com> - 2011-05-17 10:20 -0400
    Re: I need help Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-14 04:45 -0700
    Re: I need help Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-14 09:39 -0400
      Re: I need help sandeep <nospam@nospam.com> - 2011-05-15 21:37 +0000
        Re: I need help Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-15 18:35 -0400
          Re: I need help pete <pfiland@mindspring.com> - 2011-05-15 19:45 -0400
            Re: I need help pete <pfiland@mindspring.com> - 2011-05-15 20:15 -0400
          Re: I need help sandeep <nospam@nospam.com> - 2011-05-16 18:27 +0000
            Re: I need help Shao Miller <sha0.miller@gmail.com> - 2011-05-16 14:45 -0400
            Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 11:41 -0700
              Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-16 19:12 +0000
                Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 12:30 -0700
                  Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-16 20:09 +0000
                  Re: I need help sandeep <nospam@nospam.com> - 2011-05-16 20:35 +0000
                    Re: I need help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 23:22 +0100
                      Re: I need help David Thompson <dave.thompson2@verizon.net> - 2011-05-24 01:19 -0400
                Re: I need help Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 00:19 -0700
                  Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-19 14:37 +0000
                    Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-19 08:17 -0700
                      Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-19 16:08 +0000
                    Re: I need help Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 11:13 -0700
        Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 08:12 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4163 — Re: Rationale for

On 5/17/2011 02:09, Ike Naar wrote:
> Have you read http://c-faq.com/ansi/constmismatch.html ?

Hadn't read that one until this morning.  Thanks! :)

[toc] | [prev] | [next] | [standalone]

#3945

In article 
<04ee4fd1-29ef-4640-a906-22055187c1e4@glegroupsg2000goo.googlegroups.com>,
 janus <emekamicro@gmail.com> wrote:

> Hello All,
> 
> I found this is a code I am currently studying, could someone explain it to 
> me.
> 
> char * string = "Simulated Annealing = 12847369";
> char * value = strchr(string, '=');
> 
> *(value ++ ) = 0;

This converts "Simulated Annealing = 12847369" to "Simulated Annealing \0 
12847369". However modifying a string constant is not defined in the standard 
and has implementation dependent result. To do this safely the string has to be 
writable, such as,
    char string[] = "Simulated Annealing = 12847369";
which is a char array variable, not a pointer to a string constant.

string points to the C string "Simulated Annealing ".
value points to the C string " 12847369".

> printf("%s ==== %s", value, string);
> 
> I noticed that sting will print in a new line, why this?

You can see if the behaviour disappears when you use safe code.

> char* karmarkar = "Karmarkar   958572";
> I want to use strchr to find the first occurrence of "space" in string 
> karmarkar.
> How do I do that? 

If you want to search for the space character ' ', just do
    strchr(karmarkar, ' ')
If you want the actual substring "s" "p" "a" "c" "e", use
    strstr(karmarkar, "space")

-- 
Damn the living - It's a lovely life.           I'm whoever you want me to be.
Silver silverware - Where is the love?       At least I can stay in character.
Oval swimming pool - Where is the love?    Annoying Usenet one post at a time.
Damn the living - It's a lovely life.                              In 1492....

[toc] | [prev] | [next] | [standalone]

#3952

On 5/14/2011 7:05 AM, janus wrote:
> Hello All,
>
> I found this is a code I am currently studying, could someone explain it to me.
>
> char * string = "Simulated Annealing = 12847369";
> char * value = strchr(string, '=');
>
> *(value ++ ) = 0;
>
>
> printf("%s ==== %s", value, string);
>
> I noticed that sting will print in a new line, why this?

     Another thing it is likely to print is "SIGSEGV" or "SIGBUS" or
"General Protection Fault" or something along those lines.  The
anonymous array created by the string literal is not `const', but
that's just an accident of history.  Trying to modify such an array
yields undefined behavior -- and indeed, plenty of compilers will
put the arrays in read-only memory.  (This allows them to save space
by allocating just one array to hold both of "over" and "recover".)

     If you want a modifiable string, use the literal as an initializer:

	char string[] = "Simulated Annealing = 12847369";

This gives you an ordinary (named) array that you can modify at will,
initialized with the characters of the string literal.

> char* karmarkar = "Karmarkar   958572";
> I want to use strchr to find the first occurrence of "space" in string karmarkar.
> How do I do that?

	char *space = strchr(karmarkar, ' ');
	if (space == NULL)
	    printf ("No spaces\n");
	else
	    printf ("First space is at position %u\n",
	        (unsigned)(space - karmarkar));

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

[toc] | [prev] | [next] | [standalone]

#4035

Eric Sosman writes:
> 	char *space = strchr(karmarkar, ' '); if (space == NULL)
> 	    printf ("No spaces\n");
> 	else
> 	    printf ("First space is at position %u\n",
> 	        (unsigned)(space - karmarkar));

This could give the wrong answer on implementations where PTRDIFF_MAX > 
UINT_MAX.

[toc] | [prev] | [next] | [standalone]

#4038

On 5/15/2011 5:37 PM, sandeep wrote:
> Eric Sosman writes:
>> 	char *space = strchr(karmarkar, ' '); if (space == NULL)
>> 	    printf ("No spaces\n");
>> 	else
>> 	    printf ("First space is at position %u\n",
>> 	        (unsigned)(space - karmarkar));
>
> This could give the wrong answer on implementations where PTRDIFF_MAX>
> UINT_MAX.

     Thank you so very, very much for this helpful observation,
guaranteed to clarify matters for the O.P.  Maybe I should have
written

	printf ("First space is at position %g\n",
	    (double)(space - karmarkar));

... but then I'm sure you'd point out that it might print the
wrong answer if the first space was more than 1E37 characters
(10000000000000000000000000000000000000 characters) into the
string, and would very likely print only an approximate answer
for many shorter strings.  I await your enlightening disquisition
on this vital matter with great eagerness.

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

[toc] | [prev] | [next] | [standalone]

#4039

Eric Sosman wrote:
> 
> On 5/15/2011 5:37 PM, sandeep wrote:
> > Eric Sosman writes:
> >>      char *space = strchr(karmarkar, ' '); if (space == NULL)
> >>          printf ("No spaces\n");
> >>      else
> >>          printf ("First space is at position %u\n",
> >>              (unsigned)(space - karmarkar));
> >
> > This could give the wrong answer on implementations
> > where PTRDIFF_MAX > UINT_MAX.
> 
>      Thank you so very, very much for this helpful observation,
> guaranteed to clarify matters for the O.P. 

sandeep is wrong.
The context (snipped by sandeep)
for which your code was written, is this:
    char* karmarkar = "Karmarkar   958572";

And in that context, there is no way that the difference
between (space) and (karmarkar) can excede either UINT_MAX
or PTRDIFF_MAX (which would be a different C trivia point).

-- 
pete

[toc] | [prev] | [next] | [standalone]

#4040

pete wrote:
> 
> Eric Sosman wrote:
> >
> > On 5/15/2011 5:37 PM, sandeep wrote:
> > > Eric Sosman writes:
> > >>      char *space = strchr(karmarkar, ' '); if (space == NULL)
> > >>          printf ("No spaces\n");
> > >>      else
> > >>          printf ("First space is at position %u\n",
> > >>              (unsigned)(space - karmarkar));
> > >
> > > This could give the wrong answer on implementations
> > > where PTRDIFF_MAX > UINT_MAX.
> >
> >      Thank you so very, very much for this helpful observation,
> > guaranteed to clarify matters for the O.P.
> 
> sandeep is wrong.
> The context (snipped by sandeep)
> for which your code was written, is this:
>     char* karmarkar = "Karmarkar   958572";
> 
> And in that context, there is no way that the difference
> between (space) and (karmarkar) can excede either UINT_MAX
> or PTRDIFF_MAX (which would be a different C trivia point).

I should have been more clear.
Whether or not (PTRDIFF_MAX > UINT_MAX) is true, is irrelevant.
This code cannot give the wrong answer.

What matters, 
in terms of whether or not the code is undefined, 
is whether or not (space - karmarkar)
is representable as a ptrdiff_t value.

Since (space - karmarkar)
is representable as a ptrdiff_t value,
then what matters, 
in terms of whether or not the code outputs the correct answer,
is whether or not (space - karmarkar) 
is less than or equal to UINT_MAX.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#4094

Eric Sosman writes:
> On 5/15/2011 5:37 PM, sandeep wrote:
>> Eric Sosman writes:
>>> 	char *space = strchr(karmarkar, ' '); if (space == NULL)
>>> 	    printf ("No spaces\n");
>>> 	else
>>> 	    printf ("First space is at position %u\n",
>>> 	        (unsigned)(space - karmarkar));
>>
>> This could give the wrong answer on implementations where PTRDIFF_MAX>
>> UINT_MAX.
> 
>      Thank you so very, very much for this helpful observation,
> guaranteed to clarify matters for the O.P.  Maybe I should have written
> 
> 	printf ("First space is at position %g\n",
> 	    (double)(space - karmarkar));
> 
> ... but then I'm sure you'd point out that it might print the wrong
> answer if the first space was more than 1E37 characters
> (10000000000000000000000000000000000000 characters) into the string, and
> would very likely print only an approximate answer for many shorter
> strings.  I await your enlightening disquisition on this vital matter
> with great eagerness.

You are very welcome, Eric. I would say that it is actually quite a minor 
point, but it's good not to get into bad habits!

I would advise using the %td format specifier for ptrdiff_t values: it is 
generally better not to use double for integer values, but instead use a 
large enough integer type (or a bignum library if the basic C types are 
insufficient).

In C90 there is no ptrdiff_t, so casting to (signed long int) and using %
ld may be best. I don't know if pointer expressions in C90 are allowed to 
yield wider types than long int.

[toc] | [prev] | [next] | [standalone]

#4097

On 5/16/2011 14:27, sandeep wrote:
> In C90 there is no ptrdiff_t, so casting to (signed long int) and using %
> ld may be best. I don't know if pointer expressions in C90 are allowed to
> yield wider types than long int.

Are you certain of that?  I have a document which predates ANSI 
X3.159-1989 (C89, right?) and which appears to include it.

[toc] | [prev] | [next] | [standalone]

#4098

sandeep <nospam@nospam.com> writes:
[...]
> In C90 there is no ptrdiff_t, so casting to (signed long int) and using %
> ld may be best. I don't know if pointer expressions in C90 are allowed to 
> yield wider types than long int.

Yes, C90 does have ptrdiff_t; see C90 7.1.6.

C90 doesn't have a printf conversion specifier for ptrdiff_t, but
converting to long should be enough; ptrdiff_t is a typedef for a
signed integer type, and C90 has no predefined signed type wider
than long.

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

[toc] | [prev] | [next] | [standalone]

#4107

On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
> C90 doesn't have a printf conversion specifier for ptrdiff_t, but
> converting to long should be enough; ptrdiff_t is a typedef for a
> signed integer type, and C90 has no predefined signed type wider
> than long.

Unfortunately, nearly every implementation now in use which is being used
in "C90" mode actually has "long long".  With no stable way to print it...

*sigh*

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4112

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
>> C90 doesn't have a printf conversion specifier for ptrdiff_t, but
>> converting to long should be enough; ptrdiff_t is a typedef for a
>> signed integer type, and C90 has no predefined signed type wider
>> than long.
>
> Unfortunately, nearly every implementation now in use which is being used
> in "C90" mode actually has "long long".  With no stable way to print it...
>
> *sigh*

But do any of them make ptrdiff_t (or any other predefined typedef)
wider than long?  If not, then using "%ld" and a cast to long is
enough for this particular case.  (And even if ptrdiff_t is wider
than long, it's only a problem if the actual value being printed
exceeds LONG_MAX.)

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

[toc] | [prev] | [next] | [standalone]

#4118

On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
>> Unfortunately, nearly every implementation now in use which is being used
>> in "C90" mode actually has "long long".  With no stable way to print it...

> But do any of them make ptrdiff_t (or any other predefined typedef)
> wider than long?  If not, then using "%ld" and a cast to long is
> enough for this particular case.  (And even if ptrdiff_t is wider
> than long, it's only a problem if the actual value being printed
> exceeds LONG_MAX.)

I'm not sure.  I think there is probably at least one with 64-bit pointers
and 32-bit longs.

Ah, well.  I don't actually care anymore; I just ignore implementations which
don't have long long, snprintf, and designated initializers.  For the most
part this works out.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4119

Keith Thompson writes:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
>>> C90 doesn't have a printf conversion specifier for ptrdiff_t, but
>>> converting to long should be enough; ptrdiff_t is a typedef for a
>>> signed integer type, and C90 has no predefined signed type wider than
>>> long.
>>
>> Unfortunately, nearly every implementation now in use which is being
>> used in "C90" mode actually has "long long".  With no stable way to
>> print it...
>>
>> *sigh*
> 
> But do any of them make ptrdiff_t (or any other predefined typedef)
> wider than long?  If not, then using "%ld" and a cast to long is enough
> for this particular case.  (And even if ptrdiff_t is wider than long,
> it's only a problem if the actual value being printed exceeds LONG_MAX.)

If this is a risk, it would be better to cast to (unsigned long int): 
even if the answer was wrong at least there would be no danger of 
triggering an undefined behavior by overflow.

This code would be even safer:
ptrdiff_t pd=space - karmarkar;
if(pd<=ULONG_MAX) printf("First space is at position %lu\n",(unsigned 
long int)pd);
else printf("First space is at position NaN\nWarning overflow error 
detected, please update your C compiler");

Even better else part (in pseudocode):

else {
char* s=karmarkar;
bignum n=new_bignum(0);
while(*s++!=' ')add_bignum(n,n,1);
print_bignum("First space is at position ",n);
}

[toc] | [prev] | [next] | [standalone]

#4129

sandeep <nospam@nospam.com> writes:

> Keith Thompson writes:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
>>>> C90 doesn't have a printf conversion specifier for ptrdiff_t, but
>>>> converting to long should be enough; ptrdiff_t is a typedef for a
>>>> signed integer type, and C90 has no predefined signed type wider than
>>>> long.
>>>
>>> Unfortunately, nearly every implementation now in use which is being
>>> used in "C90" mode actually has "long long".  With no stable way to
>>> print it...
>>>
>>> *sigh*
>> 
>> But do any of them make ptrdiff_t (or any other predefined typedef)
>> wider than long?  If not, then using "%ld" and a cast to long is enough
>> for this particular case.  (And even if ptrdiff_t is wider than long,
>> it's only a problem if the actual value being printed exceeds LONG_MAX.)
>
> If this is a risk, it would be better to cast to (unsigned long int): 
> even if the answer was wrong at least there would be no danger of 
> triggering an undefined behavior by overflow.

I'd say it's a bad idea.  ptrdiff_t is signed so converting it to an
unsigned type for printing will produce unexpected results.

BTW, the conversions don't overflow.  In particular, the behaviour is
implementation defined, not undefined; though the difference is slight
in portable code.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#4672

On Mon, 16 May 2011 23:22:00 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

> sandeep <nospam@nospam.com> writes:
> 
> > Keith Thompson writes:
<snip: print ptrdiff_t as long in C90?>
> > If this is a risk, it would be better to cast to (unsigned long int): 
> > even if the answer was wrong at least there would be no danger of 
> > triggering an undefined behavior by overflow.
> 
> I'd say it's a bad idea.  ptrdiff_t is signed so converting it to an
> unsigned type for printing will produce unexpected results.
> 
In general it can, but in many situations including the one upthread
you know the value is nonnegative; then unsigned is 'right'.

> BTW, the conversions don't overflow.  In particular, the behaviour is
> implementation defined, not undefined; though the difference is slight
> in portable code.
> 
> <snip>

[toc] | [prev] | [next] | [standalone]

#4299

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

> On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
>> C90 doesn't have a printf conversion specifier for ptrdiff_t, but
>> converting to long should be enough; ptrdiff_t is a typedef for a
>> signed integer type, and C90 has no predefined signed type wider
>> than long.
>
> Unfortunately, nearly every implementation now in use which is being used
> in "C90" mode actually has "long long".  [snip]

If it's actually conforming to C90 then 'long long'
requires a diagnostic, yes?

[toc] | [prev] | [next] | [standalone]

#4322

On 2011-05-19, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
>>> C90 doesn't have a printf conversion specifier for ptrdiff_t, but
>>> converting to long should be enough; ptrdiff_t is a typedef for a
>>> signed integer type, and C90 has no predefined signed type wider
>>> than long.

>> Unfortunately, nearly every implementation now in use which is being used
>> in "C90" mode actually has "long long".  [snip]

> If it's actually conforming to C90 then 'long long'
> requires a diagnostic, yes?

Probably, but I've yet to encounter a compiler which is pedantic about such
things in its default mode...

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4332

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-19, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> On 2011-05-16, Keith Thompson <kst-u@mib.org> wrote:
>>>> C90 doesn't have a printf conversion specifier for ptrdiff_t, but
>>>> converting to long should be enough; ptrdiff_t is a typedef for a
>>>> signed integer type, and C90 has no predefined signed type wider
>>>> than long.
>
>>> Unfortunately, nearly every implementation now in use which is being used
>>> in "C90" mode actually has "long long".  [snip]
>
>> If it's actually conforming to C90 then 'long long'
>> requires a diagnostic, yes?
>
> Probably, but I've yet to encounter a compiler which is pedantic about such
> things in its default mode...

I've yet to encounter a C compiler that conforms to *any* standard in
its default mode.  (Disclaimer: There are plenty of C compilers I
haven't encountered.)

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

[toc] | [prev] | [next] | [standalone]

#4336

On 2011-05-19, Keith Thompson <kst-u@mib.org> wrote:
> I've yet to encounter a C compiler that conforms to *any* standard in
> its default mode.  (Disclaimer: There are plenty of C compilers I
> haven't encountered.)

You know, I was going to agree, but then I realized I was thinking too
narrowly; I was thinking only of *C* standards.  I am pretty sure there
is at least one compiler which complies with at least one standard.

Or would if the person whose standards were in question were sufficiently
drunk, anyway.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web