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

General FreeBASIC programming questions.
MrSwiss
Posts: 3132
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Apr 22, 2018 16:28

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
Posts: 47
Joined: Jun 13, 2015 19:33

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

Postby adele » Apr 22, 2018 17:16

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
Posts: 3132
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Apr 22, 2018 17:46

@adele,
adele wrote: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!
Manual wrote: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
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Apr 22, 2018 18:17

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
Posts: 3132
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Apr 22, 2018 18:33

fxm wrote: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
Posts: 135
Joined: Sep 12, 2007 19:13
Location: Dallas, Texas

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

Postby cbruce » Apr 22, 2018 19:03

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
Posts: 3132
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Apr 23, 2018 14:09

cbruce wrote: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
Posts: 915
Joined: Jul 25, 2017 17:22
Location: Argentina

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

Postby paul doe » Apr 23, 2018 14:24

MrSwiss wrote:
cbruce wrote: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
Posts: 3132
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Apr 23, 2018 14:50

paul doe wrote: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
Posts: 135
Joined: Sep 12, 2007 19:13
Location: Dallas, Texas

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

Postby cbruce » Apr 23, 2018 15:52

.
MrSwiss wrote:
cbruce wrote: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
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Apr 23, 2018 16:24

MrSwiss wrote:I'll file a bug-report, on Source Forge in 24h ...
paul doe wrote: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
Posts: 915
Joined: Jul 25, 2017 17:22
Location: Argentina

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

Postby paul doe » Apr 23, 2018 16:32

fxm wrote: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
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Apr 23, 2018 16:41

For now, I'm going to put a note in the documentation on the Literals page, in the "Integer size suffixes" paragraph.
MrSwiss
Posts: 3132
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Apr 23, 2018 17:09

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
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Apr 23, 2018 18:12

fxm wrote: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]

Return to “General”

Who is online

Users browsing this forum: Majestic-12 [Bot] and 1 guest