L (l) suffix Bug, not always "Long", WIN-FBC64

[MrSwiss]

The following test reveals:
negative values result in: INTEGER, instead of LONG, even if l suffix is used,
after the litteral number:

Code: Select all

' Problem with FBC 64 (WIN Standalone): l suffix, doesn't
' guarantee a LONG, in all circumstances!

#Print TypeOf(1234567890l)  ' correct: LONG
#Print TypeOf(-123456789l)  ' problem: INTEGER

Print SizeOf(1234567890l)   ' correct: LONG (4 byte)
Print SizeOf(-123456789l)   ' problem: INTEGER (8 byte)

Sleep

[adele]

Hi,

as you know, we got a Wiki and/or a help file.

Code: Select all

SizeOf ( variable | DataType )
Returns the size of a variable or type in bytes.


A literal expression like (-123456789L) per definitione is not a variable and not a type either, and SizeOf isn´t suspected to guess your hidden thoughts:)
Adi

[MrSwiss]

@adele,

as you know, we got a Wiki and/or a help file.

I know, but you are looking at the wrong page ...
Check suffix and, what is expected by their use!

Integer literals ending with:

"%", are considered as signed 32/64 (depending on platform) bit integers. (Integer)
"L", "&", are considered as signed 32 bit long integers. (Long)
"U", are considered as unsigned 32/64 (depending on platform) bit integers. (UInteger)
"UL", are considered as unsigned 32 bit integers. (ULong)
"LL", are considered as signed 64 bit integers. (LongInt)
"ULL", are considered as unsigned 64 bit integers. (ULongInt)

Secondly, SizeOf() is only for confirmation, TypeOf() returns the Type,
on the CLI (at compile time).
Thirdly, I've written clearly *litteral* (not variable), on purpose.

[fxm]

This behavior occurs for any negative numeric literal.
It's like a negative numeric literal is not a pure numeric literal but rather an expression like a (positive) numeric literal multiplied by -1.

Code: Select all

#print typeof(1L)
#print typeof(1 * 1L)
#print typeof(1L * 1L)


LONG
INTEGER
INTEGER

[MrSwiss]

This behavior occurs for any negative numeric literal.

Whatever the explanation may be, I'll take it as a confirmation of the BUG.

I'll file a bug-report, on Source Forge in 24h ...

[cbruce]

MrSwiss, maybe along the line of fxm's response...

==========================================================================
---------- [page]
integer literal - cppreference.com
http://en.cppreference.com/w/cpp/langua ... er_literal

---------- [selection]
There are no negative integer literals. Expressions such as -1 apply the unary minus operator to the value represented by the literal, which may involve implicit type conversions.
==========================================================================

[MrSwiss]

There are no negative integer literals.

This is correct for C/C++. But, do we really have to do, the same *nonsense* in FB?
IMHO, implicit behaviour, should always be *explicitly* changeable.
Here: with the suffixed (explicit) *type definition*, of the literal.

My case, which led to *discovery* of the *type conversion* was:

- wanting to code a *universal* data-type, with overloaded initializers (no OOP!)
- OK, with the following types:

• Boolean (funny, accepts the -1, aka: TRUE), assignes 1 byte only!
• [U]Integer (ptr size, of compiler, '%' with negative values: no problem!)
• [U]LongInt ('ll' with negative values: no problem!)
• Single / Double (using 'f' or 'd', after literal)
• String (behind the scenes: a sized ZString)

NOK only, with negative LONG.
With a temporary LONG (negative literal = assigned value), easily fixed ...

Also working, by using an assigned type specific variable, are:

• [U]Byte / [U]Short (here: the suffixes (forcing) are missing) and finally:
• [U]Long (here, the 'l' should do its job, IMHO, regardless of value)
  (Otherwise, a 4 byte negative LONG is *impossible*, with FBC 64!)

[paul doe]

There are no negative integer literals.

This is correct for C/C++. But, do we really have to do, the same *nonsense* in FB?

This 'nonsense' is due to the way expressions are parsed. So, changing this behavior would imply changing it at the parsing level, unfortunately...

[MrSwiss]

So, changing this behavior would imply changing it at the parsing level, unfortunately...

Hell, I know that, too.

That's the reason, I find current behaviour, to be a BUG.
Since, it only affects a specific type: LONG.

Negative literals, with all other types, can be forced, by suffix!

[cbruce]

.

There are no negative integer literals.

This is correct for C/C++. But, do we really have to do, the same *nonsense* in FB?

MrSwiss, please do not misinterpret this. I am not making fun of you!

Having watched the development of FreeBASIC for 15 years, I have always seen factions who want to change the direction of the development. But that has always been towards C++ and OOP... which is now the standard for FB.

This is the first time in forever that I have seen someone say "do we really have to do, the same *nonsense* in FB?".

I love FreeBASIC... but, given its history, that comment had me snorting root beer out my nose! [BIG GRIN}
.

[fxm]

I'll file a bug-report, on Source Forge in 24h ...

So, changing this behavior would imply changing it at the parsing level, unfortunately...

I think it's useful to fill in a bug report, at least to keep an official tracking of this non-obvious behavior.

[paul doe]

I think it's useful to fill in a bug report, at least to keep an official tracking of this non-obvious behavior.

My, of course. I didn't imply that we shouldn't. Seems like we're bumping into a lot of bugs lately... :'(

[fxm]

For now, I'm going to put a note in the documentation on the Literals page, in the "Integer size suffixes" paragraph.

[MrSwiss]

Further extending the test-code revealed that:
Coercion & Coversion (from manual) is correct, e.g. with 'LL' in FBC 64,
conversion to "Integer" is made ... (maybe better, to just state in manual,
that the suffix-forcing only works, as expected, with positive numbers).
Thus, largely defeating the purpose, of the suffix(es)!

Currently:
Specifying a size suffix guarantees that the compiler will consider a number as a specific integer size.
--- This is clearly, not the case, with all negative numbers! ---

[fxm]

For now, I'm going to put a note in the documentation on the Literals page, in the "Integer size suffixes" paragraph.

Done:
ProPgLiterals → fxm [Added a note on "negative" integer literal with a size suffix]