DEV Community: L Djohari

The Guide to Safe & Modern C Memory Allocation Strategy

L Djohari — Sun, 07 Sep 2025 22:46:24 +0000

C gives you power and footguns to shoot yourself in the foot if you use it wrong.
This note standardizes how we allocate, initialize, copy, and free memory and strings in a portable, safe way (ISO C + small, documented helpers).
We avoid undefined behavior (UB), platform gotchas, and “hidden” memory allocation traps.

0) TL;DR Rules

Allocation ≠ Initialization. Never read uninitialized memory.
Prefer calloc for structs; else malloc + explicit init (memset or field-wise).
After realloc, init the new tail (bytes beyond old size).
Never use raw strdup in our codebase. Use xstrdup/xstrndup below.
Centralize lifetime with create/destroy APIs. Document ownership (borrowed vs owned).
After free, set pointer to NULL.

1) Core Allocation APIs

Function	Purpose	Initialized?	Must Init?
`malloc(n)`	Allocate `n` bytes (heap)	❌ garbage	✅ memset or assign
`calloc(c,n)`	Allocate `c*n` bytes (heap)	✅ zeroed	❌
`realloc(p,n)`	Resize block `p` to `n` bytes	🔸 partial¹	✅ init new tail
`alloca(n)`	Allocate `n` bytes (stack, auto free)	❌ garbage	✅ memset or assign

¹ realloc: preserves old bytes; new bytes are uninitialized.

Golden rule: Never evaluate memory you didn’t initialize.

2) Safe Allocation Wrappers (ISO C, OOM-fatal, OOM-NULL with *_try variants)

Use these consistent behavior:

#ifndef SAFE_ALLOC_H
#define SAFE_ALLOC_H

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <limits.h>

/* Abort-on-OOM (Out of Memory) policy (common for daemons/servers).
   If you need non-fatal OOM, use *_try variants separately. */

static inline void *xmalloc(size_t size) {
    void *p = malloc(size);
    if (!p && size) {
        fprintf(stderr, "FATAL: malloc(%zu) failed\n", size);
        abort();
    }
    return p;
}

static inline void *xmalloc_try(size_t size) {
    void *p = malloc(size);
    if (!p && size) {
        return NULL;
    }
    return p;
}

static inline void *xcalloc(size_t nmemb, size_t size) {
    /* basic overflow guard */
    if (size && nmemb > SIZE_MAX / size) {
        fprintf(stderr, "FATAL: calloc overflow (%zu,%zu)\n", nmemb, size);
        abort();
    }
    void *p = calloc(nmemb, size);
    if (!p && nmemb && size) {
        fprintf(stderr, "FATAL: calloc(%zu,%zu) failed\n", nmemb, size);
        abort();
    }
    return p;
}

static inline void *xcalloc_try(size_t nmemb, size_t size) {
    /* basic overflow guard */
    if (size && nmemb > SIZE_MAX / size) {
        return NULL;
    }
    void *p = calloc(nmemb, size);
    if (!p && nmemb && size) {
        return NULL;
    }
    return p;
}


static inline void *xrealloc(void *ptr, size_t size) {
    void *p = realloc(ptr, size);
    if (!p && size != 0) {
        fprintf(stderr, "FATAL: realloc(%p,%zu) failed\n", ptr, size);
        abort();
    }
    return p;
}

static inline void *xrealloc_try(void *ptr, size_t size) {
    void *p = realloc(ptr, size);
    if (!p && size != 0) {
        return NULL;
    }
    return p;
}

/* Free + NULL 
*  We put scope in here to avoid dangling if-else on non braces statement
*/
#define xfree(p) { if ((p) != NULL) { free(p); p = NULL; } }

/* Bounded str duplicate: must provide valid cstr with NUL-terminate. */
static inline char *xstrdup(const char *s) {
    if (!s) {
        /* Define our policy: duplicate NULL → empty string */
        char *z = xmalloc(1);
        z[0] = '\0';
        return z;
    }
    size_t n = strlen(s);
    /* +1 checked overflow */
    if (n >= SIZE_MAX) {
        fprintf(stderr, "FATAL: xstrdup overflow\n");
        abort();
    }

    char *p = xmalloc(n + 1);
    memcpy(p, s, n + 1); /* includes '\0' */
    return p;
}

/* Bounded str duplicate: copy at most n bytes, n is size-1 (withouth NUL-terminate). */
static inline char *xstrndup(const char *s, size_t n) {
    if (!s) {
        char *z = xmalloc(1);
        z[0] = '\0';
        return z;
    }

    size_t m = 0;

    size_t m = strnlen(s, maxlen);
    if (m >= SIZE_MAX) {
        fprintf(stderr, "FATAL: xstrndup overflow\n");
        abort();
    }

    char *p = xmalloc(m + 1);

    if (m){
        memcpy(p, s, m);
    }

    p[m] = '\0';
    return p;
}

/* Binary memcopy helper. */
static inline void *xmemcpy(const void *src, size_t n) {
    if (!src && n) {
        return NULL;
    }

    void *p = xmalloc(n ? n : 1);
    if (n){ 
        memcpy(p, src, n);
    }

    return p;
}

#endif /* SAFE_ALLOC_H */

Why not use strdup directly?

Our xstrdup checks for overflow and defines behavior for NULL input.
No surprises and consistent with our OOM policy.

3) Initialization Patterns

Structs (configs/contexts)

typedef struct {
    const char *host;
    int         port;
    int         backlog;
    void       *user_data;
} server_config_t;

/* Prefer calloc for zero/NULL defaults */
server_config_t *cfg = xcalloc(1, sizeof *cfg);
cfg->host   = xstrdup("0.0.0.0"); 
cfg->port   = 9000;
cfg->backlog= 256;

/* Or: malloc + memset + field init */
server_config_t *cfg2 = xmalloc(sizeof *cfg2);
memset(cfg2, 0, sizeof *cfg2);
cfg2->port = 9000;

xfree(cfg->host);
xfree(cfg);
xfree(cfg2);

`realloc` tail must be initialized

size_t old_cap = 16, new_cap = 64;
char *buf = xmalloc(old_cap);
/* ...write up to old_cap... */

buf = xrealloc(buf, new_cap);
/* New region [old_cap, new_cap) is garbage → initialize if you will read it */
memset(buf + old_cap, 0, new_cap - old_cap);

4) Ownership Conventions (VERY IMPORTANT)

Define clearly who allocates, who frees.

Borrowed pointer: points to memory we do not free (e.g., literals, caller-owned).
Owned pointer: allocated here, must be freed in destroy.
Copy-on-set: safest—API duplicates input and manages it.

Example API

typedef struct server server_t;

server_t *server_create(void);
void      server_destroy(server_t *s);

int        server_set_host(server_t *s, const char *host); /* copies */
const char*server_get_host(const server_t *s);             /* borrowed */

Implementation:

struct server {
    char  *host;   /* owned */
    int    port;
    size_t backlog;
};

server_t *server_create(void) {
    server_t *s = xcalloc(1, sizeof(server_t));
    s->port = 9000;
    s->backlog = 256;
    return s;
}

int server_set_host(server_t *s, const char *host) {
    char *copy = xstrdup(host);  /* safe */
    xfree(s->host);
    s->host = copy;
    return 0;
}

const char *server_get_host(const server_t *s) {
    return s->host ? s->host : "";
}

void server_destroy(server_t *s) {
    if (!s) return;
    xfree(s->host);
    xfree(s);
}

5) Create/Destroy + Heap Initialization

typedef struct {
    const char *host;
    int         port;
    int         backlog;
    size_t      read_chunk;
} uvsvr_config_t;

uvsvr_config_t uvsvr_config_defaults(void) {
    return (uvsvr_config_t){
        /* AS MOST C Library API always stated if char *p must be allocated, not literal*/
        .host        = xstrdup("0.0.0.0"), 
        .port        = 9000,
        .backlog     = 256,
        .read_chunk  = 16 * 1024,
    };
}

uvsvr_config_t *uvsvr_config_new(void) {
    uvsvr_config_t *p = xmalloc(sizeof *p);
    *p = uvsvr_config_defaults();
    return p;
}

6) Anti-Patterns (Don’t Do These)

Reading before init:

  T *p = xmalloc(sizeof(*p));
  if (p->flag) { /* UB */ }

Assuming realloc clears new bytes.
Freeing borrowed pointers, or leaking owned ones.
Using alloca for large/variable buffers.
Using unsafe string funcs (strcpy, strcat, legacy strncpy).

7) Practical Snippets

Safe formatting

char buf[64];
int n = snprintf(buf, sizeof(buf), "%s", input);
if (n < 0) { /* format error */ }
if ((size_t)n >= sizeof(buf)) { /* truncated */ }

8) Checklist

[ ] Use xcalloc for structs; or xmalloc + memset.
[ ] Always init after malloc/alloca.
[ ] After realloc, init new bytes.
[ ] Use xstrdup/xstrndup (never avoid strdup).
[ ] Centralize lifetime in create/destroy.
[ ] Define ownership in headers.
[ ] xfree after use → pointer = NULL.
[ ] Avoid alloca in production servers.
[ ] Prefer snprintf/memcpy with explicit sizes.

✅ Summary:

malloc/alloca = garbage → must init.
calloc = zeroed defaults.
realloc = old preserved, new garbage.
Use safe wrappers (xmalloc, xcalloc, xrealloc, xstrdup, etc.).
Centralize allocation in create/destroy APIs.
Document the ownership contracts.
This avoids UB, leaks, dangling pointers, and footguns/shooting yourself in the foot.

The Guide into Strings in C for Dev who wanted to learns C - Clear Rules, Mutation, Reassignment & Ownership, No Surprises

L Djohari — Sun, 07 Sep 2025 18:40:52 +0000

C++ has std::string with RAII, move semantics, and safe copying.
C has only pointers and arrays. You are responsible for allocation, mutation, reassignment, and freeing. You own lifetime and memory.
That’s where most bugs and shot in the foot happen in C.

This guide is for C++ or migrated from any languages who want safe, modern C string rules without ambiguity and no surprises.

1. The Three Faces of Strings

Form	Storage	Can change contents?	Can reassign pointer?	Need `free`?
`const char *p = "abc";`	literal	❌ (read-only)	✅ yes	❌ no
`char buf[16] = "abc";`	array	✅ (in place)	❌ (arrays not assignable)	❌ no
`char *p = xstrdup("abc");`	heap	✅ (if capacity fits)	✅ yes	✅ yes

➡️ Rules of thumb:

Literal: borrowed, immutable, lives forever.
Array: embedded, mutable, no free.
Heap pointer: owned, mutable, must free.
char *p: In most C API DO NOT ASSIGN STRING LITERAL if you found field char* p as this is marked as UB.
Use C library like sds if you don't want to handle string manually.

2. Null Terminators

Literals: always null-terminated.
Arrays: must have room for \0 .
Heap strings: always allocate +1 for terminator.

✅ Always use snprintf for bounded, safe writes:

char buf[16];
snprintf(buf, sizeof buf, "%s", "127.0.0.1");  // auto NUL

3. Do You Need to `free` Before Changing?

Case	Action	Free first?
Array `char buf[N]`	overwrite in place	❌ never
Pointer → literal/borrowed	reassign pointer	❌ never
Pointer → heap (owned)	overwrite (fits cap)	❌ no
Pointer → heap (owned)	replace (new alloc)	✅ yes

➡️ If unsure about capacity → safest is always:

free(p);
p = xstrdup(new_value);

4. Helper functions

xstrdup (unbounded-length)

Note: xstrdup(str) is my custom function to handle copy-on-set when size is unknown. You must ensured if string is valid c-string with \0 terminator, otherwise it is an UB.

#include <stdlib.h>
#include <string.h>
#include <errno.h>

/* C-string duplicate:
   - s == NULL -> returns owned "".
   - MUST BE VALID c-string with \0 terminated (caller’s contract).
*/
static inline char *xstrdup(const char *s) {
    if (!s) { 
        char *z = malloc(1); 
        if (!z){
            return NULL; 
        } 
        z[0] = '\0'; return z; 
    }

    size_t n = strlen(s);
    char *p = malloc(n + 1);

    if (!p){ 
        return NULL;
    }

    memcpy(p, s, n + 1);
    return p;
}

xstrndup (bounded-length)

#include <stdlib.h>
#include <string.h>
#include <limits.h>

/* Policy: NULL or maxlen==0 -> return an owned empty string */
static inline char *xstrndup(const char *s, size_t maxlen) {

    if (s == NULL || maxlen == 0) {
        char *z = malloc(1);
        if (!z) {
            return NULL;
        }
        z[0] = '\0';
        return z;
    }

    /* Guard (maxlen + 1) overflow */
    if (maxlen == SIZE_MAX) {
        return NULL;
    }

    size_t n = strnlen(s, maxlen);

    char *p = malloc(n + 1);
    if (!p) {
        return NULL;
    }

    if (n) {
        memcpy(p, s, n);
    }

    p[n] = '\0';
    return p;
}

5. Practical Cases

A) Pointer to literal (DO NOT USE)

This pattern you must avoid. As per most C API Contract are not allowed this pattern because it will introduce confusion when freeing the memory.

char *p = "0.0.0.0";    // borrowed literal
p = "127.0.0.1";        // ✅ reassign to another literal
// p[0] = '1';          // ❌ UB: can't modify literal
// free(p);             // ❌ UB: don't free literals

B) Literal first, then reassigned to owned copy

This pattern must be to avoid declaring char *p with literal string at first place, but it is safe.

char *p = "0.0.0.0";    // starts as borrowed literal
p = xstrdup(p); // ✅ now heap-owned, must free later
if(p){
    free(p); // ✅ now heap-owned, must free late
    p = NULL;
}

Key point: after reassignment, ownership changes → now you mus t manage lifetime.

C) Array inside struct

struct S { char host[16]; } s = {0};
snprintf(s.host, sizeof(s.host), "%s", "0.0.0.0");
snprintf(s.host, sizeof(s.host), "%s", "127.0.0.1");  // ✅ overwrite in place
// never free, buffer belongs to struct

D) Owned pointer inside struct (copy-on-set)

struct S { char *host; } s = {0};
s.host = xstrdup("0.0.0.0");

char *tmp = xstrdup("127.0.0.1");
free(s.host);
s.host = tmp;

free(s.host);
s.host = NULL;

E) Owned pointer (mutate in place with capacity)

char *p = malloc(64);
snprintf(p, 64, "%s", "0.0.0.0");
snprintf(p, 64, "%s", "127.0.0.1");  // ✅ fits
free(p);
p = NULL;

F) Start as literal, then copy, then replace

char *p = "init";          // literal, borrowed
p = xstrdup(p);            // now owned heap copy
replace_owned_string(&p, "newvalue"); // frees + assigns safely
free(p);
p = NULL;

6. Expanded Bug Cases to Avoid

Bug	Bad Code	Fix
Modify literal	`char *p="abc"; p[0]='A';`	Use `char buf[]="abc";` or `xstrdup("abc")`
Free literal	`char *p="abc"; free(p);`	Never free literals
Double free	`free(p); free(p);`
Use-after-free	`free(p); p = NULL; printf("%s", p);`	Always set to NULL, check before use
Buffer overflow	`strcpy(buf,"longstring");`	Use `snprintf(buf,sizeof buf,"%s",src)`
Uninit read	`char *p=malloc(16); if(p[0]=='a')...`	`calloc` or `memset` before read
Realloc UB	`p=realloc(p,new); use(p+old..)`	Always `memset` the new region

7. API Pattern: Copy-on-Set

void replace_owned_string(char **dst, const char *src) {
    char *copy = xstrdup(src);
    free(*dst);
    *dst = copy;
}

Usage:

struct S { char *host; } s = {0};
replace_owned_string(&s.host, "0.0.0.0");
replace_owned_string(&s.host, "127.0.0.1");
free(s.host);
s.host = NULL;

8. Choosing Array vs Pointer

Array (char field[N]): fixed-size protocol fields, ISO8583 Data Elements, IPv4, timestamps.
Pointer (char *field): unbounded input, user-provided data.

➡️ Arrays = simpler, no free.
➡️ Pointers = flexible, but you must free or replace carefully.

9. Quick Checklist

Use C library like sds if you don't want to handle string manually.
NOT use literal on char* p to avoid confusion during free().
Literals: reassign pointer only; no mutate/free.
Arrays: mutate in place with snprintf; no free.
Heap-owned: mutate if fits; else free old + copy new.
If unsure always replace_owned_string.
After free() set pointer NULL.
Never evaluate uninitialized memory.

✅ Summary

As per most C API Standard, DO NOT use literal on char* p to avoid confusion during free().
char *p = "value"; → pointer to literal (borrowed).
Reassigning to another literal = fine.
Reassigning to xstrdup("...") = now owned → must free.
Arrays are safe, fixed buffers.
Heap pointers need manual lifetime control.
Copy-on-set pattern keeps your code boring and safe.

Series I: CMake & C++17 Quick Started

L Djohari — Sat, 30 Nov 2024 16:59:29 +0000

Starting modern C++ development is quite a challenging journey. This series aims to demystify Modern C++17 Development with CMake Project.

I'd like to thanks to my mentor back in 2004, if I didn't met my mentor back in 2004 I might be wouldn't knows best-practices on how to develop cross-platform C++.

From him i got invaluable hands-on experiences to use right approaches & right tools for right jobs, and one of them is CMake.

Series I: CMake & C++17 Quick Started

In this first part of the series, we will focus on:

C++17 Key Features
Understanding CMake as a C++ Project Build Tool.

You can skip to next series to get down to business quick.

In Next Series, we will cover:

Installing the prerequisite software to develop and compile Modern C++17 with CMake on Linux/WSL2 (Windows Subsystem for Linux 2).
Integrating Visual Studio Code (VS Code) for CMake C++17 Project Development.
Writing C++17 application and CMakeLists.txt configuration.

Fast-Tracking for Mastering C++17 Development

These are few key-points to fast-tracking your skill to mastering C++17 Development.

The most crucial is the memory management part, once you are mastering this part you can write safe-memory code and feel comfortable with C++.

Understand CMake for C++17 Project.
Mastering Data Types, Value Categories and Object Management—Reference, Pointer, Lvalue, Rvalue, and Move Semantic.
Mastering RAII Principle and Memory Management using smart-pointer.
Mastering struct, class and OOP.
Mastering INCLUDE and PROJECT-STRUCTURE.
Understanding static lib, shared lib and executable compilation.

Why C++17

C++17, finalized in 2017, is a significant evolution in the C++ language. Building on its legacy since 1985, it introduced key features that separate it from predecessors, focusing on productivity, safety, and modern programming needs.

C++17 stands out for higher productivity, high performance without Garbage Collector (GC), combining cutting-edge features with backward compatibility, ensuring smooth transitions while enabling modern development practices.

Key Features of C++17

RAII: RAII (Resource Acquisition Is Initialization) is a C++ design principle where resource management (e.g., memory, file handles) is tied to object lifetime. Resources are acquired in the constructor and released in the destructor, ensuring automatic cleanup, even in case of exceptions.
Smart Pointers: Improved management of dynamic memory with - std::shared_ptr, std::unique_ptr, and std::weak_ptr. Say goodbye to manual memory allocation & de-allocation.
std::string: Yes, C++ has string object. With modern C++ you will be almost never touch *char to handle string.
Generic Programming through Templates: Type Templates, Template Specialization, Variadic Templates and Class Template Argument Deduction (CTAD) offering capabilities comparable to languages like Java, C#, Go, or Rust.
Threading Enhancements: Added parallel execution and better concurrency - with standard library features.
std::optional: Represents optional values to reduce null pointer risks.
std::variant: Type-safe union for storing predefined types.
std::filesystem: Cross-platform API for file system operations.
Parallel Algorithms: Enables parallel execution policies (e.g., - std::for_each).
if constexpr: Compile-time branching for cleaner template code. These allow more complex computations to be performed at compile-time, improving runtime performance.
Improved Lambda Functions: Support for *this capture and default arguments.
Fold Expressions: Simplifies variadic template argument operations.
std::string_view: Lightweight, non-owning string references for efficiency.
Container Improvements: Enhanced containers like std::map::try_emplace and insertion-order guarantees.
Allocator Flexibility: Easy replacement of memory allocators for optimized performance.

CMake as a C++ Build Tool

CMake excels as a flexible and powerful build system generator. It allows developers to define C++ projects precisely, configure compiler settings, manage dependencies, and even execute shell commands—all while generating platform-specific build files like Makefiles, Ninja, or Visual Studio projects.

CMake’s adaptability has made it the go-to tool for modern C++17 development, comparable to Gradle, Maven, or Xcodebuild in other ecosystems.

What is CMake?

CMake enables developers to define every aspect of a C++ project, from build targets and compiler options to testing and installation rules.

It generates build files for tools like Ninja, abstracting platform-specific complexities.

History

Origins (2000): Created by Kitware to support scientific projects like ITK and VTK.
Adoption: Quickly gained traction in open-source and enterprise projects for multi-platform support.
Modern Usage: Used by major projects like LLVM, KDE, Qt, Google Abseil, Google gRPC, and more.

Why Use CMake?

Flexibility in Defining Projects:

Precisely configure targets, source files, and build steps using CMakeLists.txt. To add nested sub-projects, simply use add_subdirectory(<source-folder> <build-dir>). The CMakeLists.txt file serves as the entry point of the project.
Cross-Platform Support:

Generates build files for Linux, Windows, and macOS.
Compile Flags Management:

Easily set compiler flags for standards (e.g., -std=c++17), optimization, warnings, debugging, or application-specific definition flags.
Custom Shell Commands:

Run shell commands and scripts using add_custom_command or execute_process.
Dependency Management:

Seamlessly integrates libraries using find_package, FetchContent, or by adding the source folder with add_subdirectory.
IDE Integration:

Works flawlessly with IDEs like Visual Studio, Visual Studio Code, Xcode, CLion, and Eclipse.
Testing and Installation:

Built-in support for test frameworks (via CTest) and installation processes.
Modern C++ Features:

Leverages features like C++11/14/17/20, LTO, and sanitizers.
Extensibility & Reusability:

Highly customizable with user-defined macros, variables, functions, and modules without get knocking-hard with complexity like another build tools.

Equivalent Tools in Other Ecosystems

Java: Gradle, Maven.
Android: Gradle (Android Plugin).
iOS/macOS: Xcodebuild, Swift Package Manager (SPM).
Rust: Cargo.
Python: setuptools, pipenv.
JavaScript/Node.js: npm, yarn.
.NET: MSBuild, dotnet CLI.

In Next Series, we will cover:

Installing the prerequisite software to develop and compile Modern C++17 with CMake on Linux/WSL2 (Windows Subsystem for Linux 2).
Integrating Visual Studio Code (VS Code) for CMake C++17 Project Development.
Writing C++17 application and CMakeLists.txt configuration.

See you on next series =)

Configure Multi-Repository Git Submodules with Push via Git SSH & Pull via HTTPS in Github

L Djohari — Sat, 30 Nov 2024 14:51:21 +0000

Managing multiple repositories in Git, especially when using submodules, can be tricky—especially when you want different access levels for different users.

This article walks you through how to configure a Git multi-repository setup with submodules, ensuring that some users can have read-only access to the submodules via HTTPS, while your teams with correct credentials using git SSH can push changes via SSH.

Scenario Overview

Imagine you have a main repository (project) with two submodules (core and server).

  project #(https://github.com/<your-git-user>/project)
    libs/core #(https://github.com/<your-git-user>/core)
    libs/server #(https://github.com/<your-git-user>/server)

Note: This workflow scenario only working if your repository and its submodules is public repository.

The goal is:

Public users: Can clone the repository and its submodules via HTTPS (read-only access).
Authorized users: Can push changes to submodules via SSH, while not affecting public access.
This workflow is also apply to other git service provider such as gitlab or bitbucket.
With this workflow, everyone in your team could have different SSH Key Aliases and will not impacted git repository configurations.

Through this tutorial we are use git SSH Aliases for managing multi-account git SSH, if you still figure it you can read quick article Configure Git with Multi-Account SSH and Verified Commits Using GPG in Github in here.

Steps to Add Submodules to Main Repository (project)

1. Clone your Main Repository using Git SSH

Make sure you have configured your git SSH Key Aliases in your workstation and add SSH Key to your github account.

git clone git@github.com-<your-git-user>:<your-git-user>/project.git

2. Configure Local Git Repository Config

Configure local repository config from inside the local main repository folder (project)

cd project
git config user.name "Your Name"
git config user.email "your_email@example.com"

If you use commit GPG Signing you can add below configs

git config user.signingkey <GPG_KEY_ID>
git config commit.gpgsign true

3. Add submodules to your Main Repository using HTTPS

git submodule add https://github.com/<your-git-user>/core.git libs/core
git submodule add https://github.com/<your-git-user>/server.git libs/server

Initialize submodules and its dependencies if any

git submodule update --init --recursive

We are halfway to finished this configuration, now we have to configure the push origin to use git SSH url for each submodule, users with Authorized git SSH Key can push changes to submodules.

Steps to Configure `push origin` Url for git Submodule Push Access

1. Get Current `pull` and `push` Origin Url From Submodules

For authorized users with SSH access, set the push origin for each submodule to use SSH. This ensures that pushes to submodules are done via SSH, while clones remain accessible via HTTPS.

git submodule foreach 'git remote -v

output

$ git submodule foreach 'git remote -v'
Entering 'libs/core'
origin  https://github.com/<your-git-user>/core.git (fetch)
origin  https://github.com/<your-git-user>/core.git (push)
Entering 'libs/server'
origin  https://github.com/<your-git-user>/server.git (fetch)
origin  https://github.com/<your-git-user>/server.git (push)

It will print your pull and push url, we will configuring push url to use git SSH url.

2. Configure Submodules for Push Access (SSH)

For each submodule (core, server) we have to configure push origin url

A. Configure Submodule `libs/core` Push Url

Go to submodule libs/core from project folder

cd libs/core

Change push url to core git SSH url

git remote set-url --push origin git@github.com-<your-git-user>:<your-git-user>/core.git

Configure git username, email and commit GPG signing from inside `libs/core` folder

git config user.name "Your Name"
git config user.email "your_email@example.com"

If you use commit GPG Signing you can add below configs

git config user.signingkey <GPG_KEY_ID>
git config commit.gpgsign true

Go back to `project` folder

cd ../..

Now your submodule libs/core will have push origin point to git SSH url.

B. Configure Submodule `libs/server` Push Url

Go to submodule libs/server from project folder

cd libs/server

Change push url to server git SSH url

git remote set-url --push origin git@github.com-<your-git-user>:<your-git-user>/server.git

Configure git username, email and commit GPG signing from inside `libs/server` folder

git config user.name "Your Name"
git config user.email "your_email@example.com"

If you use commit GPG Signing you can add below configs

git config user.signingkey <GPG_KEY_ID>
git config commit.gpgsign true

Go back to `project` folder

cd ../..

Now your submodule libs/server will have push origin point to git SSH url.

2. Verified if `push origin` url is Using Correct git SSH Url

In project folder execute

git submodule foreach 'git remote -v'

It will print your submodules push origin url to point to git SSH url.

$ git submodule foreach 'git remote -v'
Entering 'libs/core'
origin  https://github.com/<your-git-user>/core.git (fetch)
origin  git@github.com-<your-git-user>:<your-git-user>/core.git (push)
Entering 'libs/server'
origin  https://github.com/<your-git-user>/server.git (fetch)
origin  git@github.com-<your-git-user>:<your-git-user>/server.git (push)

The .gitmodules file should still use HTTPS URLs for cloning. This way, public users can easily clone the repositories:

[submodule "core"]
    path = core
    url = https://github.com/<your-git-user>/core.git
[submodule "server"]
    path = server
    url = https://github.com/<your-git-user>/server.git

3. Push Changes from the Main Repository

After making changes to the main repository or it submodules, push everything as usual when we do push.

Conclusion

Read-Only Access for Public Users

Users who do not have SSH credentials can still clone the repository and submodules via HTTPS, but they won't be able to push any changes.
They must push changes via Pull Request.

Write Access for Authorized Users

Authorized users with SSH keys configured in GitHub can push changes directly to the submodules via SSH, while other users retain read-only access via HTTPS.

Working & Push Changes to Submodules from Main Repository

With this workflow, you can focus working inside Main Repository (project) to made necessary changes and push changes without struggling.

Boost Productivity with GitLens

This is not paid sponsor, but I found from my experience during development GitLens extension for Visual Studio Code helps a lot for my use cases.

GitLens for Visual Studio Code simplifies managing multi-repos with submodules. It helps you:

Track Submodule Changes: View commit history and differences across both the main repos and submodules.
Easily Manage Configurations: Visualize and manage SSH/HTTPS URLs for cloning and pushing right in your editor.

GitLens turns your Git workflow into a seamless, visual experience—perfect for managing submodules across multiple repositories.

Configure Git with Multi-Account SSH and Verified Commits Using GPG in Github

L Djohari — Thu, 28 Nov 2024 06:56:52 +0000

Throughout time in developments we faced multiple repositories with different git account/credentials. Managing multiple Git accounts and ensuring commit authenticity can be challenging.

This guide simplifies the process by combining multi-account SSH key setup with GPG signing for secure authentication and trusted commits across your Linux, Windows, and macOS workstation.

Why It Matters

SSH Keys: Manage multiple accounts securely with password-free access. Essential for handling separate work, personal, or client repositories without confusion.
GPG Signing: Cryptographically sign commits to prove their authenticity and protect them from tampering—critical for secure, professional or enterprise collaborations.
This workflow is also apply to other git service provider such as gitlab or bitbucket.

Steps

Typical steps to enabling multi-account Git SSH & GPG commit signing, you can check this big picture on how we enabling it.

Create SSH Key in workstation for each account with distinct name.
Save your SSH Public Key to github.
Create gpg key and save to github.
Clone using git SSH for push access to the repo.
Config the local git repo folder to configure username, email account and signing commit using your gpg key.
For complete details you can follow the rest of this article.

1. Setting Up Multi-Account Git with SSH

Step 1: Generate SSH Keys

For each Git account, generate a separate SSH key.

Linux/macOS:

ssh-keygen -t rsa -b 4096 -C "email@example.com" -f ~/.ssh/id_rsa_personal
ssh-keygen -t rsa -b 4096 -C "client_email@example.com" -f ~/.ssh/id_rsa_client

Windows (Git Bash):

ssh-keygen -t rsa -b 4096 -C "email@example.com" -f ~/ssh/id_rsa_personal
ssh-keygen -t rsa -b 4096 -C "client_email@example.com" -f ~/ssh/id_rsa_client

Important notes

During SSH Key Generation, user is your github username and email is your email registered for your github account.
"email@example.com" : you can change to your registered github email account.
"client_email@example.com" : you can change to your other registered github email account.

Step 2: Configure SSH

Edit the SSH config file to associate each key with its GitHub account.

Linux/macOS: ~/.ssh/config
Windows: ~/ssh/config

If the configfile doesn't exist you can create the file config first then edit it using a text editor.


# Personal Account
Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_personal

# Client Account
Host github-client
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_client

2. Adding SSH Keys to GitHub

Step 1: Copy Your Public Key

cat ~/.ssh/id_rsa_personal.pub
cat ~/.ssh/id_rsa_client.pub

Step 2: Add Keys to GitHub

Navigate to GitHub > Settings > SSH and GPG Keys > New SSH Key.
Paste each public key.
Label keys for clarity (e.g., "Personal" or "Client").

Step 3: Clone Using SSH Aliases

Clone repositories using the configured aliases:

git clone git@github-personal:username/repo.git
git clone git@github-client:client/repo.git

3. Setting Up GPG Signing

Step 1: Generate a GPG Key

Linux/macOS:

gpg --full-generate-key

Windows (Gpg4win):

Install Gpg4win and run:

gpg --full-generate-key

Choose RSA and RSA (4096 bits) and set an expiry date.

Step 2: Export the Public Key

Find the GPG key ID:

gpg --list-secret-keys --keyid-format LONG

Export and copy the key:

gpg --armor --export <GPG_KEY_ID>

Step 3: Add GPG Key to GitHub

Go to GitHub > Settings > SSH and GPG Keys > New GPG Key.
Paste the public key.

4. Configuring Repository-Specific Settings

For each repository, configure local Git settings to specify the username, email, and GPG key.

cd /path/to/repo
git config user.name "Your Name"
git config user.email "your_email@example.com"
git config user.signingkey <GPG_KEY_ID>
git config commit.gpgsign true

Verify settings with:

git config --get user.name
git config --get user.email
git config --get user.signingkey

This ensures commits in the repository use the correct identity and are signed.

5. Using and Verifying Signed Commits

Create a Signed Commit

git commit -S -m "Your commit message"

Verify Signed Commits

git log --show-signature

Git will display the signature status, confirming commit authenticity.

Conclusion

Combining multi-account SSH key management with GPG signing ensures secure, streamlined workflows for professional developers. Whether you're managing personal, work, or client repositories, this setup keeps your Git environment organized, authenticated, and trustworthy.

DEV Community: L Djohari

The Guide to Safe & Modern C Memory Allocation Strategy

0) TL;DR Rules

1) Core Allocation APIs

2) Safe Allocation Wrappers (ISO C, OOM-fatal, OOM-NULL with *_try variants)

3) Initialization Patterns

Structs (configs/contexts)

realloc tail must be initialized

4) Ownership Conventions (VERY IMPORTANT)

Example API

5) Create/Destroy + Heap Initialization

6) Anti-Patterns (Don’t Do These)

7) Practical Snippets

Safe formatting

8) Checklist

The Guide into Strings in C for Dev who wanted to learns C - Clear Rules, Mutation, Reassignment & Ownership, No Surprises

1. The Three Faces of Strings

2. Null Terminators

3. Do You Need to free Before Changing?

4. Helper functions

xstrdup (unbounded-length)

xstrndup (bounded-length)

5. Practical Cases

A) Pointer to literal (DO NOT USE)

B) Literal first, then reassigned to owned copy

C) Array inside struct

D) Owned pointer inside struct (copy-on-set)

E) Owned pointer (mutate in place with capacity)

F) Start as literal, then copy, then replace

6. Expanded Bug Cases to Avoid

7. API Pattern: Copy-on-Set

8. Choosing Array vs Pointer

9. Quick Checklist

Series I: CMake & C++17 Quick Started

Series I: CMake & C++17 Quick Started

In this first part of the series, we will focus on:

In Next Series, we will cover:

Fast-Tracking for Mastering C++17 Development

Why C++17

Key Features of C++17

CMake as a C++ Build Tool

What is CMake?

History

Why Use CMake?

Equivalent Tools in Other Ecosystems

In Next Series, we will cover:

Configure Multi-Repository Git Submodules with Push via Git SSH & Pull via HTTPS in Github

Scenario Overview

Steps to Add Submodules to Main Repository (project)

1. Clone your Main Repository using Git SSH

2. Configure Local Git Repository Config

3. Add submodules to your Main Repository using HTTPS

Steps to Configure push origin Url for git Submodule Push Access

1. Get Current pull and push Origin Url From Submodules

2. Configure Submodules for Push Access (SSH)

A. Configure Submodule libs/core Push Url

Configure git username, email and commit GPG signing from inside libs/core folder

Go back to project folder

B. Configure Submodule libs/server Push Url

Configure git username, email and commit GPG signing from inside libs/server folder

Go back to project folder

2. Verified if push origin url is Using Correct git SSH Url

3. Push Changes from the Main Repository

Conclusion

Read-Only Access for Public Users

Write Access for Authorized Users

Working & Push Changes to Submodules from Main Repository

Boost Productivity with GitLens

Configure Git with Multi-Account SSH and Verified Commits Using GPG in Github

Why It Matters

Steps

1. Setting Up Multi-Account Git with SSH

Step 1: Generate SSH Keys

Linux/macOS:

Windows (Git Bash):

Important notes

Step 2: Configure SSH

2. Adding SSH Keys to GitHub

Step 1: Copy Your Public Key

Step 2: Add Keys to GitHub

`realloc` tail must be initialized

3. Do You Need to `free` Before Changing?

Steps to Configure `push origin` Url for git Submodule Push Access

1. Get Current `pull` and `push` Origin Url From Submodules

A. Configure Submodule `libs/core` Push Url

Configure git username, email and commit GPG signing from inside `libs/core` folder

Go back to `project` folder

B. Configure Submodule `libs/server` Push Url

Configure git username, email and commit GPG signing from inside `libs/server` folder

Go back to `project` folder

2. Verified if `push origin` url is Using Correct git SSH Url