| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Similar to the bug fixed in the previous commit, going through the
non-UTF-8 path of ByteArray.fromString() with a zero-length string would
crash. Create an empty Uint8Array here as well.
|
| |
|
|
|
| |
ByteArray.fromGBytes() would crash if the GLib.Bytes had zero length.
Anticipate this case and just create an empty Uint8Array.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Based on looking at the git logs, add copyright notices to files which
were missing them, assuming the copyright belongs to people who made major
contributions to each file.
Some assumptions were made as to who to assign the copyright to, such as,
what copyright assignment did the contributor make in other files added in
the same commit? What email address did they use to make the commit? What
copyright assignment did they make in other commits using the same email
address?
|
| |
|
|
|
|
| |
This adds a SPDX-License-Identifier comment to all files that are part
of GJS, part of its unit tests, or auxiliary tools. (Except for some
files like the debugger scripts that don't support comments.)
|
| |
|
|
|
|
|
|
| |
This is done quite inconsistently across the codebase, so we pick the
most common style and enforce it. That is, no space before function
parentheses, except in the case of anonymous functions and async arrow
functions, where we add a space so as not to conflict with the rule of
spaces around keywords.
|
| |
|
|
|
|
|
| |
We should not access the data pointer if the length is 0. This was also
causing a crash.
Closes #219.
|
| |
|
|
|
|
| |
This avoids a crash when the wrong object is passed to the functions.
Closes #219.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason why there was a byte order mark (BOM) in the encoded string
was not due to GLib, but instead due to iconv. We specified the encoding
"UTF-16", and iconv will in that case write bytes with a system-default
UTF-16 endianness, starting with a BOM to tell you which one it chose.
To make matters worse, this iconv default is little-endian on Linux and
big-endian on Mac (despite the processor being little-endian! Maybe this
is for compatibility with files from the m68k days.) So, on macOS the
"abcd" test was coming out completely garbled.
The correct thing to do, since we are interpreting the bytes as a
char16_t array in memory, is to make sure that iconv writes them into
memory in the processor's endianness, not the system's default UTF-16
endianness.
This fixes a regression from !232 on macOS (and probably on all
big-endian machines as well.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a regression from 1.50 to 1.52. JS strings with embedded 0
bytes will behave in unexpected ways, and is almost never what client
code wants, so we should avoid this.
Additionally, avoids an extra copy in the non-fast-path of toString().
The BOM in the output of toString('LATIN1') was a surprise to me, but I
verified that it happened even before this patch, so that behaviour has
not changed.
Closes: #195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This overrides, on each Uint8Array returned from an introspected function
or from ByteArray.fromString() or ByteArray.fromGBytes(), the toString()
property with a compatibility shim that preserves the old behaviour of
ByteArray.prototype.toString() while logging a compatibility warning
asking people to fix their code.
This ByteArray.toString() -> Uint8Array.toString() change has had more
fallout in application code than I expected, so it seems better to
preserve backwards compatibility. (The old behaviour was to decode the
byte array into a string with default encoding UTF-8, and the default
behaviour of Uint8Array is to return a string with the decimal digits of
each byte joined with commas. So the effect was that strings like
"97,98,99,100" would show up in UIs where previously "abcd" would have
been printed.
This is only on specific instances, so Uint8Array.prototype.toString()
remains untouched.
|
| |
|
|
|
|
|
|
|
|
| |
This should make it easier to keep old code working. It adds a legacy
ByteArray.ByteArray class that works just like the old ByteArray class
but uses Uint8Array internally. It isn't zero-copy, so it will regress
the performance of old code, but it should keep almost all code at least
working. To recover the performance, clients can use Uint8Array instead.
See: #5
|
| |
|
|
|
|
|
|
|
|
|
| |
It's possible to replace ByteArray with Uint8Array and have almost the
same functionality, making GJS code closer to standard Javascript, and
removing a large amount of code.
This is necessary because getProperty/setProperty hooks are removed from
JSClass, which the old ByteArray relied on for its array access.
Closes #5.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with SpiderMonkey 38, strings can be stored internally in the
JS engine as either Latin-1 or two bytes per character (sort-of-UTF-16).
When operating on the characters directly, we must check
JS_StringHasLatin1Chars() and use the appropriate accessors depending on
how they are stored.
Additionally, since the string's characters are still owned by the
string and may get moved around during garbage collection, we cannot use
any JSAPI functions that might trigger a GC while maintaining a pointer
to the string's characters. To enforce this, we must construct a
JS::AutoCheckCannotGC object, which will cause a crash if a GC starts
while it is in scope.
https://bugzilla.gnome.org/show_bug.cgi?id=777962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the old JSUnit test harness with an embedded copy of
Jasmine [1], which makes writing tests less of a pain, includes more
handy test facilities, and produces better output.
jasmine.js is a copy of upstream Jasmine 2.5.2. minijasmine.js contains
code for starting up Jasmine, adapting it to the GJS environment, and
producing TAP output. minijasmine.cpp makes an executable which loads the
preceding two files from the unit test GResource.
All the tests in installed-tests/js are converted to use Jasmine's
describe()/it() style. Quite often this allows simplifying them since
Jasmine has features like array and object equality, spies, and clock
ticks.
[1] https://jasmine.github.io/2.5/introduction.html
https://bugzilla.gnome.org/show_bug.cgi?id=775444
|
| |
|
|
|
|
|
| |
And remove the APIs/ability to scan for a JS version to use.
Upstream wants to remove this API.
https://bugzilla.gnome.org/show_bug.cgi?id=721355
|
|
|
This is a lot less traumatic for distributions, among other
things.
https://bugzilla.gnome.org/698935
|
