-
-
Notifications
You must be signed in to change notification settings - Fork 32.8k
zlib: reduce code duplication #57810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -607,9 +607,11 @@ class CompressionStream : public AsyncWrap, public ThreadPoolWork { | |
return AllocForBrotli(data, real_size); | ||
} | ||
|
||
static constexpr size_t reserveSizeAndAlign = | ||
std::max(sizeof(size_t), alignof(max_align_t)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Isn't this just always There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no, if you don't care about unaligned accesses you could set it to 1. There is no architecture actually doing that though. But this is just addressing a comment made by @Flarna. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. see #57727 (comment) as well, this just removes a double definition of a constant, there is nothing special about this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm confused, you're saying "no" here but the comment you linked seems to unambiguously answer my question with "yes"? 🙂 Either way, I don't really care, but I'm not sure that this code is clearer because when reading it it really should raise a question of "why are we defining this constant as the maximum of two values where one is always clearly larger than the other" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not aware of any platform where There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @addaleax Just make a large struct or class and you can easily check that the alignment of it is less then its size. This code is simply doing the right thing, it will make sure there is enough space and it is still aligned. In theory alignof(max_align_t) can be less than sizeof(size_t). In practice it won't, but the compiler will optimize it out anyway. |
||
|
||
static void* AllocForBrotli(void* data, size_t size) { | ||
constexpr size_t offset = std::max(sizeof(size_t), alignof(max_align_t)); | ||
size += offset; | ||
size += reserveSizeAndAlign; | ||
CompressionStream* ctx = static_cast<CompressionStream*>(data); | ||
char* memory = UncheckedMalloc(size); | ||
if (memory == nullptr) [[unlikely]] { | ||
|
@@ -618,16 +620,15 @@ class CompressionStream : public AsyncWrap, public ThreadPoolWork { | |
*reinterpret_cast<size_t*>(memory) = size; | ||
ctx->unreported_allocations_.fetch_add(size, | ||
std::memory_order_relaxed); | ||
return memory + offset; | ||
return memory + reserveSizeAndAlign; | ||
} | ||
|
||
static void FreeForZlib(void* data, void* pointer) { | ||
if (pointer == nullptr) [[unlikely]] { | ||
return; | ||
} | ||
CompressionStream* ctx = static_cast<CompressionStream*>(data); | ||
constexpr size_t offset = std::max(sizeof(size_t), alignof(max_align_t)); | ||
char* real_pointer = static_cast<char*>(pointer) - offset; | ||
char* real_pointer = static_cast<char*>(pointer) - reserveSizeAndAlign; | ||
size_t real_size = *reinterpret_cast<size_t*>(real_pointer); | ||
ctx->unreported_allocations_.fetch_sub(real_size, | ||
std::memory_order_relaxed); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% sure but I think this doesn't fit the code style, it seems inconsistent already in the codebase
Quite some places use a
k
prefix, others use define style (e.g.RESERVER_SIZE_AND_ALIGN
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that sounds like pure evil, are you suggestion to make it a #define in a c++ project?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I didn't mean to convert it to a define,
constexpr
is perfectly fine and the way to go.It's just about nitpicking about the name. Unfortunatelly cpp-style-guide doesn't clarify this.
Looking into code I found several places using the
k
prefix (e.g. here), and some usingALL_UPPER_CASE
(e.g. here).Personally I prefer the proposed
k
prefix.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, I guess I can rename it to reserveSizeAndAlign_, although rather ugly, that seems to comply with the code standard / general implementations. I doubt I have ever seen a k though, unless in kilo. Why would you prefer a k there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know where the
k
prefix comes from but it is used at quite some places in this repo for constants. Therefore I see it as helpful as it jumps into my mind that this is a constant. Would I go fork
prefix in my personal repo: no - but thats a different topic.The casing you use now is used nowhere in this repo for constants.
Aynhow, all I'm asking is to try to follow the existing style8s). I guess
kReserveSizeAndAlign
,RESERVE_SIZE_AND_ALIGN
,reserver_size_and_align
(and maybe more) follow exisiting styles.