input handling in c
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.
six thoughts on generating c
./configure
make
make test
make install
Modern Tools for Hunting Undefined Behavior in C
GNU C Library 2.43 released
>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.
Best Practices for Ownership in GLib
>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.
Copying values pointed to by addresses stored in two variables (confusion with pointers).
I thought the book I’m reading had typos when I read code that uses this: C 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 [https://godbolt.org/z/EW7o3697e] 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: C 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 [https://godbolt.org/z/vMf9ns68q]. What’s wrong with this?
How can I force the entry-point to be at start of .text?
I’m trying to write a linker file to get C code running on a risc-v processor (using riscv-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 objdump 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. But IDK if this how it should be done. Thanks in advance :)
C-Chronicles-The-Quest-of-Quantum-Code: A C language game for programming beginners
Help needed!
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!
14th_cylon
Dendrobatus Azureus
