public/browser
1
0
Fork 0
mirror of https://github.com/lightpanda-io/browser.git synced 2026-02-04 22:43:48 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity

Move more asserts to custom asserter.

Browse Source 
Deciding what should be an lp.assert, vs an std.debug.assert, vs a debug-only
assert is a little arbitrary.

debug-only asserts, guarded with an `if (comptime IS_DEBUG)` obviously avoid the
check in release and thus have a performance advantage. We also use them at
library boundaries. If libcurl says it will always emit a header line with a
trailing \r\n, is that really a check we need to do in production? I don't think
so. First, that code path is checked _a lot_ in debug. Second, it feels a bit
like we're testing libcurl (in production!)..why? A debug-only assertion should
be good enough to catch any changes in libcurl.
This commit is contained in:
Karl Seguin
2026-01-19 09:12:16 +08:00
parent 9b000a002e
commit a6e7ecd9e5
31 changed files with 204 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/http/errors.zig
View File

@@ -19,6 +19,8 @@
const std = @import("std");
const c = @import("Http.zig").c;
const IS_DEBUG = @import("builtin").mode == .Debug;
pub const Error = error{
UnsupportedProtocol,
FailedInit,
@@ -109,7 +111,9 @@ pub const Error = error{
};
pub fn fromCode(code: c.CURLcode) Error {
std.debug.assert(code != c.CURLE_OK);
if (comptime IS_DEBUG) {
std.debug.assert(code != c.CURLE_OK);
}
return switch (code) {
c.CURLE_UNSUPPORTED_PROTOCOL => Error.UnsupportedProtocol,
@@ -218,7 +222,9 @@ pub const Multi = error{
};
pub fn fromMCode(code: c.CURLMcode) Multi {
std.debug.assert(code != c.CURLM_OK);
if (comptime IS_DEBUG) {
std.debug.assert(code != c.CURLM_OK);
}
return switch (code) {
c.CURLM_BAD_HANDLE => Multi.BadHandle,