Hexadecimal Constant Representation

[Blane_J_]

Is there any difference between representations " Z'd[d...]' " and " [s] [[base] #] nnn... " which can be used to represent integer constants ? In my program, the follow two lines generate wired results ( IVF 15.0.1.148 [IA-32] is in use):

! First: This one is all right.
INTEGER(KIND=8), PARAMETER :: MaxValue1 = Z'7FFFFFFFFFFFFFFF'
! Second: This one gives an error message: "error #6384: The INTEGER(KIND=4) value is out-of-range."
INTEGER(KIND=8), PARAMETER :: MaxValue2 = #'7FFFFFFFFFFFFFFF'

I have clearly declared the integers all have KIND=8 kind type, but why the Second is wrong and the error is about INTEGER(KIND=4) ?

[IanH]

Note that neither form is standard conforming.  I wasn't even aware of the existence of the #nnn form (you have inserted additional quotes) until your post.  Presumably that form of literal constant is always taken to be default integer, hence the warning.

The type, kind and value of an initializer (the right hand side of the `=`) is evaluated independently of the thing that it is initializing.

In terms of the standard language, you need to use one of the intrinsic type "constructor" intrinsic functions to give meaning to a BOZ literal constant.  On their own they have no type and kind. 

INTEGER(KIND=8), PARAMETER :: MaxValue3 = INT(Z'7FFFFFFFFFFFFFFF',KIND=8)

As mentioned by RO in a recent thread, someone should sit down with the compiler and have a bit of a frank discussion with it around it accepting the non-standard "bare" BOZ literal syntax without complaint when /stand is specified.

Also worth noting that there's an intrinsic to get the HUGEst positive number that an integer object of certain kind can take,

[Blane_J_]

Thanks lanH, The IVF Compiler Documentation regards  "  [[base] #] nnn... " form an extend representation of integer constant, but not in the F2008 standard documentation within which the " Z'd[d...]' " form is. And, the IVF docs also contain paragraph of "Determining the Data Type of Nondecimal Constants" to explain treatments to these BOZ representations. Then why not treat the two forms equally ?

[Steven_L_Intel1]

The # form is semantically different from the Z'' form in that the # form is explicitly an integer.

I already have a bug report filed about the lack of standards warning for the Z'' form in some contexts where it is nonstandard. It does detect in in others.

[dboggs]

OK, so I'm getting a little confused. I routinely use a statement like

icolor = #70FF00

That is, without any quotes. Is this standard conforming or not? Is it recommended or not? It is very convenient. I'm surprised to even see an alternate form, #'70FF00', that is generating this discussion. Why would one use this?

[Steven_L_Intel1]

Absolutely NOT standard conforming. But use it if you like it. As I mentioned above, this is an integer constant, not typeless the way the Z form is.

By the way, the syntax is not #'70DF00' but  [[base] #] nnn...  No quotes.

[Blane_J_]

If "  [[base] #] nnn... " form of constants are explicitly integer, is it of default kind ? And is there any approach I can use this form to represent INTEGER(KIND /= default_kind) constant ?

[Steven_L_Intel1]

Default integer only. You can't specify a kind.

[Blane_J_]

I've changed the compiler option "Default integer KIND" from 4 to 8 (/integer_size:64) in project Property/Fortran/Data but still the same. So is the default integer kind associate with the system arch (x86 or x86_64) in use(x86_64 is the current configuration) ?

[IanH]

Is there a reason that you aren't using the standard form?

[Blane_J_]

Just technical discussion anyway. In addition compare with OBZ form, the "  [[base] #] nnn... " seems unitive to me .

[Steven_L_Intel1]

Hmm - I thought the # constants were default integer, but maybe they are integer(4) only. I'll ask the developers and get the documentation clarified.

[Steven_L_Intel1 · Accepted solution]

Interesting situation here. On Linux and Mac, the # constants follow the default integer kind, but on Windows they are restricted to INTEGER(4). The reasons for this are lost in antiquity and we can think of no valid reason for the limitation so in the next major release, the # constants will be "default integer" on all platforms.

[Blane_J_]

Thanks Steve, that's a good news, and will that act as BOZ constants and follow the rules written in "Determining the Data Type of Nondecimal Constants" paragraph then?

[Steven_L_Intel1]

Nope. The # constants are not the same as BOZ. # constants are integers, and will always be "default integer". So they will be treated exactly the same as decimal constants such as 12345 without kind specifiers. BOZ constants are typeless and assume type depending on context.

My advice would be to write standard-conforming code and use BOZ constants with intrinsics such as INT or REAL if you need to force a kind or use them in expressions.

[Blane_J_]

That's understandable, thanks Steve.