I have an old AIR file that works fine. I tried to recompile it but the resulting airfile is buggy.
After digging in the code, i found that at some place strings are parsed to ints, and that the resulting int does not correspond to the string.
So i made a simple Actionscript file and executed the code:
var test:int = parseInt("3710835714");
and the variable will have the value
-584131582
So this looks like an overflow. But i'm surprised that the air file i have (which i didn't compile myself) runs just fine. So I wonder - does the internal representation of int somehow depend on what version of the Flex or AIR sdk libraries one is using for compiling?
//edit: it seems it boils down to this test:
var obj:Object = new Object();
obj.val="3710835714";
var test1:Boolean = (obj.val==-584131582);
var test2:Boolean = (int(obj.val)==-584131582);
this evaluates for me to
test1=false;
test2=true;
however - the this old AIR file seems to evaluate both cases to true. How can that be?
It is happening due to Give number exceeds ActionsScript Int limit
The int data type is stored internally as a 32-bit integer and comprises the set of integers from -2,147,483,648 (-231) to 2,147,483,647 (231 - 1),
and number 3,710,835,714 exceeds it by 1563352067
but your parse result shows compiler is considering it as Uint, whose Max limit is 4,294,967,295 i.e
-584131581 = 3,710,835,714 - 4,294,967,295
You should use Uint or Number for big whole-numbers/integers
this blog may helps you
ActionScript 3 Number data type problem with long integer values
Hopes that works
Related
I have a very old piece of code to handle Excel files in Delphi 5, which I adapted to work with Delphi 2005, which I used professionally until 2010. Since then, there was no reasonable free version of Delphi. Therefore, it is only now that using Delphi 10.2.3 Tokyo I would like to adapt it once again.
A problem that I was not able to solve is related to the use of OleStream.Seek(...) in the function given below, where I get a fatal error with all expressions in OleCheck(...).
Also, I didn't find any hint on a similar problem searching for the function OleStream.Seek(...) on the Internet.
The code is the following
function Streamseek(offset : longint; origin: word):string;
var
Pos : longInt ; // Pos: largeint;
begin
if FBIFFVersion > biff4 then begin
case Origin of
soFromBeginning:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_SET,Pos)); // ENUM: set =0
soFromCurrent:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_CUR,Pos)); /// 1 cur
soFromEnd:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_END,Pos)); // 2 end
end;
Of course, it is just one function in a much bigger program, which is not relevant here.
My problem is: I searched for
OStream.Seek(Offset,STREAM_SEEK_SET,Pos) on the Internet, but I could only find OleStream.seek(offset : longint; origin: word):string; except for one webpage, but there the same types were used.
Working with IStream in Delphi
So, I wonder what parameter types need to be used.
In the German version of Delphi 10.2.3, I get the error:
[dcc32 Fehler] line(878): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen
In English:
The types of the real and the formal var parameters must be the same.
It is clear that largeint is not a modern parameter type, and I only see the possibility that, instead of Integer, LongInt, Int64 or else is needed since the number of parameters should be OK.
LongInt instead of Integer for offset does not work, Longint instead of LargeInt does not work for pos.
Has anyone an idea what might be the reason for the error? What are the required types of this function in Delphi 10.2.3?
I wrote a barebone progran template in XC8 (1.37) that I use to develop and test new GLCD functions for the 18F family. Programming is done via a PICkit3. Since I need to quicky reprogram several times the code it is really important that programming is faster as much as possible.
Tipically, the code size is around 2K and it takes less than 10 sec to program,
Everiything is fine until I must use a font table, defined as:
const char font8[] = {....
Now, with just $400 bytes added, the compiler place the table at the ROM's end and the programming of 64K memory takes more than 1 minute.
Is there any way to avoid this?
I tried to manually limit the memory range in the MPLABX options, but this is annoying and a little unsafe (sometimes part of code is truncated).
A while back I had to write some code for emissions testing, where I needed to copy data between extreme ends of RAM. To do that I needed to specify the exact memory addresses. You can also use the C extension __at() construct. http://ww1.microchip.com/downloads/en/DeviceDoc/50002053F.pdf#page=27
int scanMode __at(0x200);
const char keys[] __at(123) = { ’r’, ’s’, ’u’, ’d’};
int modify(int x) __at(0x1000) {
return x * 2 + 3;
}
I am trying to use a single 4KB string in my arduino sketch but this always seems to give a whole bunch of java errors in the console and never compiles. I believe, I am using it correctly:
const char sequence[] PROGMEM = {"0F0FF0 ... 0F0F0FF"};
By trial-and-error I determined that the maximum length I can get to compile successfully is 1104 characters. This doesn't seem to make much sense. Is there some unknown limitation in the compiler or is it an issue with the IDE? I'm using 1.0.5 but I get the same results in 1.6.5 as well. I'd really rather not split the array. Reading online, the size limit should be 32KB, which is far higher, than what I need.
Any help or explanation appreciated, please and thank you.
It's a limitation of the IDE, not the compiler. If you make it a single string still, but use C's string concatenation, it will compile. eg.
const char sequence[] PROGMEM = {
"0F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF0"
"0F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF0"
...
"0F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF00F0F0FF0"
};
I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..
I'm trying to exceed the shared memory object after shm_open and ftruncate successfully at fisrt. Here is the code,
char *uuid = GenerateUUID();
int fd = shm_open(uuid, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR);
if(fd == -1) perror("shm_open");
size_t shmSize = sizeof(container);
int ret = ftruncate(fd, shmSize);
perror("ftruncate first");
ret = ftruncate(fd, shmSize * 2);
perror("ftruncate second");
It could pass the first ftruncate, but for the second ftruncate, it exceeds failed with errno=22, "Invalid argument".
I also tried to ftruncate the memory object after mmap, refer to the ftruncate's man page, the shared memory should be formatted as zero to the new length.
Besides, I also tried to ftruncate the memory object in the child process (This is an IPC topic among two processes), the ftruncate returns "Invalid fd, no such file or directory" but I could shm_open and mmap successfully in child process.
Any ideas? Thanks!
I think this is a known "feature" of shm_open(), ftruncate(), mmap().
You have to ftruncate() the first time through to give the shared memory a length, but subsequent times ftruncate() gives that error number 22, which you can simply ignore.
The used implementation seems to conform to an older specification where returning an error is an allowed behavior for ftruncate(fd, length) when length exceeds the previous length:
If the file previously was smaller than this size, ftruncate() shall
either increase the size of the file or fail.