Go programs can indeed interact with C code through Cgo, which allows Go to call C functions directly. When using Cgo, just import the pseudo-package "C" and embed C code in the comments above the import line, such as including C function definitions and calling them. In addition, external C libraries can be linked by specifying link flags such as #cgo LDFLAGS. However, there are many issues to pay attention to when using Cgo: 1. Memory management needs to be processed manually and cannot rely on Go garbage collection; 2. Go types may not match C types, and types such as C.int should be used to ensure consistency; 3. Multiple goroutine calls to non-thread-safe C libraries may cause concurrency problems; 4. There is performance overhead in calling C code, and the number of calls across language boundaries should be reduced. The disadvantages of Cgo also include improved construction complexity, difficulty in cross-compilation, increased binary volume and loss of some security guarantees provided by Go. Cgo should be used when you need to call existing C libraries, access low-level system functions, or embed into C/C applications, and should be avoided when paying attention to cross-platform compatibility, binary size, or target environment limitations (such as WASM, mobile). Setting CGO_ENABLED=0 can disable Cgo to test whether the pure Go implementation is feasible. Overall, Cgo is very useful in specific scenarios, but introduces additional complexity, and whether it is adopted depends on the specific requirements.

Go programs can indeed interact with C code using a feature called Cgo , which allows Go to call C functions directly. It's especially useful when you need to interface with existing C libraries or use system-level APIs that aren't available in pure Go.

But like any tool, it comes with trade-offs — performance, portability, and complexity can all be affected. Let's break down how it works and what to watch out for.

How to Use Cgo to Call C Code from Go

Using Cgo is fairly straightforward. You just import the pseudo-package "C" and embedded C code inside special comments above the import line.

Here's a simple example:

 /*
#include <stdio.h>

void saysHi() {
    printf("Hello from C!\n");
}
*/
import "C"

func main() {
    C.sayHi()
}

This will compile and run the embedded C function sayHi() from Go.

You can also link to external C libraries by specifying them with comments like:

 /*
#cgo LDFLAGS: -lmyclib
#include "myclib.h"
*/
import "C"

Then call functions declared in those headers as if they were part of the C package.

Common Pitfalls and Practical Tips

When working with Cgo, there are several gotchas to be aware of:

• Memory management : Go uses garbage collection, but C doesn't. If you allocate memory in C (eg, via malloc ), you're responsible for freeing it. Don't expect Go to do it automatically.

• Type mismatches : Go types don't always map cleanly to C types. For example, int sizes might different across platforms. Use types like C.int , C.size_t , etc., to stay safe.

• Concurrency issues : Calling C from multiple goroutines can cause problems unless the C library is thread-safe. Some C libraries aren't designed for concurrent access at all.

• Performance overhead : Calling into C isn't free. There's a small cost every time you cross the boundary between Go and C. Avoid doing this in tight loops or high-frequency paths unless necessary.

A good rule of thumb is to minimize the number of transitions between Go and C. Do more work on one side before crossing over.

Trade-offs of Using Cgo

While Cgo is powerful, it introduces several downsides:

• Build complexity increases : With Cgo, your build now depends on a C compiler and possible platform-specific headers or libraries. This complicates CI/CD pipelines and deployment environments.

• Cross-compilation becomes harder : Normally, Go compiles binaries for other platforms easily. But with Cgo enabled, cross-compiling requires matching C libraries for the target architecture — which isn't always easy or clean.

• Binary size grows : Linking to C libraries often pulls in extra dependencies, making your final binary larger than a pure Go version.

• Loss of some Go guarantees : Go's runtime helps avoid certain bugs (like buffer overflows). Once you start calling C code, those protections no longer apply — so you're back to worrying about null points, memory leaks, and undefined behavior.

If possible, prefer using Go-only alternatives, especially if you're targeting mobile, WASM, or environments where C support is limited.

When Should You Use Cgo?

Use Cgo when:

• You must interface with an existing C library (eg, OpenSSL, libpng).
• You need to access low-level OS features not exposed in Go standard libraries.
• You're embedding Go into a larger C/C application.

Avoid Cgo when:

• Cross-platform compatibility is critical.
• Binary size or simplicity matters (eg, CLI tools, containers).
• You want to compile to WebAssembly or mobile targets.

It's worth noting that you can conditionally disable Cgo by setting CGO_ENABLED=0 . Doing this forces your code to fall back to pure Go implementations, which can help test whether your project truly needs Cgo.

So yes, Go can talk to C through Cgo, and it works well enough for many use cases — but it adds complexity. Whether that's worth it depends on your specific situation.

The above is the detailed content of How can Go programs interact with C code using Cgo? What are the trade-offs?. For more information, please follow other related articles on the PHP Chinese website!