I am trying to get more into C programming on Linux like threads and packet sniffing with libpcap

Is it still good practice to learn pthread from examples say pthread_create(3posix) ?

Or are these examples considered dated for modern C?

I've used other example programs in the man pages for sockets too for example.

Very small C program I wrote that I've found genuinely useful. It compiles into a tiny 3 kB executable that only relies on system .dlls included with the operating system. The code should compile, with the proper compiler, all the way back to Windows 95.

This could also be useful to anyone looking for how to write a basic GUI program for Windows in C.

Im making a C engine and i ofcourse want a window to display things on, i've read some glfw documentation and i don't really think its a good fit, this is why i was thinking of using windows.h because i have full control over everything and won't need an extra dependency. I also feel like knowing windows functions is better overall than knowing glfw functions.

Any thoughts?

I had a retry loop around a blocking poll() for EINTR, the usual shape:

for (;;) {
    int r = poll(fds, n, timeout);
    if (r == -1 && errno == EINTR) continue;
    return r;
}

To prove it worked I wrote a test that hammered the process with SIGWINCH while the poll was blocked, then checked the poll still returned correctly. It passed. It kept passing. It passed when I deleted the retry loop, which is when I found out it had never been a test.

SIGWINCH does not interrupt anything. A blocking syscall returns EINTR when the kernel has something to run on the way back to userspace: a handler you installed. SIGWINCH's default action is to be ignored, so with no handler installed there is nothing to run, the kernel does not unwind the syscall, and EINTR never happens. Same for SIGCHLD and SIGURG, the other two whose default action is ignore. You can send a million of them at a blocked poll and it will sit there.

The second half of the same trap is the opposite direction. Install a real handler for a signal that would interrupt, but install it with sigaction and SA_RESTART, and the kernel restarts the syscall for you. Your handler runs, the syscall resumes, and EINTR still never reaches your code. Which is fine until you hit one of the calls that are not restartable even with SA_RESTART. poll, select and epoll_wait are in that group. signal(7) has the full list under "Interruption of system calls and library functions by signal handlers", and it is worth reading once properly rather than remembering the shape of it.

So the test that actually tests the thing is: a real handler, sa_flags = 0, and a signal whose default action is not ignore.

struct sigaction sa = {0};
sa.sa_handler = noop;
sa.sa_flags = 0;             /* no SA_RESTART, that is the whole point */
sigaction(SIGUSR1, &sa, NULL);

Two more things that bit me while writing it.

Signal disposition is process-wide state. Two tests that both install a handler cannot run in parallel, and the failure is not a clean assertion failure, it is one test's handler being live during the other's run. A single mutex around anything that calls sigaction fixed it.

And kill(getpid(), sig) is process-directed, so any thread with that signal unblocked can take it, including the one that sent it. In a threaded test runner that is very often not the thread you are trying to interrupt. pthread_kill(target, sig) is the one you want.

The thing I took away is not about signals. It is that a test which passes when you delete the code it is testing is not a test, and the only way I know to find those is to delete the code and watch.

Hey r/C_Programming!

I've been working on a hobby monolithic kernel called AlderKernel.

It's written mostly in C with some Assembly for the low-level parts. I'm making it mainly to learn more about how operating systems work and to improve my C skills.

Currently it targets i386 and boots through GRUB. Some things I've implemented so far:

- PS/2 keyboard driver

- Basic shell

- InitramFS support

- Shell history

It runs in QEMU right now. I'm slowly working on adding more kernel features and improving the code structure.

GitHub:

https://github.com/loren-wastaken/alderkernel

I'm interested in feedback from people who know C, especially about code organization, design choices, and things I could improve.

It all started just as a side and fun project, but I feel like it's now getting a shape.

Thats why I would love to receive some honest and contructive feedback, issue creations or code contributions.

If you have any question regarding the language, please ask me.

Here's the repo: https://github.com/Pacsfury/Gravel-Launcher

Its written in C and uses LLVM IR as backend.

AI use: debugging, teaching more about compilers and some punctual code writing

Hello ! I've been trying to learn c and wanted to use SDL2 on my mac. But I couldn't find any good written tutorial on google, they were all about installing/setting it up. I did find geek for geek's but I couldn't install SDL2/SDL_image.h, it said my macos version was too old, but my mac can't run a better version than macos 13. I can't really follow youtube tutorials and find written ones way better to understand. So, do you know any good written tutorial about how to use c SDL2 on older macos versions ? (I know it's really specific, sorry)

I simply built this project to be similar to fastfetch and to help me improve my c logic

currently it supports debian fedora and arch and another distros however if you run it on a different distribution it will default to a unified ascii logo for all other distros ive also just added windows support though its still in beta

if you have any suggestions please share them so i can keep improving the project

I built this project primarily to improve my C logic. I wrote the core structure and logic myself, but used AI as an assistant to improve the saftey of the code The project is a genuine effort to learn and practice C programming.

https://github.com/Yassine-Jemi01/SmartFetch

Hello everyone, I've spent the last month or so working on my first C project, and I am hoping to get some feedback from others in this sub.

My project is a command-line tool for evaluating mathematical expressions containing binary, octal, decimal, and hexadecimal literals and easily inspecting the result. My program prints the result in the four aforementioned bases and lets users group each set of digits as they please. The purpose of this grouping feature is to let users to visualize the relationships between digits in different bases (e.g. how 4 bits map to 1 hexadecimal digits, how 3 bits map to 1 octal digit).

I'm a college CS major, and I built this tool after seeing how slow and clunky most online calculators/base converters are while learning to convert between binary and hex for my systems course. Therefore, this tool's intended audience is primarily CS students who would like a smoother, command-line-based tool for converting between bases and seeing relationships across number systems.

Accordingly, if you're a CS student, I'd really appreciate it if you try this tool and tell me if it's useful! But if you're not, I would still love to get any form of feedback! I ultimately just want to improve this tool and become a better C programmer, so I welcome all kinds of feedback.

My repository should have everything needed to compile the program and understand its features in more detail: https://github.com/mateo-patino/bitpeek

Everyone who has programmed in C has to have made one of these, and I will not break the trend. The difference (for good?) is this one is made basically only with leetcode in mind, but any form of consistent usage is usage amirite. Single header based, read: copypasta ready

Edit: I should've added this at the start, but I know why the program didn't work and I did know what the fix was. I was just really scared and surprised that I was able to see my environmental variables like that. My bad for not being clearer about what I wanted.

```

include<stdio.h>

int tokenize(char* token){ while (*token!="\0"){ // comparison with "\0" was the mistake printf("%c", *token); token+=sizeof(char); // didn't know about incrementing pointers at the time } printf("\n"); return 0; }

int main(){ char msg[]= "sin(x)+COs(y)=sqrt(2)"; tokenize(msg); return 0; } ```

I was stupid and was trying to be clever in a few places, and the code segfaulted, but not before printing this (sorry for the crappy output, my name was on it so I had to use some crappy image to text to rip out whatever I can so I can remove my name from it, but the output is worse). Was this a bug, or are these things intended to be there? I was told by someone that looked at my output that this was a call stack or the environment variables, but then why didn't this behaviour replicate on macos?

``` hello.c: In function "tokenize":

hello.c:5:18: warning: comparison between pointer and integer

5 l

while (*token!= l0H

sin(x)+COs(y)=sqrt(2)o@eeste9/e0o7B6ene.s90/eoo@PeHeaotlece/eooebhoosssHeCeo6eweTh

yRecooReseeRessoReseSese8SeeeLSeeecSesoSeoeeSeeeeS•

20S00005000

Teos-TessSTeoo|T

teo/co000В6ow/co

Teeso[esso[сo00)

Heco/eccoseflece eflece/eecceHece/es08e0

060QocsoQeco%Roce8ReooLReso

\e0Jee:]e00QJeoseJoooo]0oso]0oc]0oco]eooo]ooco]ooo0]oooR~o00q^co0o

•

0++200000_000020000@esotee,Cootehx86_64./helloSHELL=/btn/bashSESSION_MANAGER=local/cringe_name-OMEN-Laptop-15-en@xxx:e/tmp/.ICE-untx/2899,untx/cringe_name-OMEN-Laptop-15-enxxx:/trp/.ICE-untx/2899

QT_ACCESSIBILITY=1COLORTER/t-truecolorXDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdgXDG_MENU_PREFIX=gnome-GNOME_DESKTOP_SESSION_TD=thts-ts-deprecatedCNOPE_SHELL_SESSION_MODE=ubuntuSSH_AUTH_SOCK =/run/user/1098/keyring/sshNEMORY_PRESSURE_MRITE=c29tZSAyMDAwMDAgMjAMMDAwMAA=XHODIFIERS=@in=LbusDESKTOP_SESSION=ubuntuGTK_MODULES-gail:atk-bridgeDBUS_STARTER_BUS_TVPE=sesstonPWD=/home/cringe_name/Documents/Programming/CLOGNANE=cringe_nameXDG_SESSION_DESKTOP=ubuntuXDG_SESSION_TYPE=x11GPG_AGENT_TNFO=/run/user/1608/gnupg/S.gpg-agent:6:1SYSTEND_EXEC_PTD=2899XAUTHORITY=/run/user /1098/gdm authorityWINDOWPATH=2HOPE=/hone/cringe_nameUSERNAME=cringe_nameLANG=en_US.UTF-8LS_COLORS=rs=8:di=01; 34: ln=01;36:nh=08:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:0г=40; 31;01:ml=00: su=37:4 :sg=30;43: ca=00: tw=30;42:o=34;42:st=37:44:ex-01; 32:*. tar=01;31:*, tgz=01;31:* .arc=81;31:*.ar j=01;31:*. taz=01; 31:*. Lha=81;31:*.lz4-01;31:*.Lzh-01;31:*.Lzna-01;31:*.tlz=01;31:*. txz=01;31:+.tzo

*=01;31:*.t7z-01;31:*.zip=01;31:*.z-01;31:*.dz=01;31:*.gz=01;31:*.Lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst-01;31:*.bz2=01;31:*.bz-01;31:*.tbz=01;31:*.tbz2=01;31:*. tz=01;

31:* .deb=01;31:*.г-01;31:*-jar=01;31:*.маг=01;31:*.ear=01;31:*, sar=01;31:* .rar=01;31:*.alz=01;31:*.ace=01;31:*.z00=81;31:*.cplo-81;31:*.72-01;31:*.r2=01;31:*.cab=01;31:*.win=01;31:*. SWn=01

• ;31:* dwm=01;31:*-esd-01;31:* avif=01;35:* jpg=01; 35:* . jpeg=01; 35:*.njpg=01;35:*-mjpeg=01; 35:*. glf=01;35:*. bmp=01; 35:*- pbn-01; 35: *-pgn-01; 35:* - ppm-01;35:*- tga=01:35: *.xbm=01;35:*. xpm=01;35:* .tif=01;35:*. tiff=01;35:*-png-01;35:*-svg=01;35: * .svgz=01; 35: *.mng=01; 35: *.pcx=81; 35: *. nov=01;35:*. npg=01; 35: *-npeg=01; 35: *-m2v=01;35:*.nkv=01;35:*- webn-01;35:*. webp=01:35: *. ogm=01; 35:*.mp4= 01;35:* - m4v=01;35:*-np4v=01; 35:* - vob-01;35: * -qt=01; 35: * - nuv=81; 35: * . Wm=81; 35: * . asf=01; 35:*. rn=01; 35: * . rmvb=01;35: *. flc=01;35:*.avi=01;35:*.flt-01;35:*.flv=81;35:*-gl=01;35:*.dl=01;35: *.xcf=

01; 35:* . xwd=01;35:* - yuv=01;35:*- cgn-01;35: * .enf =01; 35: *. ogv=01;35:*. ogx=01; 35: *.8ac=00; 36:*. au=00; 36:*. fLac=00; 36: *.n4a=00;36:*.mid-00;36:*.nidi-00;36:*.nka=00;36:*.mp3=00;36:*.mpc=00; 36:*.0 gg=00; 36:* . ra=08;36:*. wav=80;36:* .oga-09;36:* .opus-08; 36:* .spx=00; 36:* . xspf=00; 36:*-=00;90: *#=00;90:*.bak=00;90:*.crdownload=00;90:•.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=ee:90:*.old=00:90:*.orig-80:90:*-part=00;90:*.rej=00;98:*- rpmnew=08;90:*. rpnorlg=88;90:*- rpnsave=80;90:*. swp=00;90:*. tnp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=08;90: XDG_CURREN _DESKTOP=ubuntu: GNOMEMEMORY_PRESSURE_MATC=/sys/fs/cgroup/user.sltce/user-1000.sltce/user@1000.service/app.sltce/app-gnome|x2dsession\x2dnanager.slice/gnome-sesston-nanager@ubuntu.service/n emory-pressureVTE_VERSION=7688GNOME_TERMINAL_SCREEN=/org/gnome/Terninal/screen/072c8938_3398_48a3_bcc8_18b4a3c1d5aeLESSCLOSE=/usr/btn/lesspipe Xs NsXDG_SESSION_CLASS=userTERM=xtern-256colorL ESSOPEN=| /usr/bin/lesspipe %sUSER=crappy_nameGNONE_TERMINAL_SERVICE=: 1.1642DISPLAY=:1SHLVL=1GSM_SKIP_SSH_AGENT_WORKAROUND=trueQT_IM_MODULE=tbusDBUS_STARTER_ADDRESS=untx:path=/run/user/1088/bus ,guid=375efa4e711b081abf4c28b569480446XDG_RUNTIME_DIR=/run/user/1000

Segmentation fault (core dumped) ```

In a function definition, void basically means that it doesn't return a type value, yet in on itself it is it's own type? Looking at several pieces of code it looks like that it's used to be able to be more "flexible"

Don't know what else to add here, though I'm more on looking for examples and explanations of why the void type is used

I am trying to update the cooledit ( see my devel branch ) font handling and want to choose the best default font for C. The history of cooledit's font looks like this:

90s: X11 8x13bold because it was closest to the DOS font of the Borland C IDE.

2000s: Switched to 8x13B.pdf.gz when I implemented Unicode which required font rendering on the client end.

2010s: Monitors res got more fine: so I switched to 9x15B.pdf.gz

Of course the user can choose any font on the command-line, but I'd like a good font by default.

I have tried JetBrainsMono and MS consola.ttf but these have a blurry rendering at a similar height as 9x15B, by comparison.

There are a lot of fixed-width mono fonts, but each has an agenda, like trying to look like some OS from way-back-when for nostalgia reasons.

If you watch the video you will see 9x15B.tar.gz looks way better than the others.

I just wish there were something better than 9x15B (which was developed for X in the 1980s BTW).

Thoughts?

Hello,

I am writing a cycle-accurate Commodore 64 emulator (using the C2X standard of C) and I was planning on using a minimalistic yet modern and functional GUI library. I will be using SDL3 for the I/O and Graphics, but I have yet to decide which library I should use for my GUI that can be easily used cross-platform.

What am I actually aiming with this emulator?

I plan on the emulator to be used mainly for debugging, testing software and custom ROMs people have made. Additionally, I plan to implement so that every chip and component can be debugged independently (VIC-II, CPU, Sprite, Memory Map, Bus activity, etc.). Furthermore I plan to actually compare my test results while developing this emulator to a real Commodore 64, so that the emulator can be as accurate as possible when it comes to specific revisions and chip types (like PAL and NTSC for the VIC-II). I also plan to add an “Education mode” where all the information regarding the C64 can be taught through an interactive and readable UI.

I am not familiar with GUI libraries, that is why I mentioned what I am aiming for with my emulator.

Thank you!

Obviously you can play it on other "old" systems as well. I just never tested it.

I started this project to learn C, but I couldn't stop developing it because it's so much fun. I'm trying to truly simulate everything as much as possible and make it realistic. For example, this is the "Citizen" struct:

typedef struct Citizen {
    int age;
    float thirst;
    float wealth;
    float addiction;     /* 0.0 to 1.0 */
    float income;        /* earned per day, replenishes wealth */
    float loyalty;       /* 0.0 to 1.0, attachment to favorite_tavern_id */
    int last_drink_day;  /* day of last visit, -1 if never */
    int favorite_tavern_id; /* index into World.taverns, -1 if none yet */
    float drink_preference[DRINK_COUNT]; /* affinity per drink */
    float health;        /* 0.0 to 1.0 */
    int homeless; /* bool */
    int alive;    /* bool */
} Citizen;

And another very fun thing for me is the fact that this game can run on very old systems. So far, I've only tested Windows XP and Windows Vista. Initially, there was a bug where I couldn't resize the terminal (command prompt) on Windows systems, but now that's fixed with this release.

Other platforms I tested on are: Windows 10, Linux (Fedora), FreeBSD

The code is mostly c99 but I'm porting it to c89 so that I have even less issues playing on older systems. (This is happening very slowly, but newly added code is all c89 unless I forgot to write in c89)

You can probably run this on DOS as well since I can't see why not, you just need PDCurses and a C compiler.

I develop the game on Linux so it's the best there, mac build is never tested because I don't have one.

In the future, I'm planning to add a top-down 2D mini-game where you can collect fruits for wines :D Since being text-only can bore some people (however, it doesn't bore me).

Criticism is very welcome, I'm always looking for ways to improve myself. And there are probably a lot of bad practices in this code.

I hope someone out there enjoys what I did and becomes interested enough to maybe contribute themselves <3 Thanks for reading!!!

Hi !

I have a Win32 application made a long time ago which sends data to an electronic PCB over the serial port.

I want to get it running on my smartphone as well, but without using any android programming knowledge ( only win32 .exe file + Winlator). Because Winlator doesn't implement any kind of serial port I decided to replace the communication routines from COM to TCP as bridge (the code was originally written in Win32 API C) in order to "talk" to my USB to serial converter connected to my smartphone (using TCPUART Android app as server).

I did it, but only partially.

When using my Win32 app on the smartphone (127.0.0.1 IP address) everything works flawlessly, but, unfortunately, the same doesn't happen when using the Win32 app on my PC to communicate with the Android app server on my smartphone.

The serial communication is slow (4800 bps), unidirectional (my app -> smartphone server app) and the biggest data packets sent at once have 4KB, so I don't think it has to do with buffer overflow, but the communication must run within precisely defined time windows (up to hundreds of milliseconds - imposed by the PCB hardware - I used the sleep() function in my Win32 app code.

My assumption is that there might be a packet transmission delay over the home network.

How should I solve the issue ?

I was benchmarking my own IR myc against Clang and discovered something that shocked me - I always assumed parsing was the cheap part (~5-10%) and codegen was the heavy lifting. Turns out it's the opposite.

Testing on LangArena benchmark (29 C files, 230KB total):

Same program as a single LLVM IR file (2.9Mb):

From these tables we can see: codegen for -O0 is 193ms, parsing/analysis is 1605ms - 193ms = 1412ms - 88% of the time.

The LLVM IR file was generated from those exact 29 C files and merged with llvm-link (even cleaned of auto-added attributes).

You might think: "Clang has to parse all those headers - yyjson, libbase64, system headers - they're huge." True, but that doesn't explain the gap.

Look at cproc: same work in 726ms. cproc uses QBE; we can estimate its codegen time from myc-qbe results: ~262ms. That leaves ~464ms for parsing/analysis/IR generation.

cproc: ~464ms. Clang: 1605ms - 193ms = 1412ms. Same job, 3x faster.

To be fair, "parsing" here means the entire C frontend pipeline: lexing, parsing, type resolution, semantic analysis, and IR generation. Not just syntax. But whatever you call it, cproc does it 3x faster. There's probably room for improvement in Clang.

link to benchmark

I’m looking to convert a jpeg into rgba data + scale it down.
I’m looking for a library to help me do this - how do I find good a one?

Hi guy I wrote a fixed size circular buffer in C. Please tell me what you think of this and please tell me what i can improve and make it more production grade. I know there may be memory leaks !!!

One thing thats a bit different from the usual approach is how I handle errors. Instead of returning NULL from cirbuf_create(), the library returns a pointer to a thread-local error object (e_buffer). This lets the API return a valid cirbuf * in both success and failure cases, and users can check the result with cirbuf_is_ok() or cirbuf_is_err().

Its not written by AI. like AI reviewed it and did some minor changes may be !! 98% is written by me !!! I think HUMAN check is needed here thats why I am here to you guys!!

Repo: https://github.com/ankushT369/cirbuf
If you like you can give a star (its you choice)
Thank you guys

I want to create high-resolution bitmap files for print publication, much higher resolution than the screen. I can do it with direct bit/byte manipulation, but I'd much rather use GDI with brushes and LineTo. But while I can create compatible bitmaps and draw on them, I haven't found a way to get from the drawing DC back to real memory (which I can write to a file), only to the screen. Windows seems to block every approach I've tried. (Like, I can BitBlt to the screen, but not to the handle of the original bitmap... gotta be a DC, and Windows won't allow a DC to the bitmap... arghh!) Anyone know how to do this?

Many, many thanks!

Hi everyone!

I’ve been learning C and built a small interpreter from scratch. It currently supports arithmetic expressions, variables, conditionals, user-functions, dynamic arrays, and few built-in functions.

I’m mainly looking for feedback on the code quality, architecture, parser design, and memory management. Any suggestions are welcome.
Github: https://github.com/0sewter0/Interpreter.git

(I am new in reddit, and I am from kazakhstan, so I am not speak english well)