From: robert.corbett on
On Mar 31, 9:08 am, Jim Xia <jim...(a)hotmail.com> wrote:
> > I would be very interested in knowing if there is a Fortran
> > implementation that does not provide the function LOC. LOC
> > is so commonly used, I would think an implementation that
> > did not provide it would not be viable.
>
> > Bob Corbett
>
> Your example (with LOC) doesn't compile with XLF. Just let you know
> there are compilers think differently from yours :-)
>
> Cheers,
>
> Jim


Do you mean it does not compile or that it does not link?

Bob Corbett
From: David Thompson on
On Thu, 25 Mar 2010 23:12:18 +0000 (UTC), glen herrmannsfeldt
<gah(a)ugcs.caltech.edu> wrote:

> Richard Maine <nospam(a)see.signature> wrote:

> C only allows subtraction of pointers to different parts of the
> same object, such as different elements of an array. That removes

To be exact, the C standard only requires pointer subtraction within
an array, but any (single) object (such as a struct) can be treated as
an array of characters, and thus pointers within that object cast to
character pointers subtracted. The standard leaves subtraction of
pointers to/into different objects undefined: it does not require a
diagnostic, the implementation can do what it chooses, and on current
machines where subtraction of the machine addresses works fine that's
what a sane C implementor does.

> some of the cases where this can fail. C also allows different
> representation for pointers to different types. If I understand
> it right, Fortran doesn't allow for that one. For example,

Well, *Fortran* POINTERs can certainly be type-dependent; they pretty
much have to be at least rank-dependent. You presumably mean Fortran
C_PTR's, which do further constrain the C implementation to use
homogenous pointers (note 15.10 in the draft I have to hand).

> character pointers on word addressed machines might use other
> bits to indicate the position in a word. I believe that C also
> doesn't guarantee that there is such an integer type, but only says
> what happens if there is such a type. It could be especially

Namely the intptr_t and uintptr_t types, which if they exist must be
capable of losslessly preserving all data pointer values. Correct.

> interesting in the case of 32 bit far model IA32 code, where
> pointers are 48 bits. (16 bit segment selector, 32 bit offset.)

> If there is no corresponding C type, then asking for the C sizeof
> something doesn't make so much sense. There are some C cases
> that I wonder about. In C, character constants, such as 'x', have
> type int, and so sizeof('x')==sizeof(int). (As I understand it,
> that isn't true in C++.) Enumeration constants also have sizeof(int),
> though the appropriate variable can have a different size. C doesn't

More exactly, in C both characters 'x' and enum constants have the
specific type int, just like 123; in C++ they have type char or enum
type respectively. sizeof(char) is always 1 and *typically* less than
sizeof(int), but there are systems with sizeof(int)=1=sizeof(char).
sizeof(enum x) is *typically* the same as sizeof(int) but it may be
different at the compiler's choice; except in C++ which allows enum
constants to be outside (range of) int but within long in which case
*that* enum type (at least) must be wider than int.

> allow pointers to constants, which avoids some problems that would
> otherwise appear in those two cases.
>
C99 adds compound literals, which are intended mainly for aggregates
(arrays and structs) but can be used degenerately for e.g. simple
number as well. But a compound literal explicitly creates an object,
initialized by the constant(s) (or if nonstatic in a function,
optionally nonconstant(s)), which can be pointed to.

Similarly C string constants like "this" have since always actually
meant an array of char *object* initialized to the string's value,
which like any array in C is actually passed and used as a pointer.