ziglang/zig
261
6.0k
Fork
You've already forked zig
772

zig libc: export fdiml and fdimf #31759

Merged
andrewrk merged 3 commits from badayvedat/zig:refactor/libzigc-fdiml-fdimf into master 2026年04月16日 01:11:08 +02:00
Contributor
Copy link

reimplements fdiml and fdimf in libzigc and removes from from musl and mingw libc. For testing I run

$ stage3/bin/zig build test-libc -Dlibc-test-path=../../libc-test -Dtest-filter=fdiml -fqemu -fwasmtime --summary all

I followed these PRs for reference:

Contributes to: #30978

reimplements `fdiml` and `fdimf` in `libzigc` and removes from from musl and mingw libc. For testing I run ```bash $ stage3/bin/zig build test-libc -Dlibc-test-path=../../libc-test -Dtest-filter=fdiml -fqemu -fwasmtime --summary all ``` I followed these PRs for reference: - https://codeberg.org/ziglang/zig/pulls/31434 - https://codeberg.org/ziglang/zig/pulls/31188 - https://codeberg.org/ziglang/zig/pulls/31503 - https://codeberg.org/ziglang/zig/pulls/31516 Contributes to: https://codeberg.org/ziglang/zig/issues/30978
libzigc: fdiml
All checks were successful
ci / x86_64-freebsd-release (pull_request) Successful in 45m59s
ci / x86_64-windows-release (pull_request) Successful in 1h10m36s
ci / x86_64-windows-debug (pull_request) Successful in 1h10m40s
ci / powerpc64le-linux-release (pull_request) Successful in 1h21m38s
ci / aarch64-macos-release (pull_request) Successful in 1h28m12s
ci / aarch64-linux-release (pull_request) Successful in 1h30m52s
ci / s390x-linux-release (pull_request) Successful in 1h32m25s
ci / aarch64-macos-debug (pull_request) Successful in 1h48m39s
ci / x86_64-linux-release (pull_request) Successful in 1h54m21s
ci / x86_64-netbsd-release (pull_request) Successful in 35m7s
ci / x86_64-linux-debug (pull_request) Successful in 1h15m55s
ci / x86_64-netbsd-debug (pull_request) Successful in 45m56s
ci / s390x-linux-debug (pull_request) Successful in 2h22m27s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 2h23m33s
ci / aarch64-linux-debug (pull_request) Successful in 2h41m45s
ci / loongarch64-linux-release (pull_request) Successful in 1h58m22s
ci / loongarch64-linux-debug (pull_request) Successful in 2h49m18s
ci / x86_64-freebsd-debug (pull_request) Successful in 41m9s
ci / x86_64-openbsd-release (pull_request) Successful in 48m45s
ci / x86_64-openbsd-debug (pull_request) Successful in 55m56s
ci / powerpc64le-linux-debug (pull_request) Successful in 4h35m42s
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / aarch64-freebsd-debug (pull_request) Successful in 4h2m16s
ci / aarch64-freebsd-release (pull_request) Successful in 3h3m42s
ci / aarch64-netbsd-debug (pull_request) Successful in 4h40m2s
ci / aarch64-netbsd-release (pull_request) Successful in 2h42m28s
d2fed9672f
mihael left a comment
Copy link

Glancing at this, all the fdim functions have the same implementations, except for the types in the function signature. You could easily generalize it and then pass the type for specializations:

fnfdimGeneric(comptimeT:type,x:T,y:T)callconv(.c)T{if(math.isNan(x))returnx;if(math.isNan(y))returny;if(x>y)returnx-y;return0;}fnfdim(x:f64,y:f64)callconv(.c)f64{returnfdimGeneric(f64,x,y);}fnfdimf(x:f32,y:f32)callconv(.c)f32{returnfdimGeneric(f32,x,y);}fnfdiml(x:c_longdouble,y:c_longdouble)callconv(.c)c_longdouble{returnfdimGeneric(c_longdouble,x,y);}

Even though the implementation is straightforward, it'd also be nice to have some tests since we're not just calling well-tested std code.

Glancing at this, all the `fdim` functions have the same implementations, except for the types in the function signature. You could easily generalize it and then pass the type for specializations: ```zig fn fdimGeneric(comptime T: type, x: T, y: T) callconv(.c) T { if (math.isNan(x)) return x; if (math.isNan(y)) return y; if (x > y) return x - y; return 0; } fn fdim(x: f64, y: f64) callconv(.c) f64 { return fdimGeneric(f64, x, y); } fn fdimf(x: f32, y: f32) callconv(.c) f32 { return fdimGeneric(f32, x, y); } fn fdiml(x: c_longdouble, y: c_longdouble) callconv(.c) c_longdouble { return fdimGeneric(c_longdouble, x, y); } ``` Even though the implementation is straightforward, it'd also be nice to have some tests since we're not just calling well-tested `std` code.
Author
Contributor
Copy link

i thought the same, but i am not really sure what is zig's guide on that, and i am leaning more on that 3 functions due to "explicit is better than implicit".

similar with the tests, the existing libc-test should be quite extensive not sure why having additional tests.

i thought the same, but i am not really sure what is zig's guide on that, and i am leaning more on that 3 functions due to "explicit is better than implicit". similar with the tests, the existing libc-test should be quite extensive not sure why having additional tests.
Contributor
Copy link

@badayvedat wrote in #31759 (comment):

i thought the same, but i am not really sure what is zig's guide on that, and i am leaning more on that 3 functions due to "explicit is better than implicit".

similar with the tests, the existing libc-test should be quite extensive not sure why having additional tests.

"Explicit is better than implicit" refers to avoiding implied behavior such as automatic memory allocations, implied instantiations of buffers, or hiding dynamic dispatch behind keywords such as interface. The idea is that you can just read the code and have a pretty good idea what goes on at low level, without needing to know too much about the internals of the language (the flipside is that it forces you to learn about this stuff other languages usually abstract away, but you also get total control).

Using generics doesn't clash with that and it's pretty common, you're still explicit about the types you're passing. A type is a type like any other. What Zig didn't do is abstract away generics with some special syntax (which would mean there's some extra, implied behaviour like monomorphization behind that special syntax during compile time).

As for tests, I'm referring to this:

  • Otherwise, implement and export the function in an appropriate place in lib/c, add tests, and delete the implementation from all of the static libcs we bundle with Zig.

  • It may not necessarily be meaningful to add tests if the function just trivially forwards to a Zig std function that is already thoroughly tested.

My understanding is we're also trying to have good test coverage in Zig code as well as using libc-test, and the second bulletpoint clears up that adding tests isn't necessary if the libzigc trivially calls well-tested std implementations.
And fdim implementations are pretty trivial themselves, but personally I'd add some tests.

There's also comments like this which differentiate between libc tests and Zig unit tests. So, that's my impression from having observed the work on libzigc so far.

@badayvedat wrote in https://codeberg.org/ziglang/zig/pulls/31759#issuecomment-12656193: > i thought the same, but i am not really sure what is zig's guide on that, and i am leaning more on that 3 functions due to "explicit is better than implicit". > > similar with the tests, the existing libc-test should be quite extensive not sure why having additional tests. "Explicit is better than implicit" refers to avoiding implied behavior such as automatic memory allocations, implied instantiations of buffers, or hiding dynamic dispatch behind keywords such as `interface`. The idea is that you can just read the code and have a pretty good idea what goes on at low level, without needing to know too much about the internals of the language (the flipside is that it forces you to learn about this stuff other languages usually abstract away, but you also get total control). Using generics doesn't clash with that and it's pretty common, you're still explicit about the types you're passing. A `type` is a type like any other. What Zig didn't do is abstract away generics with some special syntax (which would mean there's some extra, implied behaviour like monomorphization behind that special syntax during compile time). As for tests, I'm referring to [this](https://codeberg.org/ziglang/zig/issues/30978#issue-3349482): > - Otherwise, implement and export the function in an appropriate place in lib/c, add tests, and delete the implementation from all of the static libcs we bundle with Zig. > > - It may not necessarily be meaningful to add tests if the function just trivially forwards to a Zig std function that is already thoroughly tested. My understanding is we're also trying to have good test coverage in Zig code as well as using `libc-test`, and the second bulletpoint clears up that adding tests isn't necessary if the `libzigc` trivially calls well-tested `std` implementations. And `fdim` implementations are pretty trivial themselves, but personally I'd add some tests. There's also comments like [this](https://codeberg.org/ziglang/zig/pulls/31737#issuecomment-12567897) which differentiate between `libc` tests and Zig unit tests. So, that's my impression from having observed the work on `libzigc` so far.
lib/c/math.zig Outdated
@ -52,6 +52,7 @@ comptime {
symbol(&acosf,"acosf");
symbol(&atanf,"atanf");
symbol(&coshf,"coshf");
symbol(&fdiml,"fdiml");
Contributor
Copy link

x86_64-windows-gnu also needs this symbol. The correct if block is (builtin.target.isMinGW() and @sizeOf(f64) != @sizeOf(c_longdouble)) or builtin.target.isMuslLibC() or builtin.target.isWasiLibC().

`x86_64-windows-gnu` also needs this symbol. The correct `if` block is `(builtin.target.isMinGW() and @sizeOf(f64) != @sizeOf(c_longdouble)) or builtin.target.isMuslLibC() or builtin.target.isWasiLibC()`.
Author
Contributor
Copy link

thank you! addressed it

thank you! addressed it

"Explicit is better than implicit"

What are you quoting?

> "Explicit is better than implicit" What are you quoting?
Author
Contributor
Copy link

thanks for the comments @mihael !
@andrewrk it is not an exact quote it was my personal interpretation behind the language's some choices . up further thinking does not seem to be correct 🙂 so I mis-interpreted in some ways.

and regarding the diff, should I move ahead with what @mihael suggested? the comments make more sense compared to current changes but not sure what is the preference there

thanks for the comments @mihael ! @andrewrk it is not an exact quote it was my personal interpretation behind the language's some choices . up further thinking does not seem to be correct 🙂 so I mis-interpreted in some ways. and regarding the diff, should I move ahead with what @mihael suggested? the comments make more sense compared to current changes but not sure what is the preference there
refactor: address review comments & refactor into a generic fn
All checks were successful
ci / aarch64-macos-release (pull_request) Successful in 1h3m16s
ci / x86_64-netbsd-release (pull_request) Successful in 48m17s
ci / x86_64-netbsd-debug (pull_request) Successful in 1h5m43s
ci / x86_64-freebsd-release (pull_request) Successful in 42m19s
ci / aarch64-macos-debug (pull_request) Successful in 2h33m3s
ci / aarch64-linux-release (pull_request) Successful in 1h28m59s
ci / x86_64-openbsd-release (pull_request) Successful in 1h1m44s
ci / x86_64-openbsd-debug (pull_request) Successful in 1h13m22s
ci / x86_64-linux-debug (pull_request) Successful in 1h9m10s
ci / x86_64-windows-debug (pull_request) Successful in 1h21m12s
ci / x86_64-windows-release (pull_request) Successful in 1h17m48s
ci / aarch64-linux-debug (pull_request) Successful in 2h43m41s
ci / s390x-linux-release (pull_request) Successful in 1h49m12s
ci / s390x-linux-debug (pull_request) Successful in 3h29m53s
ci / x86_64-linux-release (pull_request) Successful in 3h37m11s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 3h44m4s
ci / powerpc64le-linux-release (pull_request) Successful in 1h33m57s
ci / powerpc64le-linux-debug (pull_request) Successful in 4h55m5s
ci / x86_64-freebsd-debug (pull_request) Successful in 47m7s
ci / loongarch64-linux-debug (pull_request) Successful in 3h30m12s
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / loongarch64-linux-release (pull_request) Successful in 1h54m31s
ci / aarch64-freebsd-debug (pull_request) Successful in 4h7m35s
ci / aarch64-freebsd-release (pull_request) Successful in 3h5m50s
ci / aarch64-netbsd-debug (pull_request) Successful in 3h42m57s
ci / aarch64-netbsd-release (pull_request) Successful in 2h46m48s
a6f5b5d5a2
andrewrk left a comment
Copy link

Looks good, thank you

Looks good, thank you
andrewrk changed title from (削除) refactor/libzigc-fdiml-fdimf (削除ここまで) to zig libc: export fdiml and fdimf 2026年04月16日 01:11:41 +02:00
badayvedat deleted branch refactor/libzigc-fdiml-fdimf 2026年04月25日 20:04:21 +02:00
Sign in to join this conversation.
No reviewers
Labels
Clear labels
abi/f32
abi/ilp32
abi/sf
accepted
This proposal is planned.
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
The web application for interactive documentation and generation of its assets.
backend/c
The C backend outputs C source code.
backend/llvm
The LLVM backend outputs an LLVM bitcode module.
backend/self-hosted
The self-hosted backends produce machine code directly.
binutils
Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.
breaking
Implementing this issue could cause existing code to no longer compile or have different behavior.
build system
The Zig build system - zig build, std.Build, the build runner, and package management.
debug info
An issue related to debug information (e.g. DWARF) produced by the Zig compiler.
docs
An issue with documentation, e.g. the language reference or standard library doc comments.
error message
This issue points out an error message that is unhelpful and should be improved.
frontend
Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.
fuzzing
An issue related to Zig's integrated fuzz testing.
incremental
Reuse of internal compiler state for faster compilation.
lib/c
This issue relates to Zig's libc implementation and/or vendored libcs.
lib/compiler-rt
This issue relates to Zig's compiler-rt library.
lib/cxx
This issue relates to Zig's vendored libc++ and/or libc++abi.
lib/std
This issue relates to Zig's standard library.
lib/tsan
This issue relates to Zig's vendored libtsan.
lib/ubsan-rt
This issue relates to Zig's ubsan-rt library.
lib/unwind
This issue relates to Zig's vendored libunwind.
linking
Zig's integrated object file and incremental linker.
miscompilation
The compiler reports success but produces semantically incorrect code.
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
This issue suggests language modifications. If it also has the "accepted" label then it is planned.
release notes
This issue or pull request should be mentioned in the release notes.
testing
This issue is related to testing the compiler, standard library, or other parts of Zig.
zig cc
Zig as a drop-in C-family compiler.
zig fmt
The Zig source code formatter.
zig reduce
The Zig source code reduction tool.
bounty
https://ziglang.org/news/announcing-donor-bounties
bug
Observed behavior contradicts documented or intended behavior.
contributor-friendly
This issue is limited in scope and/or knowledge of project internals.
downstream
An issue with a third-party project that uses this project.
enhancement
Solving this issue will likely involve adding new logic or components to the codebase.
infra
An issue related to project infrastructure, e.g. continuous integration.
optimization
A task to improve performance and/or resource usage.
question
No questions on the issue tracker; use a community space instead.
regression
Something that used to work in a previous version stopped working
upstream
An issue with a third-party project that this project uses.
use case
Describes a real use case that is difficult or impossible, but does not propose a solution.
No labels
abi/f32
abi/ilp32
abi/sf
accepted
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
backend/c
backend/llvm
backend/self-hosted
binutils
breaking
build system
debug info
docs
error message
frontend
fuzzing
incremental
lib/c
lib/compiler-rt
lib/cxx
lib/std
lib/tsan
lib/ubsan-rt
lib/unwind
linking
miscompilation
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
release notes
testing
zig cc
zig fmt
zig reduce
bounty
bug
contributor-friendly
downstream
enhancement
infra
optimization
question
regression
upstream
use case
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ziglang/zig!31759
Reference in a new issue
ziglang/zig
No description provided.
Delete branch "badayvedat/zig:refactor/libzigc-fdiml-fdimf"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?