Tags: giordano/aws-c-common
Tags
Fix CMake option for choosing MSVC runtime library (awslabs#1054) **Issue:** Building with `-DSTATIC_CRT=ON` didn't actually do anything. **Diagnosis:** Our CMake logic relied on `${CMAKE_BUILD_TYPE}` being set, but for multi-config generators like Visual Studio `${CMAKE_BUILD_TYPE}` is ignored and most users (and IDEs) don't bother setting it. **Description of changes:** 1) Use `$<CONFIG>` generator expressions, instead of checking `${CMAKE_BUILD_TYPE}`, to support multi-config generators like Visual Studio. See: https://cmake.org/cmake/help/v3.22/manual/cmake-buildsystem.7.html#build-configurations. 2) Deprecate ~STATIC_CRT~ option, replace with `AWS_STATIC_MSVC_RUNTIME_LIBRARY=OFF|ON`. - The old option name was confusing, since we refer to our codebase as "the CRT", but this option referred to Microsoft's C runtime library.
Change SKIP code value to reduce the chance of clashing (awslabs#1055)
Intel Vtune tracing integration (awslabs#1050) Co-authored-by: Michael Graeb <graebm@amazon.com>
Simplify error handling in XML API - BREAKING CHANGE (awslabs#1043) **Issue:** It's hard to report errors with the current API. Errors are being accidentally ignored, and some errors are never checked (perhaps because it was too much effort?). **Diagnosis:** The current callback returns `bool` of whether to continue parsing, rather than our typical `int/AWS_OP_SUCCESS/aws_raise_error()` [error handling](https://github.com/awslabs/aws-c-common/blob/b1ef77c1790a8776b58ae5ae57f90e9534b78991/README.md#error-handling). This seems like a simple design. But the inconsistency in return type leads to errors being [mistakenly swallowed](awslabs/aws-c-s3#330 (comment)). And it makes it hard when you do want to "bubble up" an error from the callback. Callbacks needs to store a custom `error_code` in their `user_data` to report an error. Most callbacks never bothered to do this, maybe because it was extra work? **Description of changes:** - XML traversal callback returns `int` instead of `bool`. - If a callback fails, the whole parse() fails. - You can no longer stop parsing without causing failure. But in nearly all use-cases we were stopping due to error. I found 1 case where we stopped because we found what we were looking for. But in this case, it didn't really hurt to continue parsing. The reduced complexity seemed worth the change. - Remove ~aws_xml_parser_new(), aws_xml_parser_destroy(), aws_xml_parser_parse()~, replace with `aws_xml_parse()`. - The new() and destroy() calls were unnecessary. Removing them simplifies use. - `aws_xml_node_get_name()` just returns `aws_byte_cursor()`, instead of ~int~ - This can't fail. Changing the signature simplifies use. - Raise `AWS_ERROR_INVALID_XML` instead of ~AWS_ERROR_MALFORMED_INPUT_STRING~ - This change is more wishy-washy. It seemed useful to get this new, more specific, error code if it bubbling up from deep within some larger operation, like an S3 meta-request. **API BREAK:** We don't know any external uses of this API, so it seems safe to change. The API is only intended for internal use by the aws-c libraries, which are being fixed up now. This API was quickly written as private code in aws-c-auth (awslabs/aws-c-auth#40), then moved to public in aws-c-common (awslabs#674) when aws-c-s3 also needed to parse XML. The fact that it was originally private is why this API didn't get more scrutiny originally.
Remove dangling symlink in CMBC proofs (awslabs#1031) The templates submodule was removed in awslabs#919 so this symlink is now dangling.
Fix warnings in public headers (awslabs#998) Co-authored-by: Waqar Ahmed Khan <waahm7@gmail.com>
Tolerate unintialized list in array_list_clear (awslabs#1021)
Tolerate unintialized list in aws_array_list_length (awslabs#1019)
PreviousNext