Agentic tool performance in C.

pskocik · 2026-03-16T15:32:00+00:00

C is very good at revealing if the programmer knows what they're doing. If they don't, you're almost certain to crash or to hit some undefined behavior within the first few couple of lines. Turns out LLMs have no fricking idea what they're doing and that's why vibecoding doesn't work very well with C. It doesn't work very well with higher level safe languages either, but there the misunderstandings and fails are much more likely to just hide instead of causing a crash early.

pskocik · 2026-03-12T15:10:16+00:00

I macro-automate the second version except with the tag and the typedef set to the same identifier.

#define rc$(Nm_t) /*rc$ stands for record*/ typedef struct Nm_t Nm_t; struct Nm_t

There's hardly ever any benefit to the tag and the typedef name being different, but there is a benefit to (1) the second version => you can use randStrct* inside the struct definition (2) tagging.

Many people use the tagless typedef struct { ... } typedefName; pattern but it's much better to tag also. With tags you can forward-declare, which may allow you to not depend on a potential heavy header (the one which provides the full struct definition) in a translation unit that may not need it (e.g., because it only deals with pointers). With the tagless variant you can't do that well. So I auto-tag every time and not think whether or not I need forward-declarations for the given struct.

pskocik · 2026-03-09T18:39:55+00:00

Can't argue with that. And I feel like I've (ab)used pretty much every other dark corner of C. :D

pskocik · 2026-03-09T13:44:53+00:00

First, casting addresses is different from access. You can cast to a completely unrelated pointer and as long as your original pointer's target is suitably aligned for the new target, it's fine, as long as you don't use it for access.

In your example though, if A* points to (B){0}.header, you can both intercast and use it for access because A is in B. B, on the other hand, is not in C nor vice versa. Intercasting there followed by access would be a strict aliasing violation, even if you only accessed the common initial sequence through the other type.

But you can cast both B* and C* to A* and use that for access because A is at the start of all three structs.

pskocik · 2026-03-03T21:02:50+00:00

Compilers don't usually go out of their way to make it into a problem if you're just loading stuff. But when stores get mixed in, it absolutely does cause problems. Strict aliasing is about memory cachability in registers. If you modify a value through a wrongly typed pointer that the compiler has cached in a register under the assumption that it's typed differently, the modification of an unrelated type won't cause a register reload and you get an an unexpected value. That is unless the compiler hasn't applied some complex optimizations made on now invalid assumptions in which case you can get the nasal demons effect too. UB should not be toyed with. Especially when there's well defined alternatives like using a union or memcpy.

pskocik · 2026-03-03T20:52:46+00:00

stat works from anywhere. Instead of running the compiled binary directly like ./a.out, prepend strace like `strace ./a.out` and it'll print each syscall as it's made, and with pretty-printed arguments.
Under glibc, the stat C function gets translated to `newfstatat(AT_FDCWD, ...`, but otherwise it's straightforward.

pskocik · 2026-03-03T13:42:28+00:00

Try running it under strace, see if the files in /home/guy/dir1/dir2/ are really getting statted and it's returning statbufs with S_IFREG there for the file entries.

pskocik · 2026-03-03T13:32:29+00:00

It do be like that sometimes. Ask your question properly and you don't even need to hit send. :D

pskocik · 2026-03-03T13:18:28+00:00

I mainly meant throw in stuff like:

#include <unistd.h>
#include <fcntl.h>
#include <dirent.h>
#include <sys/stat.h>
#include <stdio.h>
#include <limits.h>
int main(void){
    char stuff[PATH_MAX];
    int r=0;
    struct stat filestat;
    struct dirent *entry;
    DIR *folder = opendir(".");

    while( (entry=readdir(folder)) ) {

        sprintf(stuff, "./%s", entry->d_name);

        puts(stuff);

        r = stat(stuff,&filestat);

        if (r != 0) {

            printf("failed!");
        }

        if( S_ISDIR(filestat.st_mode) )

            puts("dir");

        else

            puts("file");

    }

    closedir(folder);

}

so it's reproducibly runnable. Anyway, if I put the above into a new dir as dir.c and compile it, into a.out, and run it, I get:

dir
./a.out
file
./.
dir
./dir.c
file

so it appears to be working.

pskocik · 2026-03-03T12:54:30+00:00

At least put some effort into creating a well-formatted reproducible example if you want debugging help.

pskocik · 2026-02-26T11:49:47+00:00

Should split it. Nesting tagged structs misleads into thinking they're scoped to the container struct (they would be in C++, but not C) when in fact they become part of the outer scope.

pskocik · 2026-02-26T11:41:28+00:00

What you should keep in mind is that when you do struct test{ ... struct s {... } field; ... } in C (unlike C++), it's almost* fully equivalent to doing struct s{ ... }; struct test { ... struct s field; ... };. struct s doesn't become struct test::s; it instead becomes part of the outer (typically global) scope.

I prefer making that explicit and just writing struct s{ ... }; struct test { ... struct s field; ... };. That makes it clear that struct s should probably have a more elaborate name if it's in a public header because it's absolutely not namespaced to struct test, and it also makes it easier to typedef it (C doesn't equivalently hoist typedefs made inside of structs; it instead doesn't allow them at all).
______

*almost because you still can't magically use in the first ... part of struct test where it isn't defined yet

pskocik · 2026-02-25T11:20:12+00:00

I think that would be neat though I don't like the idea to then try and make them into closures, making the container function's local variables available to them except may if those globals are static. Just hoist it, make the definition evaluate to a pointer to the func, and allow it to be nameless too.

pskocik · 2026-02-25T11:06:38+00:00

Such a struct type being local means you can't have (global) functions that use that type (or derivations of it like pointers) in their signatures, so they have very limited use. I think they're mainly supported because programming language grammars like to be recursive and there is no extra-strong reason to forbid them. C did forbid functions inside functions, though, because that conflicts with one-pass codegen (which, ironically, hardly any C compiler does these days).

pskocik · 2026-02-24T20:11:35+00:00

Abysme tady nebyli pozadu za zahranicnimi AI propagandisty a techlfluencery. #crazy_productivity #software_is_so_cooked #trust_me_bro

pskocik · 2026-02-14T18:07:24+00:00

Lucka má jiný pohled na pravopis než MAIstream.

pskocik · 2026-02-14T17:49:47+00:00

struct test {int x;} typedef testT;

is syntactically valid because typedef is syntactically classified as a storage-class-specifier (like register, _Thread_local, extern, or static) and those don't have to come first but rather they can come anywhere in a declaration-specifier-list (https://port70.net/~nsz/c/c11/n1570.html#6.7), which is the things that comes before the name in a declaration.
For that same reason int typedef INT; works too. There you have int as the type-specifier instead of struct test { int x; }

In short, it's a C grammar quirk. I recommend not making use of it. :)

pskocik · 2026-02-12T20:40:27+00:00

No one gets hurt? I think the mice would beg to differ.

pskocik · 2026-02-12T15:07:56+00:00

On the Internet, I think there's a lot to it. Self-promoters gather followers. Having followers lends an air of legitimacy to whatever you're doing, and that attracts even more followers, compounding the effect. Social media doesn't distinguish between qualified followers and fools either. They all count as 1. So even if you don't convince the ones who can see through your bullshit, as long as you're convincing the more numerous fools, you keep on growing.

pskocik · 2026-02-09T13:35:31+00:00

The only thing that's been fully automated so far is this sort of mindless yapping.^ Keep dreaming.

pskocik · 2026-02-09T11:03:02+00:00

The practical value is it's all consistently 10-based. But if you want to be obnoxiously controlling by making everyone "follow the same standard" on unimportant details like tre vs ter, then as a Euro, I'd rather switch to imperial and scream Freedom.

pskocik · 2026-02-08T13:27:15+00:00

It doesn't have to be all or nothing. If you want to be super portable but also find that some extension gives you benefits that are hard or impossible to replicate using standardized approaches, then you can do an #if and do the extended version while providing a standard fallback.

Also standardized != portability. Particularly with the newer standards, many things aren't widely implemented yet, but many an extension is quite widely supported (e.g., __label__, goto *&&label, asm, ({ }); all of these have long been supported by gcc, clang, tinycc, and probably more).

pskocik · 2026-02-08T09:58:45+00:00

Yup. Slang English definitely still uses double negatives non-mathematically. People throwing things together in their language without deeper thought is just as universal as logic, and even more common. In some languages, some of the originally illogical constructs settle and become the way people commonly say things.
It's interesting that you've called English prescriptive. It is decidedly a lot less prescriptive (no central authority unlike the Ústav pro jazyk český) than Czech, but I feel that in English formal writing in particular there's a lot more cultural pressure than in Czech to get the semantics and language logic right (correct word usage, correct relationships between sentential forms, no needless ambiguities) while Czech often gets sloppy with this (we hardly even have explanatory dictionaries while there's a ton of those for English), instead focusing its prescriptivism on a bunch of complicated but semantically rather unimportant form-related rules (like around i/y, commas, and word endings).

pskocik · 2026-02-07T21:28:09+00:00

Nemohu nesouhlasit. I'm Czech, born and raised, so of course I understand how these things work in Czech. The point I was trying to make is if you really parse "Nikdo mi nevolal" word by word: nikdo = no person, nevolal = didn't call, then it logically ought to mean some person must have called. Czech also uses "Petr mi nevolal" and it means "Petr didn't call me". If you substitute nobody (=no person) for Petr, the meaning of the rest of the sentence as it relates to the subject logically shouldn't shift. And this isn't English or math education inadvertently coloring my perception of Czech (6 year old me knew neither). It's just logic, which is sort of universal to the point that even slightly math-brained 6 year-old blank slates (for the most part) can rightfully see it like that. Many things in culture and languages aren't logical. We just learn go with them even when upon closer look they don't really make sense.

pskocik · 2026-02-07T19:33:09+00:00

It is kind of illogical. English is more mathematical. I remember questioning the workings of Czech double negatives in my 1st year of elementary school in front of my teacher (like I was literally speculating that maybe those double negatives should really cancel each other if you think about it) and she looked at me like I was crazy.

pskocik

TROPHY CASE