bug? instruction not compiled below comment

[walter]

I wrote a program, and found one line of source code
not compiled out. I rewrote it for simplicity as below.
The comment in the program is big5 code text.

--- my program ---
main(){
int i, a[8];
for (i=0;i<3;i++) a=0;
// ÁקK³Q·j´M¦¨¥\
a[3]=-1;

for (i=0;i<4;i++)
printf("%d ",a);
}
--- end of my program ---

The output is not "0 0 0 -1" because the comment is ended
with "\", and this makes a[3]=-1 to be regarded as comment.

I wonder this is a bug or not?

 

[Robert Stankowic]

I wrote a program, and found one line of source code
not compiled out. I rewrote it for simplicity as below.
The comment in the program is big5 code text.

--- my program ---
main(){
int i, a[8];
for (i=0;i<3;i++) a=0;
// ÁקK³Q·j´M¦¨¥\
a[3]=-1;

for (i=0;i<4;i++)
printf("%d ",a);
}
--- end of my program ---

The output is not "0 0 0 -1" because the comment is ended
with "\", and this makes a[3]=-1 to be regarded as comment.

I wonder this is a bug or not?

No bug. the '\' at the end "escapes" the newline and therefore the comment
does not end here
Robert

 

[Irrwahn Grausewitz]

I wrote a program, and found one line of source code
not compiled out. I rewrote it for simplicity as below.
The comment in the program is big5 code text.

--- my program ---

main(){ int main( void ){
int i, a[8];
for (i=0;i<3;i++) a=0;
// ÁקK³Q·j´M¦¨¥\
a[3]=-1;

for (i=0;i<4;i++)
printf("%d ",a); return 0;
}
--- end of my program ---

The output is not "0 0 0 -1" because the comment is ended
with "\", and this makes a[3]=-1 to be regarded as comment.

I wonder this is a bug or not?

Per definition in the standard, the C preprocessor is required to
delete any backslash immediately followed by a new-line character,
thus "splicing physical source lines to form logical source lines".
This splicing happens prior to tokenization and comment elimination.

Therefore I consider the above construct to be a flaw in your code.

FWIW, the compiler I use emits a "warning: multi-line comment"
diagnostic.

HTH
Regards

 

[Kevin Bracey]

In message <[email protected]>

--- my program ---
main(){
int i, a[8];
for (i=0;i<3;i++) a=0;
// ÁקK³Q·j´M¦¨¥\
a[3]=-1;

for (i=0;i<4;i++)
printf("%d ",a);
}
--- end of my program ---

The output is not "0 0 0 -1" because the comment is ended
with "\", and this makes a[3]=-1 to be regarded as comment.

I wonder this is a bug or not?

I suspect your compiler isn't specified as handling Big5 source files. Big5
is not a terribly good encoding method, for exactly this reason - standard
ASCII-type tools are liable to misinterpret it. You're likely to have even
worse problems in string literals.

 

[Simon Biber]

I wrote a program, and found one line of source code
not compiled out. I rewrote it for simplicity as below.
The comment in the program is big5 code text.

I recommend you use UTF-8 code instead, as it does not
suffer from this problem. All non-ASCII characters are
encoded using only characters with values outside the
ASCII set, so there are no surprises with backslashes
or any other characters.

So, instead of writing: // ÁקK³Q·j´M¦¨¥\
write: // é¿å…被æœå°‹æˆåŠŸ

I wonder this is a bug or not?

If your compiler specifies that it takes BIG5-encoded text
as input, then this is a bug. If the compiler specifies that
it takes ASCII or any ISO-8859 encoded text, then it is not
a bug, because there really is a backslash as the final
character in the line.

 

[walter]

Irrwahn Grausewitz:

The output is not "0 0 0 -1" because the comment is ended
with "\", and this makes a[3]=-1 to be regarded as comment.

I wonder this is a bug or not?

Per definition in the standard, the C preprocessor is required to
delete any backslash immediately followed by a new-line character,
thus "splicing physical source lines to form logical source lines".
This splicing happens prior to tokenization and comment elimination.

Therefore I consider the above construct to be a flaw in your code.

FWIW, the compiler I use emits a "warning: multi-line comment"
diagnostic.

HTH
Regards

I found a compile option -Wcomment, which could generate
"warning: multi-line comment" message. I've add this
option to my makefile. Thanks for your information.

Regards,

 

[Irrwahn Grausewitz]

Irrwahn Grausewitz:

I found a compile option -Wcomment, which could generate
"warning: multi-line comment" message. I've add this
option to my makefile. Thanks for your information.

<OT>
If you're using gcc you should include "-W -Wall" in the command line.
(No, -Wall on itself doesn't turn on all [generally useful] warnings.)
</OT>

Regards

 

[CBFalconer]

I wrote a program, and found one line of source code
not compiled out. I rewrote it for simplicity as below.
The comment in the program is big5 code text.

--- my program ---
main(){
int i, a[8];
for (i=0;i<3;i++) a=0;
// ÁקK³Q·j´M¦¨¥\
a[3]=-1;

for (i=0;i<4;i++)
printf("%d ",a);
}
--- end of my program ---

The output is not "0 0 0 -1" because the comment is ended
with "\", and this makes a[3]=-1 to be regarded as comment.

I wonder this is a bug or not?

If you don't have a C99 compliant compiler, the line beginning
with // is a syntax error in the first place. C90 comments are
enclosed in /* ... */.

If you do have a C99 compiler (doubtful), the terminal '\' is
documented as splicing lines together, so that the "a[3]..." is
part of the comment line.

If you are using something with non-standard extensions, it is up
to you to understand what they are doing. c.l.c cannot help you,
simply because they are non-standard, undocumented (to us), and we
just don't understand them. Such questions are off-topic here.

 

[Dan Pop]

<OT>
If you're using gcc you should include "-W -Wall" in the command line.
(No, -Wall on itself doesn't turn on all [generally useful] warnings.)
</OT>

-Wall on itself doesn't turn on all generally useful warnings, but the
right companion option for achieving this purpose is -O, not -W.

The warnings generated by -W have been excluded from -Wall precisely
because far too many people don't consider them as being generally useful.
IMHO, they're more like a source of compiler noise: far too much *correct*
C code triggers them.

Dan

 

[CBFalconer]

Irrwahn Grausewitz:

I found a compile option -Wcomment, which could generate
"warning: multi-line comment" message. I've add this
option to my makefile. Thanks for your information.

<OT>
If you're using gcc you should include "-W -Wall" in the command line.
(No, -Wall on itself doesn't turn on all [generally useful] warnings.)
</OT>

I routinely include -W -Wall -ansi -pedantic -Wwrite-strings. I
do this by running gcc through an alias (which is bypassed in make
files). I very rarely need to use any less restrictive options.

 

[Irrwahn Grausewitz]

Irrwahn Grausewitz wrote:

<OT>
If you're using gcc you should include "-W -Wall" in the command line.
(No, -Wall on itself doesn't turn on all [generally useful] warnings.)
</OT>

I routinely include -W -Wall -ansi -pedantic -Wwrite-strings. I
do this by running gcc through an alias (which is bypassed in make
files). I very rarely need to use any less restrictive options.

<OT>
Yup. However, Dan made a good point in recommending the -O option.
Otherwise some warnings (e.g. about using uninitialized automatic
variables) are ommitted, because generation of these warnings
requires information that is only available in optimizing mode.
</OT>

Regards

 

[Dan Pop]

Irrwahn Grausewitz:

FWIW, the compiler I use emits a "warning: multi-line comment"
diagnostic.

I found a compile option -Wcomment, which could generate
"warning: multi-line comment" message. I've add this
option to my makefile. Thanks for your information.

<OT>
If you're using gcc you should include "-W -Wall" in the command line.
(No, -Wall on itself doesn't turn on all [generally useful] warnings.)
</OT>

I routinely include -W -Wall -ansi -pedantic -Wwrite-strings. I
do this by running gcc through an alias (which is bypassed in make
files). I very rarely need to use any less restrictive options.

You must be a very lucky guy if you "very rarely" need to use platform
extensions, whose declarations/definitions in the standard headers are
suppressed by -ansi.

However, without -O, you'll *never* get warnings about using uninitialised
variables. But maybe you don't care about such things... ;-)

Dan

 

[CBFalconer]

Irrwahn Grausewitz:
<snip>
FWIW, the compiler I use emits a "warning: multi-line comment"
diagnostic.

I found a compile option -Wcomment, which could generate
"warning: multi-line comment" message. I've add this
option to my makefile. Thanks for your information.

<OT>
If you're using gcc you should include "-W -Wall" in the command
line. (No, -Wall on itself doesn't turn on all [generally useful]
warnings.) </OT>

I routinely include -W -Wall -ansi -pedantic -Wwrite-strings. I
do this by running gcc through an alias (which is bypassed in make
files). I very rarely need to use any less restrictive options.

You must be a very lucky guy if you "very rarely" need to use
platform extensions, whose declarations/definitions in the standard
headers are suppressed by -ansi.

However, without -O, you'll *never* get warnings about using
uninitialised variables. But maybe you don't care about such
things... ;-)

I left off my usual -O1 to avoid flaps about optimization versus
debuggers. Oh well.

At any rate, there is a strong resemblance to chickens and eggs.
My code tends to be portable because I use those options because
my code tends to be portable because ....

 

[Dan Pop]

At any rate, there is a strong resemblance to chickens and eggs.
My code tends to be portable because I use those options because
my code tends to be portable because ....

More likely because it doesn't attempt to solve any real life programming
problems that aren't filters getting their input from stdin and producing
their output on stdout.

Dan