++*p++

  • Thread starter karthikbalaguru
  • Start date
K

karthikbalaguru

Hi,

#include<stdio.h>
int main(void)
{
char *p="Hello",*p1;
p1=p;
while(*p!='\0')
++*p++;
printf("%s %s",p,p1);
return 0;
}

For the above code,
is it correct to get the output as ' Ifmmp' ?
Any ideas ?

Thx in advans,
Karthik Balaguru
 
G

Guest

#include<stdio.h>
int main(void)
{
   char *p="Hello",*p1;
   p1=p;
   while(*p!='\0')
      ++*p++;
   printf("%s %s",p,p1);
   return 0;

}

For the above code,
is it correct to get the output as ' Ifmmp' ?
Any ideas ?

if this program runs on an ascii machine then adding 1 to every
character in "Hello" yeilds "Ifmmp".

I'm not cetain if ++*p++ has defined behaviour.
Modifying a string literal certainly doesn't.

So the program could do anything. As it is p is left
pointing to nul so printing it produces nothing
the there's a space the there's "Hello" with all
its characters incremented.

What did you expect it to do? Why did you write it?
 
K

karthikbalaguru

if this program runs on an ascii machine then adding 1 to every
character in "Hello" yeilds "Ifmmp".

I'm not cetain if ++*p++ has defined behaviour.
Modifying a string literal certainly doesn't.

So the program could do anything. As it is p is left
pointing to nul so printing it produces nothing
the there's a space the there's "Hello" with all
its characters incremented.

What did you expect it to do? Why did you write it?

I was expecting undefined behaviour. But, i got
an unexpected correct logical output in gcc. :) !! :(

I did find -fwritable-strings option which makes
the string literal non-constant. I think, that option
is enabled by default in gcc.

I wonder about the use of this option if string literals
cannot be modified as per the standards !!

But, does this behaviour confirm to the standards as
Visual C++ 2008 Express edition does not allow such
modifications ? Any ideas ?

Thx in advans,
Karthik Balaguru
 
E

Eric Sosman

karthikbalaguru said:
Hi,

#include<stdio.h>
int main(void)
{
char *p="Hello",*p1;
p1=p;
while(*p!='\0')
++*p++;
printf("%s %s",p,p1);
return 0;
}

For the above code,
is it correct to get the output as ' Ifmmp' ?
Any ideas ?

My principal idea is that your questions exhibit an
unhealthy fascination with undefined behavior. But to
the question "Is it correct," the answer is "Yes" because
any outcome at whatsoever would be correct.
 
K

Kojak

Le Tue, 3 Mar 2009 04:56:17 -0800 (PST),
karthikbalaguru a écrit :
#include<stdio.h>
int main(void)
{
char *p="Hello",*p1;

char *p = "Hello" implies UB if you try to modify the content
of p. Better write const char *p="Hello" to keep in mind to
don't try to modify p.

Try to allocate memory to p then copy "Hello". Something like
this:
p = malloc(8 * sizeof(char));
strcpy(p, "hello");

And, of course, don't forget to include required header and
to check return values.

Or, another way is using char p[], but you need to modify
slightly your code.

p1=p;
while(*p!='\0')
++*p++;
printf("%s %s",p,p1);

Remember, you've incremented the pointer p, now it point
after Hello, then, guess what... :)

hth,
 
A

Alexander Grigoriev

This IS UNDEFINED BEHAVIOR. It may match "expected", or the program may
crash, or anything.

Undefined behavior means the compiler doesn't have to produce any specific
behavior in such case.

if this program runs on an ascii machine then adding 1 to every
character in "Hello" yeilds "Ifmmp".

I'm not cetain if ++*p++ has defined behaviour.
Modifying a string literal certainly doesn't.

So the program could do anything. As it is p is left
pointing to nul so printing it produces nothing
the there's a space the there's "Hello" with all
its characters incremented.

What did you expect it to do? Why did you write it?

I was expecting undefined behaviour. But, i got
an unexpected correct logical output in gcc. :) !! :(

I did find -fwritable-strings option which makes
the string literal non-constant. I think, that option
is enabled by default in gcc.

I wonder about the use of this option if string literals
cannot be modified as per the standards !!

But, does this behaviour confirm to the standards as
Visual C++ 2008 Express edition does not allow such
modifications ? Any ideas ?

Thx in advans,
Karthik Balaguru
 
M

Mark Wooding

karthikbalaguru said:
#include<stdio.h>
int main(void)
{
char *p="Hello",*p1;
p1=p;
while(*p!='\0')
++*p++;
printf("%s %s",p,p1);
return 0;
}

For the above code,
is it correct to get the output as ' Ifmmp' ?

Yes, since the behaviour of this program is undefined. In particular,
it attempts to modify the characters of a string literal. Because the
behaviour is undefined, any possible behaviour is as `correct' as any
other.

Here's a similar program whose behaviour is not undefined.

#include <stdio.h>

int main(void)
{
char buf[] = "Hello";
char *p = buf;
while (*p)
++*p++;
printf("%s %s\n", p, buf);
return (0);
}

This program outputs ` Ifmmp' on my system. This is a likely result on
systems which use ASCII-based character sets; other character sets may
produce other results. (In particular, I forget where the intra-letter-
block gaps are in EBCDIC.)

Why does it do this? Well, let's start with the article subject:
++*p++. This parses as

++(*(p++))

So, first, we grab the value of p and put it aside somewhere. Now, we
increment p. We retrieve the old value we put aside, and then increment
the character value found at that address. The result is as if we'd
written

{ char *q = p; p++; (*q)++; }

(Warning: I've introduced too much sequencing in this description. The
update of p may happen at any stage of the proceedings: it might happen
before or after the update of the character pointed to by the old value
of p, and so on.)

So: the while loop does this:

if the character code pointed to by p is nonzero, then:
increment the code by one
move the pointer p along one
and try again

In ASCII, the character codes for letters form two contiguous block (for
upper- and lower-cases), so you see the letters advancing through the
alphabet. Well, except for `z' and `Z', which didn't turn up.

-- [mdw]
 
A

Antoninus Twink

My principal idea is that your questions exhibit an
unhealthy fascination with undefined behavior.

He should have a long future ahead of him in clc then.
 
K

karthikbalaguru

karthikbalaguru said:
#include<stdio.h>
int main(void)
{
   char *p="Hello",*p1;
   p1=p;
   while(*p!='\0')
      ++*p++;
   printf("%s %s",p,p1);
   return 0;
}
For the above code,
is it correct to get the output as ' Ifmmp' ?

Yes, since the behaviour of this program is undefined.  In particular,
it attempts to modify the characters of a string literal.  Because the
behaviour is undefined, any possible behaviour is as `correct' as any
other.

Here's a similar program whose behaviour is not undefined.

        #include <stdio.h>

        int main(void)
        {
          char buf[] = "Hello";
          char *p = buf;
          while (*p)
            ++*p++;
          printf("%s %s\n", p, buf);
          return (0);
        }

This program outputs ` Ifmmp' on my system.  This is a likely result on
systems which use ASCII-based character sets; other character sets may
produce other results.  (In particular, I forget where the intra-letter-
block gaps are in EBCDIC.)

Why does it do this?  Well, let's start with the article subject:
++*p++.  This parses as

        ++(*(p++))

So, first, we grab the value of p and put it aside somewhere.  Now, we
increment p.  We retrieve the old value we put aside, and then increment
the character value found at that address.  The result is as if we'd
written

        { char *q = p; p++; (*q)++; }

(Warning: I've introduced too much sequencing in this description.  The
update of p may happen at any stage of the proceedings: it might happen
before or after the update of the character pointed to by the old value
of p, and so on.)

So: the while loop does this:

  if the character code pointed to by p is nonzero, then:
    increment the code by one
    move the pointer p along one
    and try again

In ASCII, the character codes for letters form two contiguous block (for
upper- and lower-cases), so you see the letters advancing through the
alphabet.  Well, except for `z' and `Z', which didn't turn up.

I did find an option called -fwritable-strings which makes
the string literal non-constant in gcc.
I think, that option is enabled by default in gcc.

But, what could be the use of this option if string literals
are supposed to be un-modifiable as per the standards !!

Where does the -fwritable-strings option come helpful ?
and Why has it been designed against the standards
definition of string literal ? Any ideas ?

Thx in advans,
Karthik Balaguru
 
N

Nate Eldredge

karthikbalaguru said:
I did find an option called -fwritable-strings which makes
the string literal non-constant in gcc.
I think, that option is enabled by default in gcc.

Depends on your system, perhaps. On mine it's disabled by default, and
I think this is the more common situation.
But, what could be the use of this option if string literals
are supposed to be un-modifiable as per the standards !!

The standard doesn't say they are supposed to be un-modifiable. The
standard says an attempt to modify them has undefined behavior. A
particular implementation can define for itself what happens in this
case. For gcc -fwritable-strings, the string gets modified. On my
system, for gcc without -fwritable-strings, the result is a segmentation
fault.
Where does the -fwritable-strings option come helpful ?
and Why has it been designed against the standards
definition of string literal ? Any ideas ?

Some C compilers allowed string literals to be modified, and some
pre-standard C code made use of this feature. Using -fwritable-strings
might allow you to keep using such code, if you didn't want to fix it.
 
E

Eric Sosman

karthikbalaguru said:
[...]
I was expecting undefined behaviour. But, i got
an unexpected correct logical output in gcc. :) !! :(

You have failed to understand "undefined behavior."

"Undefined behavior" means "Behavior not covered by
the definition of the C language."

Period.

"Undefined behavior" does *not* mean "There will be
an error message."

"Undefined behavior" does *not* mean "Your hard drive
will be completely erased."

"Undefined behavior" does *not* mean "You will get the
result you hoped for."

And here's the paradox: "Undefined behavior" means *all*
of these things, and more. It means *any* behavior whatsoever,
expected or unexpected, welcome or unwelcome. It means you
might get what you thought you ought to, or you might get
something completely different, or you might get demons flying
out of your nostrils.

In short, the program you posted *did* engage in undefined
behavior -- you just failed to recognize it as such.
 
G

Guest

On 3 Mar, 12:56, karthikbalaguru <[email protected]> wrote:
Modifying a string literal certainly doesn't [have defined behaviour].

It exhibits "undefined behaviour"

Note well...
I was expecting undefined behaviour.

What do you think "undefined behaviour" *is*.
"When I ordered my car I didn't specify the colour.
They gave me a red one. Why didn't they give me
one with an Unspecified Colour?"
But, i got
an unexpected correct logical output in gcc. :) !! :(

how can you expect anything?

I did find -fwritable-strings option which makes
the string literal non-constant. I think, that option
is enabled by default in gcc.
ok...

I wonder about the use of this option if string literals
cannot be modified as per the standards !!

The standard does not say they cannot be modified.
It says the behaviour of a program that does so is not defined
(is not specified).

If The Standard leaves a behaviour undefined (or specifically
states that something results in undefined behaviour) then
The Implementor (the compiler writer) is permitted, by the standard,
to do anything he damn well pleases. Including the behaviour you
"expected"
or didn't expect or... whatever.
But, does this behaviour confirm [conform?] to the standards

it conforms to the behaviour as no behaviour is specified
as
Visual C++ 2008 Express edition does not allow such
modifications ?

VCC C++ 2008 also conforms.
Any ideas ?

you have not grokked UB in its fullness


--
Nick Keighley

"I believe in lots of things most other people don't, including magic
and free lunches. The internet works. Bank ATM networks work. The
global financial system works. The telephone system works."
Robert Myers (alt.folklore.computers)
 
F

Falcon Kirtaran

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was expecting undefined behaviour. But, i got
an unexpected correct logical output in gcc. :) !! :(

I did find -fwritable-strings option which makes
the string literal non-constant. I think, that option
is enabled by default in gcc.

I wonder about the use of this option if string literals
cannot be modified as per the standards !!

But, does this behaviour confirm to the standards as
Visual C++ 2008 Express edition does not allow such
modifications ? Any ideas ?

Thx in advans,
Karthik Balaguru

I would not by any means ever consider MSVC++ an exemplar of the C
standard, especially given that it is not really an implementation of
it. If you want to learn about the intricacies of C, using a C compiler
on a UNIX system is probably the best way to experiment.

By cross-posting something such as this to comp.os.linux.advocacy and
microsoft.public.vc.mfc, both of which have almost exactly nothing to do
with this, you implicate yourself in trolling.

- --
- --Falcon Darkstar Christopher Momot
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJrtjfAAoJEKmxP9YxEE4r0PMQAMqH5JaewbDcSY1PlYRlwxMz
b1OY5ZQcUenzP9KAbr7wt2ocvo3R1HKOgQ8mjBTnCo49p+DmSb+ckROtdhzjGnva
9EjDGb7Tgd4XFnSlqbjIWBiBw9N7+QJEd+5NApehNRNIPhpDM+x2dS77irrk6sTN
7KHAMBNZiIHtsfGEB0IDd8aghq17KV2KUdf7EDoK9ESZvUXM8j43/mcEtM5F11Bv
h8pkjVdMmp/EB2cFzurF4z/emSQUi4m3m3el4dCiZlY5Np0t146zOPhwIxPZekM+
LUucMBfit21tQp7HfNT7YzllaRjh2xTmksFlsGBJmvN3wCAuwtD1nqnSz1+CpziV
qbBuAUoxooX7ROKvgPb3bIzmYcGg47agz15iNGChFOTRNf7ocvqJhVSwk/cQ0A3R
27WYyP1Pt+baCGY9xsE5GXmDpmYhXftZZ0Jd14lNlbDRMSswZaEebNZgwp3TmQlF
wkp2Qg09P9RBIGfEQSSzOU/V1EzioDeLlqda5qzFkHFpWmb8wyxgo1Ww3lJiB49s
baIpxpxNHnjELGquQULtCX0j7l16zDn25bPQxZnXVykNHchWN/l3ppvoLnZGctC6
l8XWe31DVCnO571WvOQe4SRqp7L8iTxv+xVsk529P1X/xd1DM2kpFbtMavWBeEGz
GV4Xs4wi8eQxRYgemHiO
=elbg
-----END PGP SIGNATURE-----
 
F

Falcon Kirtaran

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nate said:
Depends on your system, perhaps. On mine it's disabled by default, and
I think this is the more common situation.


The standard doesn't say they are supposed to be un-modifiable. The
standard says an attempt to modify them has undefined behavior. A
particular implementation can define for itself what happens in this
case. For gcc -fwritable-strings, the string gets modified. On my
system, for gcc without -fwritable-strings, the result is a segmentation
fault.


Some C compilers allowed string literals to be modified, and some
pre-standard C code made use of this feature. Using -fwritable-strings
might allow you to keep using such code, if you didn't want to fix it.

Whether ("hello" == "hello") evaluates to 1 or 0, is unspecified.

What should the output of the following fragment be?

"hello"[0] = 'H';

puts("hello");

A compiler error. "hello" is const. If you cast away the constness, I
think the behaviour is undefined (gcc spits out an internal error, anyway).

- --
- --Falcon Darkstar Christopher Momot
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJrtwcAAoJEKmxP9YxEE4rGEYQAJD/BeZoYahXhW7svnxmnWnU
H6586wwyaO6H3Z15W98j5DTEi4wS+A0p5/7/9RGWox2IE1WUNCcRVbimQC3s0Pyu
RlIzDS4kjXv3+sQXBA5ar32+CbWhYkt8AuOL6k5AwgE9pUlOcpuLwJrBYAwA4KW0
X9FaEySEAY+ZEovjnfuvur5LVcH+ytdaiGVtjYGm2AWynvoaTPcFVjqDt5g6dNm2
d86Q2FrF0cEdQxuKRXsAOrfzqYR3ATkCnn4z3evxVrSC3d/K5osvane/q0H8iPIh
3WmE2UBXHWbaRun4+zqfkVNPc4glNlJNJp0vW05nTTW49egnVZ/YAcMkbOneExRo
bmxs0gT3FbGaroR9F7lwxcZdQFJiuV4q7xL1x86un3R0du7rpN+pIjbXSa7EBTj/
Secc15cXynAGa3gOt7oUOaFgLw5iQSnW/TyJjemKN/BChrVS53O4xkfO18Ghm0J4
hCHbYSHOjnahSdIbSuayB7AE3PfkFrsRzEx1sap961vepQiBBTPZjXMPZlwswWmG
KRr0+SHF5xFWvgDG2M6z82Bu2uK84sZ5arZRZtMwmpE4BVSOsHN33ACgfgS3t3bk
NZobEXlgh+BAiT8+D1hphPDyBJ8itXdZgvsFR0aH3is74trrlj0nrdkGheqaRyeb
0vANObh4G1hPbtvOS2T0
=dWiC
-----END PGP SIGNATURE-----
 
H

Harald van Dijk

pete said:
Nate said:
Some C compilers allowed string literals to be modified, and some
pre-standard C code made use of this feature. Using
-fwritable-strings might allow you to keep using such code, if you
didn't want to fix it.

Whether ("hello" == "hello") evaluates to 1 or 0, is unspecified.

What should the output of the following fragment be?

"hello"[0] = 'H';

puts("hello");

A compiler error. "hello" is const. If you cast away the constness, I
think the behaviour is undefined (gcc spits out an internal error,
anyway).

The context was compilers with extensions to make string literals
writable.

Anyway, this program is strictly conforming:

int main(void) {
if(0) "hello"[0] = 'H';
return 0;
}

gcc rejects this, and this is a minor bug in gcc (and already reported).
The type of a string literal is char [], not const char []. Attempts to
modify a string literal result in undefined behaviour, but if the attempt
to modify one is never made, the code is valid and compilers should not
reject it.

Interestingly, gcc accepts

int main(void) {
if(0) *"hello" = 'H';
return 0;
}

without even a warning.
 
K

Keith Thompson

Falcon Kirtaran said:
pete wrote: [...]
What should the output of the following fragment be?

"hello"[0] = 'H';

puts("hello");

A compiler error. "hello" is const. If you cast away the constness, I
think the behaviour is undefined (gcc spits out an internal error, anyway).

No, "hello" is not const. More generally, the type of a string
literal (without a leading L) array of char, not array of const char
(this decays to char* in most contexts). Attempting to modify a
string literal (more precisely, attempting to modify the array created
by the string literal) invokes undefined behavior -- not because it's
const, but because there's a specific rule that says so. Note that
it's not a constraint violation, so no diagnostic is required.

<OT>
gcc has an option to treat string literals as const; this violates the
C standard, and can cause it to reject some valid code, but it can be
a handy diagnostic. C++ does treat string literals as const.
</OT>
 
G

Guest

I would not by any means ever consider MSVC++ an exemplar of the C
standard,

I believe Microsoft were quite good about following the standard.
Though they don't seem to have any intersst in the 1999 standard
(to the best of my knowledge).
especially given that it is not really an implementation of
it.

what? Microsoft implement the 1989 C standard. It probably isn't
perfect but which implementation is?

 If you want to learn about the intricacies of C, using a C compiler
on a UNIX system is probably the best way to experiment.

why?

<snip>
 
F

Falcon Kirtaran

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

I believe Microsoft were quite good about following the standard.
Though they don't seem to have any intersst in the 1999 standard
(to the best of my knowledge).


what? Microsoft implement the 1989 C standard. It probably isn't
perfect but which implementation is?



why?

<snip>

The idea I'm getting at here is not that Microsoft makes garbage (I'll
leave that up for debate) but that, for a myriad reasons, using a
Microsoft "Visual" C++ compiler is not the greatest way to play with C.
One reason for this is cited by the OP, essentially, in another thread
about %n.

- --
- --Falcon Darkstar Christopher Momot
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJsrUvAAoJEKmxP9YxEE4rRQ4QAINjFAu0ei8/DhXlzlvy+zoX
y3G8gg0jJXtG/J0jIvH4xNnnw6i0O3aJXnIj4zOmn2VUIoqDTEnD4HWJyWQKiUFF
8tZZOYqp4DjASLbapNac7aJ85aph9YQC0ySbs8XrmVUGDNJdL/uEdv5liTSWpIWI
YqgBvMugkTgylua11BHnj+L5j3B/KH1Z2vvm9Abm9VVURSqtE39aejARn1ZIcmla
DWdLiyzR0/posPioCKxnYsKAChx3xUjtp1GLlzuKtbGlowOjbPCk+H9kZ8vy4xDC
G5L9vh9I8Dy2rQ/8v9A9W+GThMs5zEw1DNcYgxwzq4qtLR6KOiHnvZap9H+J1O7s
u2lsLqOWzvTF0E7/d7732LRlY4XYZH16z50YH6hDYh2SJC+nSEucoEYyHW4Yx1+8
psTZbHjzamI0edZSCIWLksQv4ChoXVwIhoNVE4LXpHzMmYeAg73HZk4LXu9g611+
PapUGJnPHBmemsFEcfO7jY4TMVEb//1ytcYbyrzopt+Jsgm459hymhlGeaVkzq+8
w7WvaNwSeZUCCTrcoJG/f64SOm8sfMnPWsAX5yX5bn7EqU7mQ+Ya5CCQuCY1JsUm
kU4PhwWdgEiyulwjRf9p6qspel7YYqnRwUt/ll7B/w0FAC4bks/6mB73FuAl7mej
nWnqxa0W+FXQP0Z35QyG
=PQ6Z
-----END PGP SIGNATURE-----
 
F

Falcon Kirtaran

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

Keith said:
Falcon Kirtaran said:
pete wrote: [...]
What should the output of the following fragment be?

"hello"[0] = 'H';

puts("hello");
A compiler error. "hello" is const. If you cast away the constness, I
think the behaviour is undefined (gcc spits out an internal error, anyway).

No, "hello" is not const. More generally, the type of a string
literal (without a leading L) array of char, not array of const char
(this decays to char* in most contexts). Attempting to modify a
string literal (more precisely, attempting to modify the array created
by the string literal) invokes undefined behavior -- not because it's
const, but because there's a specific rule that says so. Note that
it's not a constraint violation, so no diagnostic is required.

<OT>
gcc has an option to treat string literals as const; this violates the
C standard, and can cause it to reject some valid code, but it can be
a handy diagnostic. C++ does treat string literals as const.
</OT>

Aah. It seems I mixed up the standards.

- --
- --Falcon Darkstar Christopher Momot
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJsrXlAAoJEKmxP9YxEE4r9WwP+wazdC5LGjkGDDZ4oLXWyhix
mJqSwB3qScgoox3dxVLO7S/TUz2uH3hq62uipXphpKXaCQTpPRkCOwq6coicKfbr
t1yyZ62ud3DNHPYAyMcrynAtH41/XrijNoD+nghO+Cd52XX7dV62NlmakqwRAhv4
+qJDVoCzXR+lTFGL5dzd+sZaCDY/CeqRJp65xObBK+HTH64OsteCWrsG8BDkMVYR
wVWvuSGaPJkiiU6MfWqrGsCt1ivYjsGcLLMgi0XtSp6FTBmAZX7kmPSA6nSyXPTg
tj5vt94wR8ttTMYIliuc1ncZdKsbNqduGgOmaHsWYslaMxldD7VVaPohEylAR5ml
zM9aXHNMy5jDv0x7vfWbiR4peraGnexgsn3dFl9s9cIOYOyoNhPTs0BuAY5hK7nC
sd84P0Oy8TNCTVLiz5HvnH7IHSaFGT1DtLDJ931CAsuSweFOUl7XGjGZBGxeRPU3
rnSieVbYj0ZJOCMAgQZKIpS7BOidn9QflktC0mq0DPeao1orkdAHFlr7ttPLUWjE
uUNxBKEamvX+b7DJolmIGIp762ChAQWvQPTX7Fm8+DlURmem+985BojSVe6dyyjd
hEz1K+/2V9lrnNt33B0lTr3lvjeovV87lko8oAB+B4iKd661+zFaX/cscX+qag2P
2BQrGRJlf4iqv6eb0TNz
=ey38
-----END PGP SIGNATURE-----
 
G

Guest

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

In what way is VCC "not really an implementation of [C]"?
The idea I'm getting at here is not that Microsoft makes garbage (I'll
leave that up for debate) but that, for a myriad reasons, using a
Microsoft "Visual" C++ compiler is not the greatest way to play with C.

and what are these myriads of ways? If someone has a windows PC
on his desk and he wants to learn C then why shouldn't he use his
PC? And why not VCC? This just looks like knee jerk MS bashing.
In what way, exactly, is a Unix system superior for learning
"the intricacies of C"?

For the record I've used VCC and gcc (gcc on Unix and Windows).
They are both good.
 One reason for this is cited by the OP, essentially, in another thread
about %n.

I agree that is *really* bad. There being no command line option
to make the compiler compliant is... disappointing
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,982
Messages
2,570,185
Members
46,736
Latest member
AdolphBig6

Latest Threads

Top