Comments (4)
- I guess integer constants is always
LONGINT
, so that the problem with sign extension where the integer value
is treated as an unsigned value is not a problem here.
The constants are recognized as follows (output from debug build).
CONST CCHAR*(*Scope:1*) = "A"(*C*)(*Type:CHAR*);
CINT*(*Scope:1*) = 100(*S*)(*Type:SHORTINT*);
CLINT*(*Scope:1*) = -1(*L*)(*Type:LONGINT*);
CREAL*(*Scope:1*) = 1.1(*F*)(*Type:REAL*);
CREALMAX*(*Scope:1*) = 1.79769e+308(*D*)(*Type:LONGREAL*);
CBOOL*(*Scope:1*) = TRUE(*Type:BOOLEAN*);
CSET*(*Scope:1*) = { 0, 31 } (* 2147483649: 10000000000000000000000000000001 *)(*Type:SET*);
CSTR*(*Scope:1*) = "testing123"(*Type:STRING*);
-1
begin a recognized as a LONGINT
might not be ideal.
- The decimal float value
1.1
is inexact represented in base 2 floating point representation and the constant will
have different value depending on whether the type isREAL
orLONGREAL
.
The Oberon-02 report solves this with creating an additional float format w[h]ere1.1
and1.1E0
isREAL
, while1.1D0
isLONGREAL
.
This is actually already in Oberon-90. I can extend the Scanner accordingly. But I wonder whether it would make sense to lift the decision whether a literal is treated as REAL
or LONGREAL
to Sema as the Scanner has no information on whether the compiler is in Oberon-90, Oberon-2 or Oberon-07 mode.
- The last line commented out triggers the crash here.
Not surprising as I've never put any effort into exported variables, nor have I tested that. I'm sure this can be supported relatively easy by setting the correct linkage type in CodeGen.
- Oberon-07 limit exported constant to integer type. e.g.
REAL
not allowed to be exported. This is probably done to keep the compiler as simple as possible and I do not see any logical reason for that.
Wirth moves in mysterious ways?
- Exported variables in Oberon-07 is read only. This makes sense as it forces the module state to be encapsulated.
This can be supported by adding corresponding checks to Sema.
from oberon-lang.
Excellent.
0FFFFFFFFFFFFFFFFH
is in signed int64 equal to-1
.Out.LongHex(l)
printsFFFFFFFFFFFFFFFF
.
We would have the same problem with sign extension of "hex" values if the constant is inferred as a smaller type.- No show stopper.
- FI can work around the missing exported variable by using procedures.
- I suspect there are several corner cases where Project Oberon have simplified things to keep is simple.
- I think Oberon-2 allow for read/write variables and have the extra
-
export marker for read-only variables.
EDIT : Updated 1.
from oberon-lang.
This should be fixed in the latest pull request. The following works for me now (macOS, arm64) as expected with the test modules that you provided, @tenko!
oberon-lang -I.:./include -L./lib -loberon M.Mod
oberon-lang -I.:./include -L./lib -loberon -fenable-main TestImport.Mod
clang -o TestImport TestImport.o M.o -L./lib -loberon -rpath @executable_path/lib
./TestImport
Let me know if it fixes the issue for you too! Thanks!
from oberon-lang.
Excellent.
This fixes the issue for me.
from oberon-lang.
Related Issues (20)
- endian.h not found on Windows platform HOT 2
- Enforce position of module level VAR section? HOT 5
- Output file argument not working HOT 2
- Avoid writing .smb file for JITed main module HOT 2
- Array passed as argument is shorten HOT 2
- Export of CHAR constants not supported HOT 1
- Making Unit Tests Work! HOT 13
- Add MSYS2 page to Wiki HOT 1
- Add Embedded example to wiki HOT 1
- Cross platform support HOT 2
- Compilation error due to extra semicolon
- CHAR variable not treated equal to CHAR literal HOT 5
- Bug in name mangling of (un)nested procedures HOT 2
- Undefined behavior due to nested procedure HOT 7
- Crash with assignment of string literal reference returned from procedure HOT 4
- DIV and MOD not in line with Oberon-07 report HOT 3
- Build report ArchLinux HOT 4
- Proposal to make runtime functionality configurable.
- Access to argc & argv
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oberon-lang.