aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/erl_bif_guard.c
AgeCommit message (Collapse)Author
2017-05-04Update copyright yearRaimo Niskanen
2017-02-16Merge branch 'maint' into 'master'Sverker Eriksson
2017-02-14erts: Fix round/1 for large floatsSverker Eriksson
1> round(6209607916799025.0). 6209607916799026 Problem: Adding/subtracting 0.5 and large double floats between (1 bsl 52) and (1 bsl 53) does not give reliable results. Solution: Use round() function in math.h.
2016-09-05Implement the new ceil/1 and floor/1 guard BIFsBjörn Gustavsson
Implement as ceil/1 and floor/1 as new guard BIFs (essentially part of Erlang language). They are guard BIFs because trunc/1 is a guard BIF. It would be strange to have trunc/1 as a part of the language, but not ceil/1 and floor/1.
2016-03-15update copyright-yearHenrik Nord
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-16Merge branch 'egil/maps-refactor'Björn-Egil Dahlberg
* egil/maps-refactor: erts: Use make_small for size terms on flat maps Conflicts: erts/emulator/beam/erl_bif_guard.c
2015-04-15Raise more descriptive error messages for failed map operationsBjörn Gustavsson
According to EEP-43 for maps, a 'badmap' exception should be generated when an attempt is made to update non-map term such as: <<>>#{a=>42} That was not implemented in the OTP 17. José Valim suggested that we should take the opportunity to improve the errors coming from map operations: http://erlang.org/pipermail/erlang-questions/2015-February/083588.html This commit implement better errors from map operations similar to his suggestion. When a map update operation (Map#{...}) or a BIF that expects a map is given a non-map term, the exception will be: {badmap,Term} This kind of exception is similar to the {badfun,Term} exception from operations that expect a fun. When a map operation requires a key that is not present in a map, the following exception will be raised: {badkey,Key} José Valim suggested that the exception should be {badkey,Key,Map}. We decided not to do that because the map could potentially be huge and cause problems if the error propagated through links to other processes. For BIFs, it could be argued that the exceptions could be simply 'badmap' and 'badkey', because the bad map and bad key can be found in the argument list for the BIF in the stack backtrace. However, for the map update operation (Map#{...}), the bad map or bad key will not be included in the stack backtrace, so that information must be included in the exception reason itself. For consistency, the BIFs should raise the same exceptions as update operation. If more than one key is missing, it is undefined which of keys that will be reported in the {badkey,Key} exception.
2015-04-14erts: Use make_small for size terms on flat mapsBjörn-Egil Dahlberg
2015-03-12erts: Refactor maps naming conventionSverker Eriksson
flatmap: Small map hashmap: Large map map: flatmap or hashmap
2015-03-12erts: Remove erl_hashmap.[ch] filesBjörn-Egil Dahlberg
2015-03-12erts: Move hashmap:size/1 to mapsBjörn-Egil Dahlberg
2014-01-28erts: Add the size-testing guard BIF map_size/1Björn-Egil Dahlberg
2011-12-09Update copyright yearsBjörn-Egil Dahlberg
2011-12-02Iron out bugs in Win64 found in daily buildsPatrik Nyblom
Almost all uses of the 'long' datatype is removed from VM and tests Emulator test now runs w/o drivers crashing Nasty abs bug fixed in VM as well as type errors in allocator debug functions Still one allocator test that fails, domain knowledge is needed to fix that. Fix type inconsistency in beam_load causing crashes
2010-05-17Add guard BIFs binary_part/2,3Patrik Nyblom
Add the gc_bif's to the VM. Add infrastructure for gc_bif's (guard bifs that can gc) with two and. three arguments in VM (loader and VM). Add compiler support for gc_bif with three arguments. Add compiler (and interpreter) support for new guard BIFs. Add testcases for new guard BIFs in compiler and emulator.
2010-01-19Merge branch 'bg/compiler-beam_validator' into ccase/r13b04_devErlang/OTP
* bg/compiler-beam_validator: beam_validator: fix incorrect assumptions about GC guard BIFs OTP-8378 In rare circumstances when using garbaging collecting guard BIFs, the validation pass (beam_validator) would signal that the code was unsafe, when it in fact was correct. (Thanks to Kiran Khaladkar.)
2010-01-15beam_validator: fix incorrect assumptions about GC guard BIFsBjörn Gustavsson
The beam_validator pass incorrectly assumes that a GC guard BIF (such as length/1) may first do a garbage collection and then fail. That assumption is not correct (guards BIF only do garbage collection when it is known that the BIF call will succeed), and will cause the compiler to reject valid programs. Modify the beam_validator to assume that if the branch is taken for a gc_bif instruction, all registers are unchanged and no garbage collection has occurred. Also add a comment in the emulator about that assumption.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP