external variables

[Spiros Bousbouras]

er, why is it always of type char* why does the unadorned
0 have thype char*. This is a genuine confusion I'm having!

For similar questions look at
< http://groups.google.co.uk/group/comp.lang.c/browse_thread/thread/06b173be34b9c68a#

 

[Larry Gates]

no. The preprocessor has nothing to do with definitions, tentative or
otherwise. The preprocessor is strictly a textual substitution phase
and has no understanding of C syntax or semantics.

I see your point.

the C preprocessor
even gets used on Fortarn programs (I believe).

I'd hate to tell you wrong. That statement's not far from true. I'll ask
Richard Maine.

 

[Guest]

Boon wrote: [...]
AFAICT, (sizeof *(one ? 0 : (char *)0)) is always 1
(Because the above ?: expression has type char *)
Yes.

er, why is it always of type char* why does the unadorned
0 have thype char*. This is a genuine confusion I'm having!

It depends on the null pointer constant.  The fact that an expression
is a null pointer constant doesn't affect its type.  For example, 0,
0ULL, and (void*)0 are all null pointer constants; their types are
int, unsigned long long, and void*, respectively.  (A null pointer
constant may be converted to some pointer type, but the expression
itself has whatever type it would have if it weren't a null pointer
constant.)

ah! I wasn't aware that this was a special case. Thanks!

<snip>

 

[Larry Gates]

No.

Does the intent change without it?
--
larry gates

And don't tell me there isn't one bit of difference between null and space,
because that's exactly how much difference there is.
-- Larry Wall in <[email protected]>

 

[Larry Gates]

That's not what I meant.

/* BEGIN new.c */

#include <stdio.h>

int one = 1;

int main(void)
{
extern int one;

if (one == sizeof *(one ? 0 : (char *)0)) {
puts("0 is a null pointer constant.");
}
return 0;
}

/* END new.c */

K&R2 §A10.2 :

An external object declaration that does not have an initializer, and does
not contain the extern specifier, is a tentative definition.
--
larry gates

OOPS! You naughty creature! You didn't run Configure with sh!
I will attempt to remedy the situation by running sh for you...
-- Larry Wall in Configure from the perl distribution

 

[Larry Gates]

the C preprocessor
even gets used on [Fortran] programs (I believe).

The g95 compiler uses the C preprocessor when the filetype is .F90 (fortran
is usually case insensitive):

C:\MinGW\source>g95 jugo4.F90 -Wall -o p.exe
jugo4.F90:11:31: warning: no newline at end of file

C:\MinGW\source>p
hi there!

C:\MinGW\source>g95 jugo5.F90 -Wall -o p.exe
jugo5.F90:11:31: warning: no newline at end of file

C:\MinGW\source>g95 jugo5.F90 -Wall -o q.exe

C:\MinGW\source>q
x= 3.0000000
y= 1.7320508

C:\MinGW\source>type jugo4.F90
#define O (
#define C )
#define Q '

100 FORMAT O Q hi there!' C
WRITE O *,100 C
STOP
END
! g95 jugo4.F90 -Wall -o p.exe
C:\MinGW\source>type jugo5.F90
#define Q(x) WRITE(*,"('x=',1pg20.8)") x
real x,y
x=3
y=sqrt(x)
Q(x)
Q(y)
STOP
END
! g95 jugo5.F90 -Wall -o q.exe

C:\MinGW\source>

 

[Larry Gates]

the C files (plus their includes). p82 shows all the files.
main.c, getop.c, stack.c and getch.c all correspond to translation
units.
The include file calc.h does not.

gotcha. Is that because there's nothing left of it after preprocessing?
--
larry gates

I'm sure a mathematician would claim that 0 and 1 are both very
interesting numbers.
-- Larry Wall in <[email protected]>

 

[Larry Gates]

wan't he asking because he wanted to know?

I was eighty percent correct. If that gets me out of the classroom and
onto the gold course, then that's good enough.

 

[Larry Gates]

Let me explain my counter example to that:

For the sake of proof, I think you need to stipulate:

int one = 1;
is a declaration of an external variable outside of any function.

Let
int one = 1;
be a declaration of an external variable outside of any function.

extern int one;
is a delcaration of the same variable, inside of main.

Let
extern int one = 1;
be a declaration of the same variable, inside of main.

It is not an external declaration,
but it is a declaration of an external variable
and it is inside a function.

Then, because main is a function it is a declaration of an external
variable and it is inside a function.

 

[Richard Bos]

What I meant was hash, something you and your countrymen know better than
we here as Texas' neighbor.

I doubt that - I know it mostly as something Mokumers sell to stupid
tourists.

#ifdef

#elseif

My question is wouldn't you normally do tentative definitions with #define
and #undefine and their cohort?

Much as one would build a fence using bricks and mortar: they serve
related functions, but certainly not the same one.

Wie es die andere Frage angeht, meine Liebliengschockolade kommt aus dem
Ort, wo ich sie mir hole. Zu Chicago hatten wir sehr tolle Polnische.
Vor ein paar Monaten hatten wir ein russisches Laden, wo ich ganz leckere
Schockoladen erfahren habe. Der ist leide pleitte geworden, wie so viele
andere waehrend der Bush Jahren. Nun ist mein Lieblings Lindt, bei
Smith's.

Well, that does explain the drain bamage.

Richard

 

[David Thompson]

On Mon, 16 Feb 2009 00:37:25 -0800 (PST),

the processor doesn't see these. it likley compiles to some
sort of assembler or loader directive.

He might not mean the machine processor aka CPU.
The Fortran standard uses 'processor' with effectively the same
meaning the C standard uses 'implementation'. Things that are allowed
by the standard to vary (like charset/code, numeric type
representations, etc.) are stated as 'processor-dependent'.
Right. Or to be precise, on all conforming C implementations, there
must be a single variable=object allocated and set to 1 before main()
starts; on most implementations that is done by program loading.
(Unless it is optimized away, since in the full example upthread, the
implementation=compiler can see that main() calls nothing that could
change the value of one, and thus can just constant-fold it.)

this has nothing to do with the preprocessor.

That's true. Even in Fortran.

you'll have to explain what "coco" is. Some Fortran thingy?

Yes. The Fortran standard has its own, optional, analogue of C
preprocessing, which it calls conditional compilation, and there is a
canonical libre implementation called COCO.

In practice however, Fortran 'processors', and programmers, commonly
use a C preprocessor* since C implementations are so ubiquitous.
(* Even in C implementations that don't have a separate preprocessor
there may be a way to preprocess-only-don't-compile which is
effectively the same thing.