hello, i am a student coder and i am spending more time trying to handle the f...ing input than i spend on algorithmization of the problem. could someone recommend some good study source, please?

i would like both the explanatory part, as well as some set of practice exercises that would really cover all possible variations.

thank you.

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.

For all the rightful criticisms that C gets, GLib does manage to alleviate at least some of it. If we can’t use a better language, we should at least make use of all the tools we have in C with GLib.

This post looks at the topic of ownership, and also how it applies to libdex fibers.

I thought the book I'm reading had typos when I read code that uses this:

uint32_t src = 0xf0;
uint32_t dest = 0x400;

int main() {
    *&dest = *&src;
}

However if you take a look at the decompiled version on godbolt: link this correctly takes the value at the address stored in src, and copies it to the address in dest.

I'd love some help understanding what going on. The code looks like nonsense to me, "*&" should "cancel out" IMO.

========

Meanwhile here's what I thought the correct code would be:

uint32_t src = 0xf0;
uint32_t dest = 0x400;

int main() {
    *(uint32_t*) dest = *(uint32_t*) src;
}

Doesn't do what's expected, see decompiled: link. What's wrong with this?

When the RHS is a constant it works fine, and seems to be a common pattern people use.

I'm trying to write a linker file to get C code running on a risc-v MCU (using riscv64-unknown-elf toolchain). My linker script looks like this, simplified:

MEMORY {
        IRAM (rx) : ORIGIN = 0x00000000, LENGTH = 1024
}

ENTRY(_start)

SECTIONS {
    .text : ALIGN(4) {
        *(.text)
    } >IRAM

...

readelf -h correctly shows the entry point's address to be the same as where _start is in the output executable. But I want _start to be at 0x0, not somewhere else, so that when I objcopy it to a flat binary, the start code will be at the beginning. How can I do this?

Right now I'm having the _start function go in a new section called ".boot" I've defined in the C file using __attribute__((section(".boot"))), then, placing this at the start of .text in the linker script like so

...
    .text : ALIGN(4) {
        *(.boot)
        *(.text)
...

But IDK if this how it should be done.

Thanks in advance :)

Hi! I've recently started learning C and I've been getting stuck on the basic tasks cuz I keep overcomplicating them T-T Could anyone please help me with this specific task?

Problem Statement

You have a digit sequence S of length 4. You are wondering which of the following formats S is in:

• YYMM format: the last two digits of the year and the two-digit representation of the month (example: 01 for January), concatenated in this order
• MMYY format: the two-digit representation of the month and the last two digits of the year, concatenated in this order

If S is valid in only YYMM format, print YYMM; if S is valid in only MMYY format, print MMYY; if S is valid in both formats, print AMBIGUOUS; if S is valid in neither format, print NA.

Constraints
－ S is a digit sequence of length 4.

Sample Input 1
1905

Sample Output 1
YYMM
May XX19 is a valid date, but 19 is not valid as a month. Thus, this string is only valid in YYMM format.

Sample Input 2
0112

Sample 2
AMBIGUOUS
Both December XX01 and January XX12 are valid dates. Thus, this string is valid in both formats.

Sample Input 3
1700

Sample Output 3
NA
Neither 0 nor 17 is valid as a month. Thus, this string is valid in neither format.

The code I wrote for this is:

#include <stdio.h>

int main(){
    int S;
    scanf("%d", &S);
    int p1 = S/100;
    int p2 = S%100;
    if (p1!=0 && p1<=12){
        if(p2!=0 && p2<=12){
            printf("AMBIGUOUS");
        }
        else if (p2>=13){
            printf("MMYY");
        }
        else{
            printf("NA");
        }
    }
    else if (p1>=13){
        
        if(p2!=0 && p2<=12){
            printf("YYMM");
        }
        else {
            printf("NA");
        }
    }
   return 0;
}

It passed the 7 checks in the system, but failed on the 8th and I have no idea what kind of values are on the 8th check... Thanks to anyone for reading this far!

Many interesting presentations.

(I replaced the post with the YouTube link. This post links to the event page instead.)

I was just wondering if there are some really good websites to learn some tricks in C. As a not so beginner programmer I would really appreciate any kind of C snippet archive or something to find inspiration. I occasionally find some gold while watching Tsoding streams, but that experience is usually less dense in terms of fancy code and focuses more on problem solving.

I encounter memory corruption issue at work coming from a signal handler and decided to write a blog post about it. Feedback welcome.

C is one of the top languages in terms of speed, memory and energy

https://www.threads.com/@engineerscodex/post/C9_R-uhvGbv?hl=en

The author replaced a garbage collector with another for Guile, a Scheme dialect, both gcs are written in C

For the big brain 10,000 meter view, defer ⸺ and the forthcoming TS 25755 ⸺ is a general-purpose block/scope-based “undo” mechanism that allows you to ensure that no matter what happens a set of behavior (statements) are run.

There's no perhaps about the FBI and CISA getting snippy at buffer overflows. These people worry about exploits that threaten car-crash incidents in enterprise IT, and they've seen enough to get angry. It's not that making mistakes is a crime when writing code. No human endeavor worth doing is without error. It's more that this class of bug is avoidable, and has been for decades, yet it pours out of big tech like woodworm from a church pew. Enough already, they say. They are right.

Any good cheat sheets about C?

I have found only this one https://cheatography.com/ashlyn-black/cheat-sheets/c-reference/

Maybe you know any else?

@c_lang@programming.dev

cross-posted from: https://discuss.tchncs.de/post/22432836