##// END OF EJS Templates
manifest: delay import of `typing.ByteString` for py 3.14 support (issue6940)...
manifest: delay import of `typing.ByteString` for py 3.14 support (issue6940) Since Python 2.7 and 3.5, `typing.ByteString` was defined as an alias for `bytes | bytearray | memoryview`, and `bytes` was also accepted as a shorthand for this, so we have `bytes` sprinkled all over the codebase. But then PEP-688 reversed all of that by deprecating `typing.ByteString` and its successor `collections.abc.ByteString` in Python 3.12 (as well as the `bytes` shorthand)[1], and removing it completely in Python 3.14. That leaves us with a couple of problems, namely defining something useful that spans py3.8-py3.13 and keeps pytype happy, and finding all of the instances where `bytes` doesn't really mean `bytes`. The current successor to all of this is `collections.abc.Buffer` in Python 3.12 (or `typing_extensions.Buffer` in previous versions). However, the current CI does type checking using Python 3.11 (so the former is not avaiable), and pytype has issues with importing `typing_extensions.Buffer`[2]. The good news is we don't need to deal with this mess immediately, since the type annotation evaluation is delayed to the type checking phase, and we're making no effort at supporting it in all supported versions of Python. So by delaying the import of this particular symbol, we can still use it for type checking purposes, but can start assessing Python 3.14 problems without doing a lot of extra work. Putting this on stable will allow people interested in 3.14 to work on it 4-5 extra months earlier (and apparently there's some interest). [1] https://peps.python.org/pep-0688/#no-special-meaning-for-bytes [2] https://github.com/google/pytype/issues/1772

File last commit:

r44253:01ec70a8 default
r53224:0851d94b stable
Show More
standalone_fuzz_target_runner.cc
45 lines | 1.5 KiB | text/x-c | CppLexer
/ contrib / fuzz / standalone_fuzz_target_runner.cc
// Copyright 2017 Google Inc. All Rights Reserved.
// Licensed under the Apache License, Version 2.0 (the "License");
// Example of a standalone runner for "fuzz targets".
// It reads all files passed as parameters and feeds their contents
// one by one into the fuzz target (LLVMFuzzerTestOneInput).
// This runner does not do any fuzzing, but allows us to run the fuzz target
// on the test corpus (e.g. "do_stuff_test_data") or on a single file,
// e.g. the one that comes from a bug report.
#include <cassert>
#include <fstream>
#include <iostream>
#include <vector>
// Forward declare the "fuzz target" interface.
// We deliberately keep this inteface simple and header-free.
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv);
int main(int argc, char **argv)
{
LLVMFuzzerInitialize(&argc, &argv);
for (int i = 1; i < argc; i++) {
std::ifstream in(argv[i]);
in.seekg(0, in.end);
size_t length = in.tellg();
in.seekg(0, in.beg);
std::cout << "Reading " << length << " bytes from " << argv[i]
<< std::endl;
// Allocate exactly length bytes so that we reliably catch
// buffer overflows.
std::vector<char> bytes(length);
in.read(bytes.data(), bytes.size());
assert(in);
LLVMFuzzerTestOneInput(
reinterpret_cast<const uint8_t *>(bytes.data()),
bytes.size());
std::cout << "Execution successful" << std::endl;
}
return 0;
}
// no-check-code since this is from a third party