cross-posted from: https://lemmy.ml/post/42242801

Major new features:

• The ISO C23 free_sized, free_aligned_sized, memset_explicit, and memalignment functions have been added.

• As specified in ISO C23, the assert macro is defined to take variable arguments to support expressions with a comma inside a compound literal initializer not surrounded by parentheses.

• For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type.

• The ISO C23 typedef names long_double_t, _Float32_t, _Float64_t, and (on platforms supporting _Float128) _Float128_t, introduced in TS 18661-3:2015, have been added to <math.h>.

• The ISO C23 optional time bases TIME_MONOTONIC, TIME_ACTIVE, and TIME_THREAD_ACTIVE have been added.

• On Linux, the mseal function has been added. It allows for sealing memory mappings to prevent further changes during process execution, such as changes to protection permissions, unmapping, relocation to another location, or shrinking the size.

• Additional optimized and correctly rounded mathematical functions have been imported from the CORE-MATH project, in particular acosh, asinh, atanh, erf, erfc, lgamma, and tgamma.

• Optimized implementations for fma, fmaf, remainder, remaindef, frexpf, frexp, frexpl (binary128), and frexpl (intel96) have been added.

• The SVID handling for acosf, acoshf, asinhf, atan2f, atanhf, coshf, fmodf, lgammaf/lgammaf_r, log10f, remainderf, sinhf, sqrtf, tgammaf, y0/j0, y1/j1, and yn/jn was moved to compat symbols, allowing improvements in performance.

• Experimental support for building with clang has been added. It requires at least clang version 18, aarch64-linux-gnu or x86_64-linux-gnu targets, and a libgcc compatible runtime (including libgcc_s.so for pthread cancellation and backtrace runtime support).

• On Linux, the openat2 function has been added. It is an extension of openat and provides a superset of its functionality. It is supported only in LFS mode and is a cancellable entrypoint.

• On AArch64, support for 2MB transparent huge pages has been enabled by default in malloc (similar to setting glibc.malloc.hugetlb=1 tunable).

• On AArch64 Linux targets supporting the Scalable Matrix Extension (SME), the clone() system call wrapper will disable the ZA state of the SME.

• On AArch64 targets supporting the Branch Target Identification (BTI) extension, it is possible to enforce that all binaries in the process support BTI using the glibc.cpu.aarch64_bti tunable.

• On AArch64 Linux targets supporting at least one of the branch protection extensions (e.g. Branch Target Identification or Guarded Control Stack), it is possible to use LD_DEBUG=security to make the dynamic linker show warning messages about loaded binaries that do not support the corresponding security feature.

• On AArch64, vector variants of the new C23 exp2m1, exp10m1, log10p1, log2p1, and rsqrt routines have been added.

• On RISC-V, an RVV-optimized implementation of memset has been added.

• On x86, support for the Intel Nova Lake and Wildcat Lake processors has been added.

• The test suite has seen significant improvements in particular around the scanf, strerror, strsignal functions and multithreaded testing.

• Unicode support has been updated to Unicode 17.0.0.

• The manual has been updated and modernized, in particular also regarding many of its code examples.

I made this 15 minute video in one take - no editing and no script. After 4 months I watched it again and I'm really happy with it. I like to record stuff that seems natural and not scripted for clicks and votes.

If you don't like Rumble then tell me where I should upload to instead. If someone posts here with a passion for a specific video platform then I'll certainly make an account on that platform.

Is there a library for C, providing thread safe (high performance), and structured logging? An example for rust is the Tracing crate for rust (from Tokio). It should support several outputs as well.

cross-posted from: https://lemmy.ml/post/2650558

Highlights:

• More work on C2X features.

• The strlcpy and strlcat functions have been added. They are derived from OpenBSD, and are expected to be added to a future POSIX version.

• Support for x86_64 running on Hurd has been added.

• CVE-2023-25139: When the printf family of functions is called with a format specifier that uses an (enable grouping) and a minimum width specifier, the resulting output could be larger than reasonably expected by a caller that computed a tight bound on the buffer size. The resulting larger than expected output could result in a buffer overflow in the printf family of functions.

Let's say I have two arrays that have related data:

const char *backend_short[] = { "oal", "pa", "sdl_m" };
const char *backend_long[] = { "openal", "portaudio", "sdl_mixer" };

Does C support a way to "assert" that these two arrays have the same size? And failing compilation if they are different? I want a safeguard in case I'm drunk one day and forget to keep these synchronized.

Thanks in advance.

EDIT: I found a solution. Here are some enlightening resources on the matter:

• https://www.pixelbeat.org/programming/gcc/static_assert.html
• https://www.embedded.com/catching-errors-early-with-compile-time-assertions/

If one has POSIX extensions available, then it seems that defining _POSIX_C_SOURCE and just using getline or detdelim is the way to go. However, for source that is just C, here is a solution I've found from various sources, mainly here. I've also tried to make it more safe.

// Read line from stdin

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

#define CHUNK_SIZE 16 // Allocate memory in chunks of this size

// Safe self-realloc
void *xrealloc(void *ptr, size_t size)
{
    void *tmp = realloc(ptr, size);
    if (!tmp) free(ptr);
    return tmp;
}

// Dynamically allocate memory for char pointer from stdin
char *readline(void)
{
    size_t len = 0, chunk = CHUNK_SIZE;
    char *str = (char *)malloc(CHUNK_SIZE);
    if (!str) return NULL;
    int ch;
    while((ch = getchar()) != EOF && ch != '\n' && ch != '\r') {
        str[len++] = ch;
        if (len == chunk) {
            str = (char *)xrealloc(str, chunk+=CHUNK_SIZE);
            if (!str) return NULL;
        }
    }
    str[len++] = '\0'; // Ensure str is null-terminated
    return (char *)xrealloc(str, len);
}

int main(void)
{
    setbuf(stdout, NULL); // Ensure environment doesn't buffer stdout
    printf("Enter name: ");
    char *userName = readline();
    if (!userName) return 1;
    printf("Hello, %s!\n", userName);
    free(userName);
    return 0;
}

The idea is that we allocate in chunks of 16, or whichever size. xrealloc is handy when reallocating a block of memory to itself.

int *ptr = malloc(sizeof(int) * 4);
ptr = (int *)realloc(ptr, sizeof(int) * 8);

If realloc fails, ptr gets assigned NULL, and we lose the address that we need to free, causing a memory leak. So, xrealloc allows for safe self re-allocation.

I am not the author of dwl. Since dwl is based on wlroots (just like the popular Sway) it already supports making screenshots using grim and screencasts using wf-recorder.

You can try out dwl from within your current WM. The default modkey is Alt. If you want to use the Super key, change #define MODKEY WLR_MODIFIER_ALT in config.h to #define MODKEY WLR_MODIFIER_LOGO and recompile. The default terminal emulator is kitty but you can change termcmd to alacritty if you want.

Currently, only native Wayland applications run on it. You can enable experimental Wayland support for Firefox with MOZ_ENABLE_WAYLAND=1, see Running programs natively under Wayland in Sway Wiki.

Do not hover over the edges of windows – this will crash dwl.

Hello fellow lemmys (or however do we call us?),

as the title suggests, I am looking for someone who wants to learn the C programming language. I have a decent knowledge of computer science and of a couple of programming languages (C#, Java, Python). Currently, I am studying computer science in central/western Europe. In my opinion, studying together keeps each other motivated and is more efficient. In long terms, I hope, that we can contribute to open-source projects together and improve our code quality by reviewing each others code.

If any of you has some interest in being my programming buddy, please message me or reply to this post. Preferably from a similar time zone (mine is UTC+01:00).

Hoping for some replies

Regards