function system() from stdlib.h

R

Radamanthe

santosh said:
Harald said:
santosh said:
Ben Bacarisse wrote:

santosh said:

<snip>
Out of curiosity, can you name a compiler that emits this diagnostic?
[for the while(condition); construct]

Not off the top of my head, no.
and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;
The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.
The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.

I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.
For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)

How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

These are just warnings. Actually, this does not change the generated
code at all. I suppose the compiler decides not to warn when there is a
comment before the following case, because an experienced programmer
using this behavior of switch/case generally puts a comment there, just
to inform that the absence of the break statement is intentional (and
not an obvious bug as it is generally). Exploiting this behaviour is
very uncommon practice, so best to warn the reader.

Anyway, I don't think this is a "so wise" feature of the compiler. Lots
of people may have the habit to put comments above cases, thus
forgetting a break would almost certainly pass silently.
 
G

Guest

Radamanthe said:
santosh said:
Harald said:
santosh wrote:
Ben Bacarisse wrote:

santosh said:

<snip>
Out of curiosity, can you name a compiler that emits this diagnostic?
[for the while(condition); construct]

Not off the top of my head, no.
and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;
The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.
The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.

I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.
For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)

How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

These are just warnings. Actually, this does not change the generated
code at all. I suppose the compiler decides not to warn when there is a
comment before the following case, because an experienced programmer
using this behavior of switch/case generally puts a comment there, just
to inform that the absence of the break statement is intentional (and
not an obvious bug as it is generally). Exploiting this behaviour is
very uncommon practice, so best to warn the reader.

Anyway, I don't think this is a "so wise" feature of the compiler. Lots
of people may have the habit to put comments above cases, thus
forgetting a break would almost certainly pass silently.

Only comments containing the word FALLTHROUGH or FALLTHRU are supposed
to cause the warning to be skipped, not just any random comment.
 
R

Richard Tobin

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}
[/QUOTE]
How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

It was traditional for "lint" to use such comments, so I'm not
surprised that a compiler does. Presumably this was one of the
intended uses of pragmas.

-- Richard
 
R

Radamanthe

Harald said:
Radamanthe said:
santosh said:
Harald van Dijk wrote:
santosh wrote:
Ben Bacarisse wrote:

santosh said:

<snip>
Out of curiosity, can you name a compiler that emits this diagnostic?
[for the while(condition); construct]

Not off the top of my head, no.
and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;
The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.
The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.
I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.

For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)
How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.
These are just warnings. Actually, this does not change the generated
code at all. I suppose the compiler decides not to warn when there is a
comment before the following case, because an experienced programmer
using this behavior of switch/case generally puts a comment there, just
to inform that the absence of the break statement is intentional (and
not an obvious bug as it is generally). Exploiting this behaviour is
very uncommon practice, so best to warn the reader.

Anyway, I don't think this is a "so wise" feature of the compiler. Lots
of people may have the habit to put comments above cases, thus
forgetting a break would almost certainly pass silently.

Only comments containing the word FALLTHROUGH or FALLTHRU are supposed
to cause the warning to be skipped, not just any random comment.

Well, ok.. this is not perfect though, and this could not be anyway. I
can't bet it won't ever happen to me to forget a break before a
commented case with "fallth(rough|thru)" inside it :) So it will
certainly happen to some people in this world. Too bad for him(her).
 
K

Keith Thompson

santosh said:
Ben said:
Richard Heathfield said:
santosh said:
<snip>

Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;

Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

The standard doesn't talk about "compilation proper". Comments vanish
in translation phase 3, which is just as much part of "compilation" as
any other phase. A compiler is perfectly free to decide whether or
not to issue an optional diagnostic based on the presence or absence
(or even the contents) of a comment.

But yes, comment deletion is commonly handled in the "preprocessor",
which is often (but not always) a separate program that runs to
completion before the phase that would issue a warning about the
semicolon. And I'd be a bit surprised if a comment really did inhibit
the warning. I find the described behavior counterintuitive. (Some
versions of lint recognize specially formatted comments as
annotations).
 
K

Keith Thompson

CBFalconer said:
santosh wrote: [...]
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

Comments are replaced by a blank.

And thus are not present (assuming a certain intepretation of
"compilation proper").
 
B

Ben Bacarisse

Keith Thompson said:
santosh said:
Ben said:
santosh said:
<snip>

Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;
I find the described behavior counterintuitive. (Some
versions of lint recognize specially formatted comments as
annotations).

It certainly was not lint (or similar). It is possible that this is a
false memory but the code I wrote at about that time (~10 years ago)
has a comment in every empty while.

I have tried to fond some evidence (or even the name of the compiler
concerned) and failed, so this is in danger of becoming no more than a
rumour.
 
J

jaysome

Out of curiosity, can you name a compiler that emits this diagnostic?
I haven't encountered it in gcc, even with the -Wall and -Wextra
switches.

FWIW, PC-lint issues this warning:

Info 722: Suspicious use of ;

Regards
 
S

Simon Biber

Christopher said:
"read"

Literally:

#!/bin/bash
read -p "press enter key when ready"
<whatever else>

Now if it's a modern version of bash and you're commited to being bash
specific:

read -s -n 1 -p "press any key when ready"

Silent echo, 1 char max

If you want to exactly duplicate MS-DOS's pause command:

system("read -s -n 1 -p \"Press any key to continue . . . \"; echo;");

The extra echo command is necessary as pause adds a newline after you
press a key.
 
R

Randy Howard

Well, we can't see your code, so we can't see what you've done
wrong.

But I /guess/ that you did some input earlier and didn't
eat all of it, so your getchar getted a char without you
having to type any more. Solution: don't leave random input
unread. (I have a small bet with my evil twin that it's your
`scanf` that's the root of the problem.)

Made up statistic, but worthy of consideration anyway:

90% of all programs that call scanf() have a bug rooted in the use of
scanf().

:)
 
R

Richard Bos

CBFalconer said:
Try:

while (side_effects) continue;

That's a good one; another I like is putting the semi-colon on a line of
its own. That's unusual enough to be clear. Like this:

while (side_effects--)
;

Richard
 
C

Chris Dollin

CBFalconer said:
Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.
 
K

Keith Thompson

Chris Dollin said:
CBFalconer wrote: [...]
Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

Of course you can change it:

#define endwhile }
#define endif }
....

(But don't expect anyone to read your code if you commit such an
abomination.)
 
R

Richard Bos

Chris Dollin said:
CBFalconer said:
Chris Dollin wrote:

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

Richard
 
D

Default User

Richard said:
That's a good one; another I like is putting the semi-colon on a line
of its own. That's unusual enough to be clear. Like this:

while (side_effects--)
;

The first C coding standard I worked under mandated/suggested that. It
works pretty well, although these days I tend to use empty braces:

while (side_effects--)
{
}



Brian
 
C

Chris Dollin

Richard said:
Chris Dollin said:
CBFalconer said:
Chris Dollin wrote:
Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

I don't. Why would you think I did?

(Yes, I /know/ that the Bourne shell was writting with algolifying
macros. C isn't built that way, and I can't change it, and I
have no interest in trying to fake a better-according-to-me
syntax using macros, for all the reasons behind your and
Keith's expressions of distaste. To get a more pleasing grammar
I go to -- or implement -- other languages.)
 
R

Richard Bos

Chris Dollin said:
Richard said:
Chris Dollin said:
CBFalconer wrote:

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

I don't. Why would you think I did?

If you want the origin for a standard hacker idiom, you know where to
find it.
(Yes, I /know/ that the Bourne shell was writting with algolifying
macros. C isn't built that way, and I can't change it, and I
have no interest in trying to fake a better-according-to-me
syntax using macros, for all the reasons behind your and
Keith's expressions of distaste.

No, you don't, because at least one of the reasons behind my distaste is
that I find the endrepeat grammar _not_ better, but overly voluble and
frequently less legible.

Richard
 
C

Chris Dollin

Richard said:
Chris Dollin said:
Richard said:
CBFalconer wrote:

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

I don't. Why would you think I did?

If you want the origin for a standard hacker idiom, you know where to
find it.

That's not an answer.
No, you don't, because at least one of the reasons behind my distaste is
that I find the endrepeat grammar _not_ better, but overly voluble and
frequently less legible.

Ah. Well, it would have helped if you'd said that. Usually when
I've seem people yuck over the Bourne shell its the algolification-
via-macros that's the issue, not the intended syntax. (I'm curious
whether you've seen a language with the repeat-endrepeat syntax,
since the one I know it from is Pop11.)

Grammatical tastes differ.

Um, this is barely topical: if you're bothered to respond, I'll
take email.
 

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

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top