Discussion:
How to apply all defines and get processed source
Add Reply
Test
2017-07-24 19:38:19 UTC
Reply
Permalink
Raw Message
Lets say I have a source file with lots of #defines and #elseif and such.

Is there a tool that would apply all the defines and produce a simplified source
file. I am using GCC if that matter (or has this feature already).

For example if my source is:

#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
{
TYPEDUJOUR pi;
#ifndef PIVALUE
pi=PIVALUE;
#else
pi=3.14;
#endif
SAYIT("%f\n",pi);
}

.. the "simplification" tools would save it to ie. "mysource.clean" with

void main(void)
{
float pi;
pi=3.14159265359;
printf("%f\n",pi);
}


This would really help a lot. Often I'd like to know what HWND and DWORD etc.
realy boils down to.

---
This email has been checked for viruses by AVG.
http://www.avg.com
Patrick.Schluter
2017-07-24 19:51:02 UTC
Reply
Permalink
Raw Message
Post by Test
Lets say I have a source file with lots of #defines and #elseif and such.
.. the "simplification" tools would save it to ie. "mysource.clean" with
void main(void)
{
float pi;
pi=3.14159265359;
printf("%f\n",pi);
}
Add the option -save-temps to your gcc command line. It will leave two
files in the compilation directory, 1 preprocessed file (i.e. what you
asked for) with .i extension and 1 assembly file with .s suffix (if you
want to read the assembly is better to add also option -fverbose-asm so
that it contains the names of your identifiers).
bartc
2017-07-24 19:57:49 UTC
Reply
Permalink
Raw Message
Post by Test
Lets say I have a source file with lots of #defines and #elseif and such.
Is there a tool that would apply all the defines and produce a simplified source
file. I am using GCC if that matter (or has this feature already).
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
{
TYPEDUJOUR pi;
#ifndef PIVALUE
pi=PIVALUE;
#else
pi=3.14;
#endif
SAYIT("%f\n",pi);
}
.. the "simplification" tools would save it to ie. "mysource.clean" with
void main(void)
{
float pi;
pi=3.14159265359;
printf("%f\n",pi);
}
This would really help a lot. Often I'd like to know what HWND and DWORD etc.
realy boils down to.
See if the -E option is any good, which shows preprocessed output. Note
this will also expand all system headers, producing a lot of output; you
might try commenting those out.
--
bartc
Keith Thompson
2017-07-24 20:12:15 UTC
Reply
Permalink
Raw Message
Post by Test
Lets say I have a source file with lots of #defines and #elseif and such.
Is there a tool that would apply all the defines and produce a
simplified source file. I am using GCC if that matter (or has this
feature already).
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
{
TYPEDUJOUR pi;
#ifndef PIVALUE
pi=PIVALUE;
#else
pi=3.14;
#endif
SAYIT("%f\n",pi);
}
.. the "simplification" tools would save it to ie. "mysource.clean" with
void main(void)
{
float pi;
pi=3.14159265359;
printf("%f\n",pi);
}
This would really help a lot. Often I'd like to know what HWND and DWORD etc.
realy boils down to.
gcc has a "-E" option that does this. It prints the preprocessor's
output to stdout. Other compilers are likely to have similar options.

Incidentally, unless you're working with a freestanding
implementation, if you have a book or tutorial that told you
to use "void main(void)", discard it and find a better one.
"int main(void)" is correct. "void main(void)" or "void main()"
is useful mostly as a red flag indicating that an author doesn't
know C very well.

(Yes, I know implementations are permitted to support other
definitions for main.)

See the comp.lang.c FAQ, http://www.c-faq.com/>, questions 11.12a
and following.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
James R. Kuyper
2017-07-24 20:15:08 UTC
Reply
Permalink
Raw Message
Post by Test
Lets say I have a source file with lots of #defines and #elseif and such.
Is there a tool that would apply all the defines and produce a simplified source
file. I am using GCC if that matter (or has this feature already).
One such tool is gcc, and it does have this feature already.
Post by Test
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
{
TYPEDUJOUR pi;
#ifndef PIVALUE
pi=PIVALUE;
#else
pi=3.14;
#endif
SAYIT("%f\n",pi);
}
.. the "simplification" tools would save it to ie. "mysource.clean" with
gcc -your_favorite_options -E filename.c -o mysource.clean
Post by Test
void main(void)
{
float pi;
pi=3.14159265359;
printf("%f\n",pi);
}
This would really help a lot. Often I'd like to know what HWND and DWORD etc.
realy boils down to.
Note, however, that "clean" is generally not a good description of the
output from the -E option. The key issue is the #include directive,
which also gets evaluated. For instance, the printf() call above should
have a matching #include <stdio.h>, probably inside the same header file
that #defined SAYIT as expanding to a printf() call. The result is that
all of the text from the corresponding header file gets included (after
preprocessing) in your -E output file. In the case of <stdio.h>, that's
usually a LOT of text.
The output file will also contain #file directives. Because of those
directives, if you compile the output file, any messages you get that
trace back to one of those header files will be correctly attributed to
that file, despite the fact that the -E output file has no #include
directives.
This is actually pretty useful, if you're trying to figure out which
header file is the source of the object/function/type/typedef
declaration you're looking for. It is NOT as useful for tracking down
where various macros are #defined, because what the standard says about
#define directives means that they disappear at the end of the
pre-processing phase.
Keith Thompson
2017-07-24 21:00:37 UTC
Reply
Permalink
Raw Message
"James R. Kuyper" <***@verizon.net> writes:
[...]
Post by James R. Kuyper
The output file will also contain #file directives. Because of those
directives, if you compile the output file, any messages you get that
trace back to one of those header files will be correctly attributed to
that file, despite the fact that the -E output file has no #include
directives.
I think you mean #line directives.

But in fact "gcc -E"'s output doesn't use #line directives. Instead, it
uses what the standard confusingly calls "non-directives", which contain
similar information.

$ gcc -E hello.c | head
# 1 "hello.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "hello.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 27 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
$

(I don't know what the trailing numbers mean.)
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ben Bacarisse
2017-07-24 20:17:10 UTC
Reply
Permalink
Raw Message
Post by Test
Lets say I have a source file with lots of #defines and #elseif and such.
Is there a tool that would apply all the defines and produce a simplified source
file. I am using GCC if that matter (or has this feature already).
You can use gcc -E, but the result is often less than helpful. Try it
and see if it helps.

<snip>
Post by Test
This would really help a lot. Often I'd like to know what HWND and DWORD etc.
realy boils down to.
You can use gcc -E on very short file that just has the right include
file and the macro in question to find out, but I'd call this a red
flag. There's no problem if this is just curiosity, but any action you
take based on what you find out is almost certainly an error!
--
Ben.
James R. Kuyper
2017-07-24 20:29:10 UTC
Reply
Permalink
Raw Message
...
Post by Ben Bacarisse
Post by Test
This would really help a lot. Often I'd like to know what HWND and DWORD etc.
realy boils down to.
You can use gcc -E on very short file that just has the right include
file and the macro in question to find out, ...
It's been more than three decades since I had any need to know such
things, and I have no access to any system where I could check directly,
but according to msdn.microsoft.com, HWND and DWORD are both typedefs,
not macros.
Richard Heathfield
2017-07-25 03:05:52 UTC
Reply
Permalink
Raw Message
Post by Test
Lets say I have a source file with lots of #defines and #elseif and such.
Is there a tool that would apply all the defines and produce a simplified source
file. I am using GCC if that matter (or has this feature already).
gcc's -E switch gives you pre-processed source.
Post by Test
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
Since, in hosted implementations, a return type of anything other than
int for main() invokes undefined behaviour, all bets are off for your
example.

int main(void) is what you need there.

Anyway, -E is the switch you are seeking.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
Ben Bacarisse
2017-07-25 11:12:38 UTC
Reply
Permalink
Raw Message
<snip>
Post by Richard Heathfield
Post by Test
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
Since, in hosted implementations, a return type of anything other than
int for main() invokes undefined behaviour, [...]
Do you have a citation for that?
Post by Richard Heathfield
int main(void) is what you need there.
Ack. There is certainly no reason not to write int main.
Post by Richard Heathfield
Anyway, -E is the switch you are seeking.
--
Ben.
Richard Heathfield
2017-07-25 11:55:22 UTC
Reply
Permalink
Raw Message
Post by Ben Bacarisse
<snip>
Post by Richard Heathfield
Post by Test
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
Since, in hosted implementations, a return type of anything other than
int for main() invokes undefined behaviour, [...]
Do you have a citation for that?
Oh, dear. I thought I did. I suppose this is one of those myriad little
changes that I've lost track of. Still, let's find out.

I am taking as my text the Committee Draft from 12 April 2011. I suppose
I wouldn't be too surprised to discover that it's out of date, but
that's what I've got.

In 5.1.2.2.1 (Program Startup), Paragraph 1 (which applies to hosted
implementations), we read:

The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined with a
return type of int and with no parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent; 10) or in some other implementation-defined manner.

Now, let's look at that again, but this time eliding some text in an
attempt to clarify the sentence structure:

It shall be defined with a return type of int and with no parameters: or
with two parameters (referred to here as argc and argv, though any names
may be used, as they are local to the function in which they are
declared): or equivalent; or in some other implementation-defined manner.

Now, we definitely have a "shall" outside of a constraint. Can we agree
that, if this "shall" is violated, the behaviour is undefined? If not,
here is your chance to disagree with me:

____________

Okay, if we agree, we can move on. We can read the sentence in either of
two ways:

It shall be defined with a return type of int AND [0 parms OR 2 parms OR
equivalent OR in some other implementation-defined manner]

It shall be defined [with a return type of int AND 0 parms OR 2 parms OR
equivalent] OR in some other implementation-defined manner

If the first is the correct reading, then I would suggest that this is
the citation for which you have asked.

If the second is the correct reading, then the behaviour is
implementation-defined IF gcc (in this case, since that's what the OP is
using) defines it.

But /does/ gcc define it? There is no mention of main(), as far as I can
tell, within the "implementation-defined behaviour" bit of the gcc
documentation for C. In the more general documentation we find:

[...] startup is through a function int main (void) or int main (int,
char *[]).

See https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Standards.html#C-Language

These are the only mentions of main() on that page, and there is no
definition of the behaviour for void main.

So, either way, I must stand by my earlier statement until such time as
someone shows it to be in error.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
Ben Bacarisse
2017-07-25 13:51:38 UTC
Reply
Permalink
Raw Message
Post by Richard Heathfield
Post by Ben Bacarisse
<snip>
Post by Richard Heathfield
Post by Test
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
Since, in hosted implementations, a return type of anything other than
int for main() invokes undefined behaviour, [...]
Do you have a citation for that?
Oh, dear. I thought I did. I suppose this is one of those myriad
little changes that I've lost track of. Still, let's find out.
<snip>
Post by Richard Heathfield
In 5.1.2.2.1 (Program Startup), Paragraph 1 (which applies to hosted
The function called at program startup is named main. The
implementation declares no prototype for this function. It shall be
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared): int main(int argc, char *argv[]) { /* ... */ } or
equivalent; 10) or in some other implementation-defined manner.
<snip>
Post by Richard Heathfield
Now, we definitely have a "shall" outside of a constraint. Can we
agree that, if this "shall" is violated, the behaviour is undefined?
Of course.
Post by Richard Heathfield
It shall be defined with a return type of int AND [0 parms OR 2 parms
OR equivalent OR in some other implementation-defined manner]
It shall be defined [with a return type of int AND 0 parms OR 2 parms
OR equivalent] OR in some other implementation-defined manner
If the first is the correct reading, then I would suggest that this is
the citation for which you have asked.
It can't be the first. Just look at the semicolons in the original text
that you omitted in your paraphrase. English uses semicolons rather
than [...] for exactly this purpose.
Post by Richard Heathfield
If the second is the correct reading, then the behaviour is
implementation-defined IF gcc (in this case, since that's what the OP
is using) defines it.
Right. But I thought "Since, in hosted implementations, a return type
of anything other than int for main() invokes undefined behaviour" was
literally what you meant. "In hosted implementations" does sound very
general, doesn't it? Writing "in gcc's implementation" or "in your
particular implementation" would have made that clear.
Post by Richard Heathfield
But /does/ gcc define it?
It's not easy to tell because gcc is not a monolithic entity. You would
need to review the documentation of all versions and all ports of gcc to
make a remark about gcc in general.

Side note: what happens if I edit the local copy of gcc's documentation
and patch the version number in the binary -- does *my* gcc now define
it?

<snip>
Post by Richard Heathfield
So, either way, I must stand by my earlier statement until such time
as someone shows it to be in error.
And what you meant is entirely correct, but I must stand by my reading
of what implementations a remark about "hosted implementations" appears
to cover.
--
Ben.
Richard Heathfield
2017-07-25 14:32:14 UTC
Reply
Permalink
Raw Message
Post by Ben Bacarisse
Post by Richard Heathfield
Post by Ben Bacarisse
<snip>
Post by Richard Heathfield
Post by Test
#include <somedefslikeSAYITinhere.h>
#define PIVALUE 3.14159265359
void main(void)
Since, in hosted implementations, a return type of anything other than
int for main() invokes undefined behaviour, [...]
Do you have a citation for that?
Oh, dear. I thought I did. I suppose this is one of those myriad
little changes that I've lost track of. Still, let's find out.
<snip>
Post by Richard Heathfield
In 5.1.2.2.1 (Program Startup), Paragraph 1 (which applies to hosted
The function called at program startup is named main. The
implementation declares no prototype for this function. It shall be
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared): int main(int argc, char *argv[]) { /* ... */ } or
equivalent; 10) or in some other implementation-defined manner.
<snip>
Post by Richard Heathfield
Now, we definitely have a "shall" outside of a constraint. Can we
agree that, if this "shall" is violated, the behaviour is undefined?
Of course.
Post by Richard Heathfield
It shall be defined with a return type of int AND [0 parms OR 2 parms
OR equivalent OR in some other implementation-defined manner]
It shall be defined [with a return type of int AND 0 parms OR 2 parms
OR equivalent] OR in some other implementation-defined manner
If the first is the correct reading, then I would suggest that this is
the citation for which you have asked.
It can't be the first. Just look at the semicolons in the original text
that you omitted in your paraphrase. English uses semicolons rather
than [...] for exactly this purpose.
I omitted only one semicolon, and putting it back in doesn't help. To
demonstrate this, I will put it back, and I will also put back the
punctuation that I /think/ you meant when you used the plural for
"semicolons", although in fact these were colons:

It shall be defined with a return type of int and with no parameters:
[example code]
or with two parameters [parenthetical comment]:
[example code]
or equivalent; or in some other implementation-defined manner.

The problem here is that the 'operands' (if I may use the term) of the
single semicolon (and its bedfellow "or") are ambiguous. On reflection,
I think your reading is stronger; but on the other hand I remember once
holding that view myself and being dissuaded from it by people who know
C much better than I do!

It is certainly the case that int is the *only* return type for main
that is quite definitely defined for *all* (hosted) implementations and
is therefore the obvious safe option, but I am once again ambivalent
about the precise meaning of this paragraph. So you may well be right,
Ben, but it isn't a step forward for those seeking to write correct
code. As Douglas Adams once wrote: "We demand rigidly defined areas of
doubt and uncertainty!"
Post by Ben Bacarisse
Post by Richard Heathfield
If the second is the correct reading, then the behaviour is
implementation-defined IF gcc (in this case, since that's what the OP
is using) defines it.
Right. But I thought "Since, in hosted implementations, a return type
of anything other than int for main() invokes undefined behaviour" was
literally what you meant.
It *was* literally what I meant, until you chased me. :-)

<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
Keith Thompson
2017-07-25 16:28:28 UTC
Reply
Permalink
Raw Message
Richard Heathfield <***@cpax.org.uk> writes:
[...]
Post by Richard Heathfield
In 5.1.2.2.1 (Program Startup), Paragraph 1 (which applies to hosted
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined with a
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
int main(int argc, char *argv[]) { /* ... */ }
or equivalent; 10) or in some other implementation-defined manner.
[...]
Post by Richard Heathfield
Okay, if we agree, we can move on. We can read the sentence in either of
It shall be defined with a return type of int AND [0 parms OR 2 parms OR
equivalent OR in some other implementation-defined manner]
It shall be defined [with a return type of int AND 0 parms OR 2 parms OR
equivalent] OR in some other implementation-defined manner
If the first is the correct reading, then I would suggest that this is
the citation for which you have asked.
Your first reading is inconsistent with other wording in the standard.
In particular, N1570 5.1.2.2.3p1 says:

If the return type of the main function is a type compatible with
int, [...]

That wouldn't make any sense unless it's possible for the return type to
be incompatible with int.

This program:

void main(void){}

has undefined behavior under a hosted implementation that doesn't
document "void main(void) { /* ... */ }" as a permitted definition
for main, and implementation-defined behavior (not undefined
behavior) under an implementation that does. (I think, for example,
that Microsoft's C compiler does document that form.)

Hosted implementations may support void main(void). There is no
good reason to take advantage of that support.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Kenny McCormack
2017-07-25 16:40:10 UTC
Reply
Permalink
Raw Message
In article <***@kst-u.example.com>,
Keith Thompson <kst-***@mib.org> wrote:
...
(Subject: Re: How to apply all defines and get processed source)
...
void main(void){}
has undefined blah, blah, blah...
Reading this thread...

Words just fail me...
--
"Only a genius could lose a billion dollars running a casino."
"You know what they say: the house always loses."
"When life gives you lemons, don't pay taxes."
"Grab 'em by the p***y!"
s***@casperkitty.com
2017-07-25 17:18:12 UTC
Reply
Permalink
Raw Message
Post by Keith Thompson
void main(void){}
has undefined behavior under a hosted implementation that doesn't
document "void main(void) { /* ... */ }" as a permitted definition
for main, and implementation-defined behavior (not undefined
behavior) under an implementation that does. (I think, for example,
that Microsoft's C compiler does document that form.)
Any behavior which is documented by an implementation and not defined by the
Standard would, tautologically, be defined on that implementation rather
than undefined. From the Standard's point of view, however, the distinction
between Implementation-Defined Behavior and Undefined Behavior is that
documentation of the former is *required for conformance*. Documentation of
the latter may be necessary to make an implementation suitable for various
purposes, but the Standard makes no attempt to address such quality-of-
implementation issues.
Richard Heathfield
2017-07-25 18:09:26 UTC
Reply
Permalink
Raw Message
Post by Keith Thompson
[...]
Post by Richard Heathfield
In 5.1.2.2.1 (Program Startup), Paragraph 1 (which applies to hosted
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined with a
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
int main(int argc, char *argv[]) { /* ... */ }
or equivalent; 10) or in some other implementation-defined manner.
[...]
Post by Richard Heathfield
Okay, if we agree, we can move on. We can read the sentence in either of
It shall be defined with a return type of int AND [0 parms OR 2 parms OR
equivalent OR in some other implementation-defined manner]
It shall be defined [with a return type of int AND 0 parms OR 2 parms OR
equivalent] OR in some other implementation-defined manner
If the first is the correct reading, then I would suggest that this is
the citation for which you have asked.
Your first reading is inconsistent with other wording in the standard.
Perhaps you're right (and in fact on past form I'd trust your
interpretation more than I'd trust mine), but you're going to have to
show me. Your example (see below) doesn't count because it's irrelevant
to the case in hand (see below below!).
Post by Keith Thompson
If the return type of the main function is a type compatible with
int, [...]
That wouldn't make any sense unless it's possible for the return type to
be incompatible with int.
But that section applies both to hosted *and* to freestanding
implementations. The Standard has nothing specific to say about the
definition of main for freestanding implementations, and it is entirely
possible for main's return type to be incompatible with int in
circumstances that don't apply in 5.1.2.2.1(1) - to wit, within
freestanding implementations.

<snip>
Post by Keith Thompson
Hosted implementations may support void main(void).
Implementations may support any extension they like as long as it
doesn't break strictly conforming code. So what?
Post by Keith Thompson
There is no
good reason to take advantage of that support.
On that, at least, we can agree.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
Keith Thompson
2017-07-25 19:16:28 UTC
Reply
Permalink
Raw Message
Post by Richard Heathfield
Post by Keith Thompson
[...]
Post by Richard Heathfield
In 5.1.2.2.1 (Program Startup), Paragraph 1 (which applies to hosted
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined with a
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
int main(int argc, char *argv[]) { /* ... */ }
or equivalent; 10) or in some other implementation-defined manner.
[...]
Post by Richard Heathfield
Okay, if we agree, we can move on. We can read the sentence in either of
It shall be defined with a return type of int AND [0 parms OR 2 parms OR
equivalent OR in some other implementation-defined manner]
It shall be defined [with a return type of int AND 0 parms OR 2 parms OR
equivalent] OR in some other implementation-defined manner
If the first is the correct reading, then I would suggest that this is
the citation for which you have asked.
Your first reading is inconsistent with other wording in the standard.
Perhaps you're right (and in fact on past form I'd trust your
interpretation more than I'd trust mine), but you're going to have to
show me. Your example (see below) doesn't count because it's irrelevant
to the case in hand (see below below!).
Post by Keith Thompson
If the return type of the main function is a type compatible with
int, [...]
That wouldn't make any sense unless it's possible for the return type to
be incompatible with int.
But that section applies both to hosted *and* to freestanding
implementations. The Standard has nothing specific to say about the
definition of main for freestanding implementations, and it is entirely
possible for main's return type to be incompatible with int in
circumstances that don't apply in 5.1.2.2.1(1) - to wit, within
freestanding implementations.
No, that section applies only to hosted implementations.

5.1.2 Execution environments
5.1.2.1 Freestanding environment (covers startup and
termination, and doesn't say much about either)
5.1.2.2 Hosted environment
5.1.2.2.1 Program startup
5.1.2.2.2 Program execution
5.1.2.2.3 Program termination
5.1.2.3 Program execution

Note in particular that it says that a return from main is equivalent to
a call to the exit function. That function needn't exist in a
freestanding implementation (the list of required headers in 4p6 does
not include <stdlib.h>).
Post by Richard Heathfield
<snip>
Post by Keith Thompson
Hosted implementations may support void main(void).
Implementations may support any extension they like as long as it
doesn't break strictly conforming code. So what?
Yes, and 4p6's permission to provide extensions probably makes the
special "or in some other implementation-defined manner" wording
in 5.1.2.2.1 superfluous. Perhaps the latter was included to
acknowledge common practice, and to encourate implementers to
document other forms for main.
Post by Richard Heathfield
Post by Keith Thompson
There is no
good reason to take advantage of that support.
On that, at least, we can agree.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Heathfield
2017-07-25 19:30:32 UTC
Reply
Permalink
Raw Message
<snip>
Post by Keith Thompson
Post by Richard Heathfield
Post by Keith Thompson
If the return type of the main function is a type compatible with
int, [...]
That wouldn't make any sense unless it's possible for the return type to
be incompatible with int.
But that section applies both to hosted *and* to freestanding
implementations. The Standard has nothing specific to say about the
definition of main for freestanding implementations, and it is entirely
possible for main's return type to be incompatible with int in
circumstances that don't apply in 5.1.2.2.1(1) - to wit, within
freestanding implementations.
No, that section applies only to hosted implementations.
So it does. I overlooked that (by looking too closely at the leaf and
not taking a step back to check out the twig). Your point therefore
carries more weight than I had ascribed to it. My apologies.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
Loading...