Is it standard and practical to use long long types?

[Chris Torek]

If you aim for C99 compliance you *must not* issue a warning about not
returning a value from main().

This is quite wrong.

Compilers are free to emit completely bogus warnings at any time.
For instance, given a program like:

int main(void) { return 0; }

the C standards allow the following:

% strangecc prog.c
prog.c, line 3: warning: there is no line 3
prog.c: warning: this program has no errors
prog.c: warning: your shoe laces are untied
prog.c: warning: these warnings are annoying
%

The *only* thing the C standard requires, in terms of diagnostics,
is that a translation unit that violates a "shall" in a "constraints"
section produce "at least one diagnostic".

Whether a warning constitutes such a "diagnostic" is something you
-- the compiler writer -- can put in your implementation document.
You might also note that you emit non-required warnings, how to
enable additional warnings, and so on.

To be successfully adopted, a compiler-writer should strive to
produce *useful* warnings, rather than the deliberately annoying
ones above. But the C standard makes no such requirements.

 

[Keith Thompson]

Jacob, if you're going to post a followup on the newsgroup, please
don't send it to me by e-mail as well. If you must send me a copy by
e-mail, please say so in the message so I don't waste my time replying
twice. (I saw your e-mail before the same message showed up the
newsgroup.)

For the benefit of others, here's my reply again.

]

The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway

Depending on how the warning is phrased, the user is probably wrong.
Nothing in the standard forbids issuing whatever warnings you like.
If you're going to be flamed anyway, you might as well do what you like.

How can I issue a warning about something that is
*explicitely* allowed?

Um, by issuing a warning about something that is explicitly allowed.
(Presumably a diagnostic about something that's not allowed would be an
error message, not a warning.)

I thought about that but it looks
weird isn't it? If the standard explicitely allows this
stuff a warning is misplaced. A better way would be
to change the standard, what looks like a minor change to
C99.

The change in C99 was deliberate. A lot of us agree that it was a bad
idea, but it wasn't an accidental bug. Now that it's in the standard,
changing it would break existing valid code, so that's just not going
to happen.

Most compilers distinguish between error messages (which cause the
compilation to fail) and warnings (which don't). Some provide more
levels of diagnostics, such as informational messages. Most compilers
that provide more than one level of diagnostic provide options to
disable the lower levels (disable warnings, or show warnings but disable
informational messages). Some, including gcc, provide some options that
disable certain specific warnings.

You should almost certainly issue a warning if control can reach the
end of a non-void function other than main(), even though this isn't
strictly an error. It causes undefined behavior only if the caller uses
the result, and there's no requirement to warn about undefined behavior,
but it's almost certainly something that the programmer should fix.
If you want to warn about reaching the end of main(), I suggest using
a different message, acknowledging that it's well-defined in C99 but
invalid in C90.

There are a number of things you can do. You can issue a warning message
for a program that falls off the end of main(). You can issue something
weaker than a warning, perhaps an informational or style message.
You can provide, or not provide, an option to disable the diagnostic,
either individually or in combination with other diagnostics. You can
allow the user to control the option by means of a formatted comment
in the source, similar to what lint does, or in a config file in the
user's home directory. If you provide such an option, you can either
enable or disable the diagnostic by default.

If you want to follow the spirit of C99, it's clear that falling off
the end of main() is intended by the standard to be perfectly valid;
this argues for disabling the diagnostic by default, but it's entirely
up to you.

The only things you *can't* do are:

1. In C99 mode, reject an otherwise correct program that falls off
the end of main() (issuing a diagnostic is permitted).

2. Claim that the C99 standard doesn't allow you to issue the diagnostic
(it clearly does).

You *can* worry as much as you like about being flamed for whichever
decision you make, but I don't recommend it.

 

[Ioannis Vranos]

This is quite wrong.

Compilers are free to emit completely bogus warnings at any time.

c.l.c. will make me insane.

In any case, bogus warnings must not exist in a decent compiler, so my
suggestion still applies.






Ioannis Vranos

 

[Keith Thompson]

c.l.c. will make me insane.

In any case, bogus warnings must not exist in a decent compiler, so my
suggestion still applies.

The C standard doesn't distinguish between error messages and
warnings. In typical compilers, error messages are issued for syntax
errors and constraint violations, and usually result in the source
program being rejected. Warnings are issued for things that aren't
actually errors, and rarely correspond to diagnostics required by the
standard. (That's for compilers operating in a standard-compliant
mode; in non-compliant mode, it's not uncommon for compilers to issue
mere warnings for some constraint violations.) In the strictest
sense, all warnings are bogus.

Given that the C99 standard explicitly allows control to fall off the
end of main(), and defines the semantics of doing so, it does seem a
little odd for a C99-compliant compiler to warn about it. On the
other hand, omitting the return or exit() is bad style (in my
opinion), and it's invalid in C90.

If it were my compiler, I'd certainly issue a warning, or at least an
informational message, for falling off the end of any non-void
function, but I'd phrase the warning differently for the special case
of main(). I think the change in C99 was a bad idea, though I
understand that it can't now be changed back without breaking existing
code. I'd probably inhibit the warning by default in strict
C99-conforming mode, enable it by default otherwise, and provide some
kind of user option to control it.

 

[Ioannis Vranos]

Given that the C99 standard explicitly allows control to fall off the
end of main(), and defines the semantics of doing so, it does seem a
little odd for a C99-compliant compiler to warn about it. On the
other hand, omitting the return or exit() is bad style (in my
opinion), and it's invalid in C90.

If it were my compiler, I'd certainly issue a warning, or at least an
informational message, for falling off the end of any non-void
function, but I'd phrase the warning differently for the special case
of main().

For standard compliant code there should be no warning, as it is the case
for all C compilers i know (and C++98 compilers i know since main() is the
same there too).

I think the change in C99 was a bad idea,

I think it was ok but i believe the explicit int return type declaration of
main() should not be enforced, that is things tobecome as they were used in
K&R 2.






Ioannis Vranos

 

[Keith Thompson]

For standard compliant code there should be no warning, as it is the case
for all C compilers i know (and C++98 compilers i know since main() is the
same there too).

You snipped the part where I said the warning should probably be
inhibited by default in C99 compliant mode. In any case, it's up to
the implementor to decide what to do about this; the standard is
silent.

I think it was ok but i believe the explicit int return type declaration of
main() should not be enforced, that is things tobecome as they were used in
K&R 2.

Ok, so we disagree.

 

[Dan Pop]

----- Original Message -----
From: "Keith Thompson" <[email protected]>
Newsgroups: comp.lang.c
Sent: Saturday, April 17, 2004 1:59 AM
Subject: Re: Is it standard and practical to use long long types?

I've removed comp.lang.c++ from the newsgroups header.

From: "Dan Pop" <[email protected]> [...]
Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?

Wait Dan, I saw that sentence in the standard, and I wrote
in this group that you were right.

But I have to follow the standard.

But the standard doesn't say you can't issue a warning.

The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway

So, you should have worded it differently, so that it doesn't contradict
the standard. Something like gcc's:

warning: control reaches end of non-void function

is certainly not contradicting *any* C standard.

How can I issue a warning about something that is
*explicitely* allowed?

That's the very point about warnings. If it weren't allowed, they would
be errors and not warnings. ALL warnings *should* be about things that
are allowed, but probably not a good idea, for one reason or another.

Again, an example from gcc:

fangorn:~/tmp 477> cat test.c
int main()
{
unsigned char c = 0;
if (c < 0) ;
return 0;
}
fangorn:~/tmp 478> gcc test.c
test.c: In function `main':
test.c:4: warning: comparison is always false due to limited range of data type

My program is as strictly conforming as you can get, yet gcc emits a
warning that proved to be extremely useful when porting real world
programs.

It is most unfortunate that many compilers emit diagnostics *required* by
the standard as warnings, simply because the compiler can proceed
processing the input file(s), despite the incorrect code. The most
frequent example is:

int foo;
char *p = &foo;

It is trivial to provide the missing cast, but, by using a warning, the
unsuspecting programmer may decide that the code is correct and the
compiler writer is excessively picky.

I thought about that but it looks
weird isn't it? If the standard explicitely allows this
stuff a warning is misplaced.

The standard explicitly allows

int main() { return 0; }

yet you have no qualms issuing no less than *three* diagnostics for this
correct program. Misplaced warnings, heh?!?

A better way would be
to change the standard, what looks like a minor change to C99.

It won't (realistically) happen, as this is a new C99 feature. The best
way of expressing your disapproval is by producing the warning shown
above (BTW, the standard allows *any* function defined as returning
something not to return anything).

And I have already asked you NOT to send me copies of your replies by
private email, unless you want to move the discussion to private email.
Yet, you keep ignoring this request... Is common netiquette a concept
beyong your grasp?

Dan