complex declarations

[Robbie Brown]

That depends upon what you mean by "head of main", and where you
#include the header file:

bar.h:
#ifndef H_BAR
#define H_BAR
int bar(int);
#endif

foo.h:
#ifndef H_FOO
#define H_FOO
void foo();
#endif

main.c:
// Is this what you mean by "head of main"?

Yes, my fault for not being clear.
I think I've probably got this now, interesting point about defining
functions after main(). I can see some sense in that now.

// create a file scope declaration for bar():
#include "bar.h"
int file_scope_declaration(double);

int main()
{
// Or is this what you mean by "head of main"?
// NB: I do NOT recommend block scope function declarations
double block_scope_declaration(int);
// Create block scope declaration for foo()
#include "foo.h"
// Do NOT do this with any standard header - the behavior is
// undefined (7.1.2p4).

Yea, I'd probably run screaming into the night if I came across this.
Never even considered it.



--
Rob - not floundering, fishing
========================================================
For every SCoP we generate the polyhedral representation
and transform it back to gimple.
========================================================
Seems perfectly reasonable to me.

 

[Ben Bacarisse]

There are other questions, like, where's the sanity of declaring a
prototype in block scope when you can't define it in same (this seems
particularly bizarre)

Yes, but it's easy to support and it would seem strange to outlaw it for
no good reason. The prohibition on *defining* function inside others is
due to the fact that it might impose extra costs on the implementation.
I say "might" because I think gcc has found a way to avoid the cost
except when it must be paid, but in the early days of C I suspect the
cost was seen as being inevitable.

<snip>

 

[BartC]

Note to Robbie: Bartc is primarily interested in designing his own
language,

(Not quite true, I've been trying to avoid doing so. However....)

and uses the term "export" to describe a feature of that
language. This term has no well-defined meaning in C. C functions have
external linkage unless declared 'static', in which case they have
internal linkage.

If you define a function F in translation unit A, to be called from
translation unit B, would anyone really be completely flummoxed if I
described F as being exported from A, and imported by B?

And I tend to declare such a function F (even when writing C), with a
'global' prefix (an empty macro) in A, and with an 'extern' prefix in B.

Proper C of course prefers to use no prefix when declaring F when it is
defined in A, and no prefix either when declaring it in B, just to make it
perfectly clear what is what! With un-exported local functions needing a
'static' prefix, obviously.

 

[Keith Thompson]

On 04/03/14 22:04, Keith Thompson wrote: [...]

Use "gcc -std=c99 -pedantic" to make it warn about violations of the C99
standard. gcc is not a conforming C compiler without the "-pedantic"
option. Use "-pedantic-warnings" to turn those warnings into fatal
errors.

OK, well my gcc doesn't support -pedantic-warnings.

I'm pretty sure that was a typo for -pedantic-errors

Yes.