Certain internet service providers transmit vlan 0 priority tagged
EAPOL frames from the ONT towards the residential gateway. VID 0
should be ignored, and the frame processed according to the priority
set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).
The pcap filter utilized by l2_packet is inadquate for this use case.
Here we modify the pcap filter to accept both unencapsulated and
encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
original filter behavior while also matching on encapsulated EAPOL.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Reviewed by: cy
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40442
Two files used to obtain time from reference clocks did not include
ntp_types.h resulting in an undefined NONEMPTY_TRANSLATION_UNIT.
Fixes: e6bfd18d21
MFC after: 3 days
X-MFC-with: e6bfd18d21
Important changes (relevant to FreeBSD):
#1814 Do not account for NULL terminator when comparing with "TRAILER!!!"
#1818 Add ability to produce multi-frame zstd archives
#1860 Make single bit bitfields unsigned to avoid clang 16 warning
#1869 Fix FreeBSD builds with WARNS=6
Obtained from: libarchive
Libarchive commit: 1f3c62ebf4d492ac21d3099b3b064993100dd997
Make struct pfsync_state contents configurable by sending out new
versions of the structure in separate subheader actions. Both old and
new version of struct pfsync_state can be understood, so replication of
states from a system running an older kernel is possible. The version
being sent out is configured using ifconfig pfsync0 … version XXXX. The
version is an user-friendly string - 1301 stands for FreeBSD 13.1 (I
have checked synchronization against a host running 13.1), 1400 stands
for 14.0.
A host running an older kernel will just ignore the messages and count
them as "packets discarded for bad action".
Reviewed by: kp
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D39392
Merge commit 069ecd0c6e2c from llvm-project (by Fangrui Song):
[ARM] Check target feature support for __builtin_arm_crc*
`__builtin_arm_crc*` requires the target feature crc which is available on armv8
and above. Calling the fuctions for armv7 leads to a SelectionDAG crash.
```
% clang -c --target=armv7-unknown-linux-gnueabi -c a.c
fatal error: error in backend: Cannot select: intrinsic %llvm.arm.crc32b
PLEASE submit a bug report to ...
```
Add `TARGET_BUILTIN` and define required features for these builtins to
report an error in `CodeGenFunction::checkTargetFeatures`. The problem is quite widespread.
I will add `TARGET_BUILTIN` for more builtins later.
Fix https://github.com/llvm/llvm-project/issues/57802
Differential Revision: https://reviews.llvm.org/D134127
Merge commit b2d7a0dcf1ff from llvm-project (by Fangrui Song):
[AArch64] Check target feature support for __builtin_arm_crc*
This is the AArch64 counterpart of D134127.
Daniel Kiss will change more `BUILTIN` to `TARGET_BUILTIN`.
Fix#57802
Note that programs attempting to use ARM/AArch64 CRC intrinsics, when
they are not supported by the targeted CPU, will still receive a regular
compilation error (instead of a fatal backend error) similar to:
7zCrc.c:4:10: error: '__builtin_arm_crc32b' needs target feature crc
return __builtin_arm_crc32b(a, b);
^
Reported by: Alastair Hogge <agh@riseup.net>
PR: 271624
MFC after: 3 days
Merge commit 0e7971154ecb from llvm-project (by Christopher Di Bella):
[libcxx][NFC] utilises compiler builtins for unary transform type-traits
Depends on D116203
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D131732
Clang 16 got new builtins that are equivalent to hand-written parts of
<type_traits>. When building world with the devel/llvm16 package
installed and CROSS_TOOLCHAIN=llvm16 set, this would lead to -Werror
warnings about those builtins being overridden.
Reported by: emaste
MFC after: 3 days
As of OpenSSL 1.1 SSL_library_init() and SSL_load_error_strings() are
deprecated. There are replacement initialization functions but they do
not need to be called: "As of version 1.1.0 OpenSSL will automatically
allocate all resources that it needs so no explicit initialisation is
required."
Wrap both calls in an OPENSSL_VERSION_NUMBER block.
Upstream pull request submitted at
https://github.com/openbsm/openbsm/pull/82
PR: 271615
Reviewed by: ngie
Event: Kitchener-Waterloo Hackathon 202305
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40273
As of 9fb6718d1b / __FreeBSD_version 1400089 stoppcbs is a pointer to
the pcbs array. Dereference stoppcbs on sufficiently new kernels.
Reviewed by: markj (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39939
This update removes printing of a leading zero in scientific or
engineering output modes (which are an extended feature of this
implementation).
(cherry-picked from commit 8b83ef067441f6d3a4a55e92d1738724954a057c)
MFC after: 2 weeks
> The SSL_library_init() and OpenSSL_add_ssl_algorithms() functions were
> deprecated in OpenSSL 1.1.0 by OPENSSL_init_ssl().
and
> The ERR_load_crypto_strings(), SSL_load_error_strings(), and
> ERR_free_strings() functions were deprecated in OpenSSL 1.1.0 by
> OPENSSL_init_crypto() and OPENSSL_init_ssl() and should not be used.
Reviewed by: ngie
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40065
Some highlights from NEWS:
** bio: fix CTAP2 canonical CBOR encoding in fido_bio_dev_enroll_*();
gh#480.
** New API calls:
- fido_dev_info_set;
- fido_dev_io_handle;
- fido_dev_new_with_info;
- fido_dev_open_with_info.
** Documentation and reliability fixes.
** Support for TPM 2.0 attestation of COSE_ES256 credentials.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Some highlights from NEWS:
** Added OpenSSL 3.0 compatibility.
** Removed OpenSSL 1.0 compatibility.
** Support for FIDO 2.1 "minPinLength" extension.
** Support for COSE_EDDSA, COSE_ES256, and COSE_RS1 attestation.
** Support for TPM 2.0 attestation.
** Support for device timeouts; see fido_dev_set_timeout().
** New API calls:
- es256_pk_from_EVP_PKEY;
- fido_cred_attstmt_len;
- fido_cred_attstmt_ptr;
- fido_cred_pin_minlen;
- fido_cred_set_attstmt;
- fido_cred_set_pin_minlen;
- fido_dev_set_pin_minlen_rpid;
- fido_dev_set_timeout;
- rs256_pk_from_EVP_PKEY.
** Reliability and portability fixes.
** Better handling of HID devices without identification strings; gh#381.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Merge commit 484e64f7e7b2 from llvm-project (by Roland McGrath):
[libc++] Use __is_convertible built-in when available
https://github.com/llvm/llvm-project/issues/62396 reports that
GCC 13 barfs on parsing <type_traits> because of the declarations
of `struct __is_convertible`. In GCC 13, `__is_convertible` is a
built-in, but `__is_convertible_to` is not. Clang has both, so
using either should be fine.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D149313
Reported by: Mark Millard <marklmi@yahoo.com>
MFC after: 3 days
The fgetln loop will terminate with buf = NULL at EOF.
Reported by: GCC
Reviewed by: kp
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39947
This release that fixes an infinite loop bug in the (non-standard)
extended math library functions root() and cbrt(), fixes a bug with
BC_LINE_LENGTH=0, and adds the fib() function to the extended math
library to calculate Fibonacci numbers.
(cherry picked from commit 438a1101dc1f687928cdbe02cd7817a88a24f42f)
MFC after: 3 days
Merge commit a5e1a93ea10f from llvm-project (by Mariya Podchishchaeva):
[clang] Fix crash when handling nested immediate invocations
Before this patch it was expected that if there was several immediate
invocations they all belong to the same expression evaluation context.
During parsing of non local variable initializer a new evaluation context is
pushed, so code like this
```
namespace scope {
struct channel {
consteval channel(const char* name) noexcept { }
};
consteval const char* make_channel_name(const char* name) { return name;}
channel rsx_log(make_channel_name("rsx_log"));
}
```
produced a nested immediate invocation whose subexpressions are attached
to different expression evaluation contexts. The constructor call
belongs to TU context and `make_channel_name` call to context of
variable initializer.
This patch removes this assumption and adds tracking of previously
failed immediate invocations, so it is possible when handling an
immediate invocation th check that its subexpressions from possibly another
evaluation context contains errors and not produce duplicate
diagnostics.
Fixes https://github.com/llvm/llvm-project/issues/58207
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D146234
PR: 269489
MFC after: 3 days
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by various declarations in libarchive:
contrib/libarchive/libarchive/archive_write_set_format_7zip.c:1541:13: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
file->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5127:15: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5213:14: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5214:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7149:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7435:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.detect_magic = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7495:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.making = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7496:26: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7702:28: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7871:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->header_passed = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7894:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->initialized = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the fields as booleans, so make them unsigned.
This has also been sent upstream.
MFC after: 3 days
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by a declaration in bsnmp's snmpd.h:
contrib/bsnmp/snmpd/trans_lsock.c:271:21: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
peer->input.stream = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the field as a boolean, so make it unsigned.
MFC after: 3 days
The packet pointer (called packet) will remain uninitialized when
pcap_next_ex() returns an error. This occurs when the wlan
interface is shut down using ifconfig destroy. Adding a NULL
assignment to packet duplicates what pcap_next() does.
The reason we use pcap_next_ex() in this instance is because with
pacp_next() when we receive a null pointer if there was an error
or if no packets were read. With pcap_next_ex() we can differentiate
between an error and legitimately no packets were received.
PR: 270649
Reported by: Robert Morris <rtm@lcs.mit.edu>
Fixes: 6e5d01124f
MFC after: 3 days
Changes: https://github.com/eggert/tz/blob/2023c/NEWS
The tzdata 2023c release reverts all changes made in 2023b other than
commentary, as that appears to be the best of a bad set of short-notice
choices for modeling this week's daylight saving chaos in Lebanon.
MFC after: insta-MFC
Summary of changes:
- postpone mtu size assignment during load to avoid race condition
- refactor some of the debug prints
- add request reset handler
- refactor flush scheduler to increase efficiency and avoid racing
- put correct vlan_tag for UD traffic with PFC
- suspend QP before going to ERROR state to avoid CQP timout
- fix arithmetic error on irdma_debug_bugf
- allow debug flag to be settable during driver load
- introduce meaningful default values for DCQCN algorithm
- interrupt naming convention improvements
- skip unsignaled completions in poll_cmpl
Signed-off-by: Bartosz Sobczak bartosz.sobczak@intel.com
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: hselasky@
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D39173
This reverts the state to our old supplicant logic setting or clearing
IFF_UP if needed. In addition this adds logging for the cases in which
we do (not) change the interface state.
Depending on testing this seems to help bringing WiFi up or not log
any needed changes (which would be the expected wpa_supplicant logic
now). People should look out for ``(changed)`` log entries (at least
if debugging the issue; this way we will at least have data points).
There is a hypothesis still pondered that the entire IFF_UP toggling
only exploits a race in net80211 (see further discssussions for more
debugging and alternative solutions see D38508 and D38753).
That may also explain why the changes to the rc startup script [1]
only helped partially for some people to no longer see the
continuous CTRL-EVENT-SCAN-FAILED.
It is highly likely that we will want further changes and until
we know for sure that people are seeing ''(changed)'' events
this should stay local. Should we need to upstream this we'll
likely need #ifdef __FreeBSD__ around this code.
[1] 5fcdc19a81 and
d06d7eb091
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: cy, enweiwu (earlier)
Differential Revision: https://reviews.freebsd.org/D38807
Although this code is in contrib/ there is no active upstream.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36047
- In the msgctl tests, there is no point in sleeping after a fork().
Just block immediately in wait().
- In non-blocking send/recv tests, just wait for the child to exit once
it's reached a message limit. If a bug prevents the child from
exiting promptly, the test will time out.
MFC after: 1 week
This version contains a fix for an issue that can affect complex
bc scripts that use multiple read() functions that receive input from
an interactive user. The same value could be returned multiple times.
MFC after: 2 weeks
Most ATM support was removed prior to FreeBSD 12. The netgraph support
was kept as it was less intrusive, but it is presumed to be unused.
Reviewed by: manu
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D38879
When the kernel is built without capability mode support, or when
using an emulator like qemu-user-static that does not translate
system calls, these calls will return a negative number and set
the errno to ENOSYS. However, this error does not indicate a
real programming or runtime error and is generally ignored by
base system applications built with capability mode sandboxing.
Match this behavior by making xz(1) to ignore ENOSYS errors
when calling capability mode system calls too.
PR: 269185
Reported by: Dan Kotowski
MFC after: 2 days
This version adds a command to dc to query whether extended registers
are enabled or not.
(cherry picked from commit 61e1a12bb6c3bfdb0a4e499c88e8eaa2b548e427)
Note that this enables the backtracking extension, which we had previously left disabled.
PR: 244149, 269425
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38421
Currently LLVM is more or less set up to use ELFv2, but it still defaults to
ELFv1 in some places. This causes lld to generate broken binaries when used
with LTO.
PR: 269455
Approved by: dim
MFC after: 3 days
In the past, we modified pcap/pcap.h to include the system net/bpf.h
rather than libpcap's own pcap/bpf.h. However, starting around 1.10.2,
libpcap requires a few extern functions defined in pcap/bpf.h to build.
Simply reverting that local change and pulling in pcap/bpf.h is not a
solution, because some ports with '#include <pcap.h>' such as mail/spamd
and net/xprobe require the system net/bpf.h to be pulled in. To
accommodate both requirements, make pcap/bpf.h a wrapper around the
system net/bpf.h, but retain the extern function definitions. This is
in preparation for libpcap 1.10.3.
Approved by: cy, philip, emaste, delphij (earlier revision)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38575
This function has been around since 4.4BSD but was dropped upstream in 2020. This went unnoticed when tzcode was updated. Bring it back, but prepare for removing it before 14.0 is released.
PR: 269445
MFC after: 3 days
Reported by: val@packett.cool
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38445
GCC expands the pointer type in this conditional expression even for
template types _Up that are not arrays. This raises an error when
std::decay<> is used with reference types (as is done in LLVM's
sources). Using add_pointer<> causes GCC to only instantiate a
pointer type for array types.
A similar change to this commit (albeit reworked due to upstream
changes) has been merged to libc++ in commit
26068c6e60324ed866a1ca2afb5cb5eb0aaf015b.
In file included from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/ordering.h:13,
from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/common_comparison_category.h:12,
from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/tuple:168,
from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20,
from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17,
from /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:36:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits: In instantiation of 'struct std::__1::__decay<llvm::CHIArg&, true>':
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1591:89: required from 'struct std::__1::decay<llvm::CHIArg&&>'
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__utility/pair.h:132:16: required by substitution of 'template<class _Tuple, typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> > constexpr std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::pair(_Tuple&&) [with _Tuple = llvm::CHIArg&&; typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> = <missing>]'
/usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:892:51: required from here
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1582:30: error: forming pointer to reference type 'std::__1::remove_extent<llvm::CHIArg&>::type' {aka 'llvm::CHIArg&'}
1582 | >::type type;
| ^~~~
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D36898
This reapplies commit c36de97088, which I
accidentally overwrote in the llvm 15 merge. (It turns out upstream did
not merge this to their 15.x branch.)
MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17826-g1f8ae9d7e7e4, the last commit before
the upstream release/16.x branch was created.
PR: 265425
MFC after: 2 weeks
Merge commit '755d9301ca89f02956fd17858b9d4d821ab5c972' from the
vendor branch. This updates us from lua 5.4.2 to 5.4.4.
In addition, it switches around how we flavor liblua for the boot loader
and flua. This is done to reduce diffs with upstream and make it easier
to import new versions (the current method has too many conflicts to
resolve by hand): we include luaconf.local.h from luaconf.h (the only
change to this file is now that #include at the end). We then define
what we need to: for flua (which does very little) and one for stand
(which creates the new FLOAT type out of int64).
Sponsored by: Netflix
This is not exhaustive - DWARF 5 has some new enumeration types not
implemented here - but I think I caught all the ones that are extended
in DWARF 5, plus the new compilation unit type (DW_UT_*), needed when
parsing .debug_info headers.
These were useful when extending libdwarf/ctfconvert/readelf to handle
DWARF generated by gcc 12, which is version 5 by default.
Reviewed by: emaste
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38273
Current content of the irdma(4) driver consists only of code that is
compilable on current 14-CURRENT branch which makes it impossible to
merge into stable/13 branch because of missing dependencies in the ofed
tree.
This patch adds missing code that allows for merging into stable branch.
Once it is there, code relating only to version 14 or higher should be
removed.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: erj@
MFC after: 1 day
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D38170
This update contains only documentation changes (new main repository
URL and changed mail address of the program author) and changes to
the build system that do not affect the FreeBSD base system build.
MFC after: 3 days
A few have been added, a couple removed.
Reviewed by: jrtc27, imp, emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38175
This update fixes a few issues in history editing and the processing
of the "quit" function. The "quit" function will no longer cause bc
to exit when encountered in a script file (before any command from
the script has been executed).
New functions is_number(), is_string return 1 if the passed argument
is a number resp. a string. The asciify() function has been extended
to support the conversion of an array of numbers into a string.
Merge commit '1a63323d17fedb05b6962853e821c9d7c6b9853e'
