Using Claude Code for embedded work

[Siwastaja]

The cosmic particle comment was referring to buffer overflow checks located behind other buffer overflow checks, so if e.g. the ETH hardware hard-limits the packet size to x, there should be no way to exploit a buffer overflow with bigger packets. But a particle could corrupt memory, etc...

Way more important risks, than cosmic particles, are,
1) accidental misanalysis of if it really gets covered elsewhere. It can be colossally hard to actually prove - you think you are covered, but are not. On the other hand, AI is pretty good nowadays for doing such analysis - so if you really want to count on this "can't happen because checked elsewhere", ask it re-check if it's having a false positive due to "checked elsewhere"
2) someone deciding to refactor / modify / add a new feature / reuse the code - that changes the whole thing.

Simplest, easiest, safest is to check locally "everywhere" (within sanity). The extra code writing effort is easily saved back; even if in 1 of 100 cases either of my above points hit, writing the other 99 checks was much less effort than dealing with the very difficult bug.

But the real reason to avoid the check is performance (code size or speed). Sometimes you just can't afford the local check and have to trust a further-up in chain check. Then: be careful.

[paulca]

The cosmic particle comment was referring to buffer overflow checks located behind other buffer overflow checks, so if e.g. the ETH hardware hard-limits the packet size to x, there should be no way to exploit a buffer overflow with bigger packets. But a particle could corrupt memory, etc...

"Packet" or "Frame"?

A ethernet frame is a singular entity that does not support fragmentation.  The IP packet however supports fragmentation and reassembly.  There are known attacks to exploit this.

Your "client only" and "behind" NAT is good, but not full proof.  Depends on your customer/market.

The part most people in here ignore is the "They are already in your network." problem that Enterprise have to work with.  If you cannot trust all other devices and software on the network all at once, then you have to assume somewhere it's been compromised.  Thus, even internal "LAN" based equipment and software has to be as robust as if it was on the Internet.

To put it another way.  In my job, I can't just list "exploitable code" and say, "It's okay, its not exploitable because we bound check it in these other places and it cannot manifest.

The result will be exactly as you would expect.  "Just fix it."  You know it's there.  You know it could be exploited, there is a fix for it.  Not doing that fix is seen as being unprofessional.

As Siwastaja mentioned, unless you have a "heavier" technical justification not to.

"We don't need to bother.", gets you fired if it turns out you did need to.  Fired or summoned by the FCA/SEC for criminal charges.  The twist in that tail, is, they are first going to ask, "Did I accidentally leave the security hole or did I leave it on purpose."

[paulca]

Even Brave AI could give me these:

CVE-2026-8836 (May 2026): A critical stack-based buffer overflow in the SNMPv3 handler allows remote code execution by manipulating packet arguments. This proves that parsing logic without strict bounds checking is fatal.

MQTT RCE (Bug #61480): Demonstrated that integer overflows in length calculations allow attackers to overwrite up to 65KB of memory, leading to full device compromise on unprotected MCUs.

These are related and active right now exploits.

Also.  Consider this.  Your device is pointed at an IP (your backend server).  Probably trusted by it.  What happens when someone, somewhere, even on the local LAN compromises it?  Now you have a rouge client problem.  Thats quite different.  Can you lock out "one" device without locking them all out?

[peter-h]

I fed the above to Claude (having given it all my relevant code):

Both of those are irrelevant to your deployment:
CVE-2026-8836 (SNMPv3): You're not running SNMP — it's not enabled in your lwipopts.h and the product has no SNMP handler. No attack surface.
MQTT RCE (Bug #61480): You're not running MQTT either. The product uses HTTP (your own server), HTTPS (MbedTLS client for cert update and healthcheck), and NTP. No MQTT client or broker.

The part most people in here ignore is the "They are already in your network." problem that Enterprise have to work with.  If you cannot trust all other devices and software on the network all at once, then you have to assume somewhere it's been compromised.  Thus, even internal "LAN" based equipment and software has to be as robust as if it was on the Internet.

That's a nice ideal but reality gets in the way. For a start, now you cannot have anything on the LAN unless you wrote the code / have sources and had them analysed. That's rather limiting

In reality, security is done in layers.

And it cannot be discussed in one-liners.

For sure, in the IOT scenario where you have a common server they all call up, if that server is compromised then you have a problem, but you control that server all the time. It is not 10,000 boxes deployed by your customers all over the place which are not physically accessible, or which you do not want to firmware-update due to the obvious (terminal!) business risk.

[paulca]

That's a nice ideal but reality gets in the way. For a start, now you cannot have anything on the LAN unless you wrote the code / have sources and had them analysed. That's rather limiting

In reality, security is done in ALL layers.

I fixed the later part for you.

Your former point is basically claiming that "Least Trust Principle" and "Zero Trust Principle" doesn't exist.

In reality it looks like...  each service, compontent, operation is treated as being potentially compromised.  So it's clients are suspicious of it.

In the first order it means that if you have 5 components on the "private" network, they all MUST have authentication and encryption in flight.  Clients of services must validate the services is what it says it is, and the service does the same for clients.  Multi-layer, multi-factor auth and SSL.

Yes it takes up about 50% of your time.  It depends on the cost of a failure/breach and it's blast radius.

This feeds back into design.  You split components and layers to move the actual sensitive and critical bits into their own isolated and protected space with user/auth tightly controlled  and audited, leaving the other components to be "lower risk".

To temper your framing a little in the right direction.  Stop thinking in "onion ring models", that is out of date.  It is not longer used that way or on it's own.

Start by doing this: "Draw your entire project, from clients, devices, servers, databases, discs etc."  Imaging it was a job interview.

The digram you get will have lines on it connecting components by some form of relationship of dependency or interaction.  These are the things you secure.  At ALL layers.

The question an InfoSec person will ask of it is....  "What if this bit gets hacked?"  How have you limited the blast radius?

[paulca]

A balancing point though, in your court.

"Suggestions" online claim at least 4Mb of RAM and 16Mb of flash for a full enterrprise integration with something like AWS or Azure.  Both AWS and Azure have integration packages for STM32.  Highly security envs will require TPM modules and other MCU functional blocks.

So.  $$$$$.

Without that size of memory/flash you end up having to cut bits out, lower security and increase it on the server side.

[peter-h]

Completely unrealistic.

[Siwastaja]

These "full enterprise integrations" increase security in one very specific way: not the actual data security, but they increase your personal security, because no one got ever fired from buying IBM integrating metric shit-ton of random junk from Amazon or Microsoft.

But it's also like McDonalds. You are very unlikely to get acute food poisoning. But then again you slowly poison yourself with crap.

Choosing differently reduces mean quality but increases variance (so best case quality increases significantly, too): you possibly are building a lot better system, also better in security, and best of all, something that does not participate in that huge "all eggs in the same basket" event we will read about all over the newspapers when the world stops for a day, which happens semi-regularly. (And that's exactly important for the personal security part: when that happens, everyone gets a free pass! "It was something we never could have though about", "we did our best", "we used the industry best practices". But if you are an engineering-minded, like me or peter-h, we might give zero value for this. We want a good solution, not a solution our bosses like - maybe we are the bosses ourselves!)

But it also means the opposite: you possibly are building a horrible hack with gaping holes, which the Microsoft solution would have avoided.

AI changes the game somewhat. It gives more power to exactly those who roll their own solutions. Which I find great. Less dependency on one-size-fits-all packages, frameworks, libraries; more new code written, analyzed and tested - and I know this horrifies some, but for me it's the opposite; new code can be tightly scoped; custom solutions are efficient and smaller; with AI the power to do those is within the house; and the heterogeneity itself provides significant protection against attacks.

The theory is that analyzing new code is magically hard, nearly difficult, and old "battle-tested" code is near-perfectly analyzed and can be assumed nearly perfect. Couldn't be further from truth, and AI has also exposed this: new bugs are found all the time from "assumed-good". What really matters is complexity and correct scoping, and large existing solutions exactly struggle here: they start from a very bad position (massive projects with a lot of legacy crap accumulated, implementing unnecessary (for the project) features increasing attack surface) and compensate only with the sheer amount of real-world usage they have seen. New code is the opposite, it starts much more lean but lacks the battle-testing.

So we will be partially reverting the good learnings ("don't reinvent, reuse") that were good but we went too far with them, and will be returning partially to "everyone does whatever they feel like doing" of 1970's-1980's - but this time with with much more powerful tools.

[paulca]

To set the stage as I see it.

Embedded world and MCUs have, since their inception been almost entirely, "Local device specific."

This presents the standard model of hardware which is... "if the have physical access it's game over anyway."

And, for even things like Aviation that might even be enough.

What happened to the engineering mindsets there was, "Security is solved".

As to how correct they were is open for debate, but the problem is simple.  Today the embedded space is reaching out into the enterprise space and getting "connected".  IoT - if you must use the buzz word.

I'm not necessarily talking about "The cloud".  I personally predate the cloud in the role.  Even "on prem bespoke" when connected changes the playing field dramatically.

I don't believe the embedded space needs to go "fully AWS/Azure" integration level, but it needs to stop thinking that the security is solved.  A LOT of things have changed in the past 10 years and not just with cloud.

The next argument I see is this "ring fencing" or "onion ring" model.  The reason that does not work particularly well is that people in companies often have multiple roles.  People in your company are your "Number one" security risk by a significant margin.

The argument, "Well they had admin, they made a mistake, they trashed the data and took the company down for a day, not my fault gov." just doesn't wash anymore.

In that vein if you have an industrial device in a factory somewhere which has  LAN ETH port.  It's purpose is possibly to turn the device on and off from a control board or change parameters.  In the "old" world it was assumed that people were honest and also that they number of people who would know how to tamper very rare.

That is not the case today.  What if, when the engineer who looks after that is on leave and it fails and "That curious kid doing the computer degree decides to have a go at it."  There are bad results.

What if he told nobody he did that?  Covered it up, said nothing.

Security at 'every' layer and interconnect.  That's where that comes from.

[Siwastaja]

What happened to the engineering mindsets there was, "Security is solved".

Clearly, exactly that happened.

The only problem - it isn't true. Security is far from solved. Security is huge amount of work going on all the time. One of the problems is, trying to even discuss about security in any meaningful, deep way, in the context of making your system as secure as possible, turns into a shitfest of "we mere mortals don't need to care, know or understand. Security is difficult, black magic, and solved. Just do exactly what the big boys tell you to do."

And don't get me wrong - this seems to work quite well! But it's valuable to understand that just like there is a significant risk of "rolling your own security", there is also a risk in using the "known good solved everything" - especially when it means everyone using the same provider or two (AWS or Azure), and that risk actually also realizes; we do have real security issues - systems get broken into; people do get their money stolen out of their accounts due to poor security design we can't affect; botnets formed from systems developed with the "best practices" ddos other, innocent systems, and so on.

And when someone tried to follow all the best practices and it fails, we hear either:
A) You wasn't following the "big boys" instructions closely enough, so your fault; proves the "security is solved" is still right,
B) "Big boys" did something wrong, yeah, but because the whole world was affected, it's like force majeure, it doesn't count, so "security is solved" is still right, la la la not listening.

I applaud all of those who reinvent their own security. They have some balls, so to speak 

[paulca]

It flows with the hardware "reality" though.  Once created and out to shipping the product is DONE.  Fixed.  Can never change.  Close the books.  If the requirements change, then its all the way back to engineering to spin a new product version.

The modern networked world does not run on that model though.

The net point.

Security is not a "place", it's an always moving target a game of cat and mouse that will never end.

Getting caught by a "zero day" or a "Specifically targetted and determined attacker" is honesly forgivable.

Getting caught out by a 12 year old script kiddy with a scanner/root kit so old it's now "FREE"... that's embaressing.

[paulca]

Maybe a good a place to start as any:
https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10

Looks like it got archived into a github private repo.  The irony.
https://owasp.org/www-project-internet-of-things/

[gspeed]

My experience:

1. LLMs are great at reading datasheets, examples and codes. However, you must check everything yourself, and not believe a word of theirs.
2. They are good at writing Makefiles and other boilerplate. Sometimes they can help with structuring tests, but too often they test 1+1=2 (and would write another test case for 1+2=3).
3. They are good at initial bringing up and testing of peripherals and hardware, often producing working code on first try.

For everything else they are absolutely rubbish. Especially for embedded C, they WILL produce unreadable and unmaintainable slop, and they WILL do it very quickly.

[peter-h]

LLMs are great at reading datasheets

They do use up a lot of "money" reading data sheets though. I've just exhausted my free Claude allowance with one reference to a data sheet on a wifi chip, on mouser.com. I have the £150/year paid-up Claude also and that does it OK but if you do a few of them, it will also postpone you for some hours.

Especially for embedded C, they WILL produce unreadable and unmaintainable slop

I think it depends on how bad is the stuff it found on github. etc Claude doesn't actually "write code" like you or I might. It does pattern matching. If you ask it for C code to draw a rotated isosceles triangle, using scanlines, it will probably give you a working algorithm. I've just timed it at 7 seconds:

Code: [Select]


/*
 * Draw a filled isosceles triangle, rotated by angle_deg degrees.
 * The triangle is defined by:
 *   cx, cy    - centre point
 *   base      - full base width in pixels
 *   height    - height in pixels (apex to base midpoint)
 *   angle_deg - rotation in degrees (0 = apex up)
 *
 * Uses scanline fill. Calls set_pixel(x, y, colour) for each pixel.
 * Requires sinf(), cosf() from math.h or a lookup table equivalent.
 */

#include <stdint.h>
#include <math.h>

// These need to match your display dimensions
#define DISPLAY_W 320
#define DISPLAY_H 240

// Replace with your actual pixel write function
extern void set_pixel(int x, int y, uint16_t colour);

static inline int mini(int a, int b) { return a < b ? a : b; }
static inline int maxi(int a, int b) { return a > b ? a : b; }

void draw_rotated_triangle(int cx, int cy, int base, int height,
                           float angle_deg, uint16_t colour)
{
    float angle_rad = angle_deg * (3.14159265f / 180.0f);
    float s = sinf(angle_rad);
    float c = cosf(angle_rad);

    // Define the three vertices of the unrotated triangle
    // Apex at top, base at bottom, centroid at origin
    // Centroid is at height/3 from base, 2*height/3 from apex
    float third = height / 3.0f;

    float vx[3], vy[3];

    // Apex (top)
    vx[0] = 0.0f;
    vy[0] = -(height * 2.0f / 3.0f);

    // Base left
    vx[1] = -(base / 2.0f);
    vy[1] = third;

    // Base right
    vx[2] =  (base / 2.0f);
    vy[2] = third;

    // Rotate and translate vertices
    float rx[3], ry[3];
    for (int i = 0; i < 3; i++)
    {
        rx[i] = cx + vx[i] * c - vy[i] * s;
        ry[i] = cy + vx[i] * s + vy[i] * c;
    }

    // Find bounding box y extent
    int ymin = (int)ry[0];
    int ymax = (int)ry[0];
    for (int i = 1; i < 3; i++)
    {
        if ((int)ry[i] < ymin) ymin = (int)ry[i];
        if ((int)ry[i] > ymax) ymax = (int)ry[i];
    }

    // Clip to display
    ymin = maxi(ymin, 0);
    ymax = mini(ymax, DISPLAY_H - 1);

    // For each scanline, find x intersections with triangle edges
    for (int y = ymin; y <= ymax; y++)
    {
        float fy = (float)y + 0.5f;  // sample at pixel centre
        int xmin_scan = DISPLAY_W;
        int xmax_scan = -1;

        // Test each of the 3 edges
        for (int e = 0; e < 3; e++)
        {
            int e2 = (e + 1) % 3;

            float y0 = ry[e];
            float y1 = ry[e2];
            float x0 = rx[e];
            float x1 = rx[e2];

            // Check if scanline intersects this edge
            if ((y0 <= fy && fy < y1) || (y1 <= fy && fy < y0))
            {
                // Interpolate x at this y
                float t = (fy - y0) / (y1 - y0);
                float xi = x0 + t * (x1 - x0);
                int ix = (int)xi;

                if (ix < xmin_scan) xmin_scan = ix;
                if (ix > xmax_scan) xmax_scan = ix;
            }
        }

        // Clip and fill the scanline
        if (xmax_scan >= xmin_scan)
        {
            xmin_scan = maxi(xmin_scan, 0);
            xmax_scan = mini(xmax_scan, DISPLAY_W - 1);
            for (int x = xmin_scan; x <= xmax_scan; x++)
            {
                set_pixel(x, y, colour);
            }
        }
    }
}


A few notes:

The centroid is used as the rotation centre rather than the apex or base midpoint — this gives natural rotation behaviour. If you want rotation around the apex instead, change `vy[0]` to `0` and adjust the base vertices to `height` below.

The edge intersection test uses the convention `y0 <= fy < y1` to avoid double-counting shared vertices between edges.

The trouble is that much of github is garbage...

[5U4GB]

My experience:

1. LLMs are great at reading datasheets, examples and codes. However, you must check everything yourself, and not believe a word of theirs.
2. They are good at writing Makefiles and other boilerplate. Sometimes they can help with structuring tests, but too often they test 1+1=2 (and would write another test case for 1+2=3).
3. They are good at initial bringing up and testing of peripherals and hardware, often producing working code on first try.

4. They are really good at acting as lint on steroids. Alongside language-aware SAST tools they can do a really good job of cleaning up inconsistencies in your code that you still haven't spotted despite multiple audits.

[paulca]

4. They are really good at acting as lint on steroids. Alongside language-aware SAST tools they can do a really good job of cleaning up inconsistencies in your code that you still haven't spotted despite multiple audits.

Yes.  However.  It's not coherent.  It's not deterministic.  Prove this to yourself by repeating code reviews on the code with clear sessions and slightly biasing prompts.

Stop when you get  bored.

If you can reach "coherence" between them.  You are moving into "mastery".  Some guy made a scale.  I think it's level 8.

I couldn't remember it, so I used my pattern matching friend to:

Steve Yegge's 8 Levels of AI-Assisted Development

Level 1: No AI
Level 2: IDE coding agent with permissions on
Level 3: IDE coding agent in YOLO mode
Level 4: Conversation over diff review
Level 5: CLI-first workflow; the IDE is no longer home
Level 6: Several parallel agents
Level 7: Ten-plus agents, coordinated by hand
Level 8: A custom agent orchestrator

Potential source: https://newsletter.pragmaticengineer.com/p/steve-yegge-on-ai-agents-and-the

---

Story from the trenches.  I gave claude agency to look at a ticket and plan an implementation.  A basic logging "gate keeper" "funnel" class.  "You shall all log via this logger".  Then it can be backed by whatever flavour of logging the platform team want that month.

Its first implement was exactly what I wanted.... except...

I asked it to review it for security issues caused by assuming the caller honors the required types.

SEV-1 security flaw.  Code injections.

The day went on like this.  "Have you considered?","Why are we?", "Do we really need?", "Doesn't that make it worse?"

Some people use "canned" agents with prompts to be adversery.  Do not compliment the code.  Tear it apart in the authors eyes, as claude probably wrote it.  It can get quite fun.  I want to see them arguing.

"To place the parallel agents into chat, get some coffee first and click here."   That might be funny.

[5U4GB]

Sure, you get a slightly different result every time, just as if a human were doing the checking, but eventually it converges a pretty clean solution.

That hierarchy is a bit off-target, it assumes you're using AI for coding and then breaks it up into lots of somewhat artificial subclasses.  I would start with 1 = "AI as lint" and go from there in terms of how much control AI has over your code.  Maybe 2 ="AI as lint with suggestions for changes", neither of which give it any control over what goes into your code.

[paulca]

Uh oh.  I started something.  What have I done?



I apologise, but I gave it your code from above.

 

[Siwastaja]

Yes.  However.  It's not coherent.  It's not deterministic.

That's why they are so good as additional review layer - coherency and determinism are relatively minor nice-to-haves, not more than that; every issue flagged is positive; and let's not forget it's not a one-way information flow, you can actually chat with it about the finding, and it will investigate more, which then improves the quality of the analysis compared to the early low-cost guess (which can already be crazily good, often).

It can't 100% prove something works, that's true. But often this isn't what people expect from a review anyway.

Coherency is more important when creating new code. Risks of doing weird things that go unnoticed is a real one, a risk that realizes all the time, the question is can you accept it or not? If it's not acceptable, then maybe limiting the use as reviewer is the cleanest, most beneficial first step of AI use. The productivity gain from AI finding 10 hard-to-debug issues can be huge already, a 5-minute analysis can save a full day. And if you are someone who has done this for a living for years or decades, one more day-long debug session is not going to teach you to be more careful the next time anyway. Maybe for a beginner not using AI but doing it manually "the hard way" is a good teacher?

[Randy222]

Sonnet or Opus?

[gspeed]

LLMs are great at reading datasheets

They do use up a lot of "money" reading data sheets though. I've just exhausted my free Claude allowance with one reference to a data sheet on a wifi chip, on mouser.com. I have the £150/year paid-up Claude also and that does it OK but if you do a few of them, it will also postpone you for some hours.

Especially for embedded C, they WILL produce unreadable and unmaintainable slop

I think it depends on how bad is the stuff it found on github. etc Claude doesn't actually "write code" like you or I might. It does pattern matching. If you ask it for C code to draw a rotated isosceles triangle, using scanlines, it will probably give you a working algorithm. I've just timed it at 7 seconds:

Code: [Select]


/*
 * Draw a filled isosceles triangle, rotated by angle_deg degrees.
 * The triangle is defined by:
 *   cx, cy    - centre point
 *   base      - full base width in pixels
 *   height    - height in pixels (apex to base midpoint)
 *   angle_deg - rotation in degrees (0 = apex up)
 *
 * Uses scanline fill. Calls set_pixel(x, y, colour) for each pixel.
 * Requires sinf(), cosf() from math.h or a lookup table equivalent.
 */

#include <stdint.h>
#include <math.h>

// These need to match your display dimensions
#define DISPLAY_W 320
#define DISPLAY_H 240

// Replace with your actual pixel write function
extern void set_pixel(int x, int y, uint16_t colour);

static inline int mini(int a, int b) { return a < b ? a : b; }
static inline int maxi(int a, int b) { return a > b ? a : b; }

void draw_rotated_triangle(int cx, int cy, int base, int height,
                           float angle_deg, uint16_t colour)
{
    float angle_rad = angle_deg * (3.14159265f / 180.0f);
    float s = sinf(angle_rad);
    float c = cosf(angle_rad);

    // Define the three vertices of the unrotated triangle
    // Apex at top, base at bottom, centroid at origin
    // Centroid is at height/3 from base, 2*height/3 from apex
    float third = height / 3.0f;

    float vx[3], vy[3];

    // Apex (top)
    vx[0] = 0.0f;
    vy[0] = -(height * 2.0f / 3.0f);

    // Base left
    vx[1] = -(base / 2.0f);
    vy[1] = third;

    // Base right
    vx[2] =  (base / 2.0f);
    vy[2] = third;

    // Rotate and translate vertices
    float rx[3], ry[3];
    for (int i = 0; i < 3; i++)
    {
        rx[i] = cx + vx[i] * c - vy[i] * s;
        ry[i] = cy + vx[i] * s + vy[i] * c;
    }

    // Find bounding box y extent
    int ymin = (int)ry[0];
    int ymax = (int)ry[0];
    for (int i = 1; i < 3; i++)
    {
        if ((int)ry[i] < ymin) ymin = (int)ry[i];
        if ((int)ry[i] > ymax) ymax = (int)ry[i];
    }

    // Clip to display
    ymin = maxi(ymin, 0);
    ymax = mini(ymax, DISPLAY_H - 1);

    // For each scanline, find x intersections with triangle edges
    for (int y = ymin; y <= ymax; y++)
    {
        float fy = (float)y + 0.5f;  // sample at pixel centre
        int xmin_scan = DISPLAY_W;
        int xmax_scan = -1;

        // Test each of the 3 edges
        for (int e = 0; e < 3; e++)
        {
            int e2 = (e + 1) % 3;

            float y0 = ry[e];
            float y1 = ry[e2];
            float x0 = rx[e];
            float x1 = rx[e2];

            // Check if scanline intersects this edge
            if ((y0 <= fy && fy < y1) || (y1 <= fy && fy < y0))
            {
                // Interpolate x at this y
                float t = (fy - y0) / (y1 - y0);
                float xi = x0 + t * (x1 - x0);
                int ix = (int)xi;

                if (ix < xmin_scan) xmin_scan = ix;
                if (ix > xmax_scan) xmax_scan = ix;
            }
        }

        // Clip and fill the scanline
        if (xmax_scan >= xmin_scan)
        {
            xmin_scan = maxi(xmin_scan, 0);
            xmax_scan = mini(xmax_scan, DISPLAY_W - 1);
            for (int x = xmin_scan; x <= xmax_scan; x++)
            {
                set_pixel(x, y, colour);
            }
        }
    }
}


A few notes:

The centroid is used as the rotation centre rather than the apex or base midpoint — this gives natural rotation behaviour. If you want rotation around the apex instead, change `vy[0]` to `0` and adjust the base vertices to `height` below.

The edge intersection test uses the convention `y0 <= fy < y1` to avoid double-counting shared vertices between edges.

The trouble is that much of github is garbage...

Actually if you're in need of some amusement, let it write protothreads (a useful C hack where local variables are forbidden) and watch it fail repeatedly.

[nctnico]

I disagree. protothreads is garbage. Making code look like something it isn't. Maintainability goes down the drain.

[SpacedCowboy]

I think there's a skill to getting things out of LLMs today. I think it takes effort, just not the same level effort as doing it yourself, and you might not need to know everything about the subject matter, but you do need to know sufficient to keep the LLM on the right track. I tell Claude 'no, <reasoning ...>' almost as much as I agree with it.

So when I see broad stroke "LLMs are useless" opinions, my immediate reaction is "you're holding it wrong" or (being more blunt, forgive me) "you don't know what you're doing". There is generally a good path to getting something useful from an LLM for pretty much any problem, but just like all twisty turny paths through the forest, you need some level of competence in taking bearings and reading the map. Just like, to pull a topic out of the air, embedded programming.

Similarly, when I see comments along the lines of "you need X million things on the internet about that specific subject for the LLM to come up with something useful", I disregard that as well. The entire point of a neural-network is to generalise from input data. The more (high quality) input data you can give it, the better it will do, obviously enough, but... And it's a big but, it can generalise from other patterns to make a good stab at solving your problem. That's sort of how they work. Sometimes they'll be wrong, you correct them, and they'll learn and adjust from that. Often better than people would.

I have an excellent (almost to the level of hand-tuned assembly) compiler for an obsolete processor that was written almost entirely by an LLM. That processor, yes, was very popular during its day, and still has its adherents, but it's a niche of a niche of the internet, and "its day" was actually prior to the internet; yet Claude could tell me that Read-Modify-Write was in significant use on C64 machines, but almost never used on Atari machines, so this optimisation could work here and that one was better there. The amount of internet real-estate dedicated to that is miniscule. You don't need that much source material for the data to be represented in the weights.

I think (and this may be an unpopular opinion I guess) there is a fair amount of copium going on when people decry the abilities of LLMs. I also think that these LLMs we have today are the worst LLMs we'll have in the next decade. They're only getting more and more capable, despite the cost in GPU time. More and more research is going into them, more and more effort is being directed their way. Even if an LLM can't do your job today, it's going to eat your lunch in a decade, IMHO, unless your job is dictated by art or taste rather than technical expertise.

Huh. Reading that back it comes across a little harsh, no offence meant to anyone - maybe I've been instructing LLMs (which don't have feelings) a little too much recently...

[5U4GB]

Sonnet or Opus?

I've found Opus better for code reviews. Sonnet does a more high-level analysis of the program design while Opus looks at the code details.

[paulca]

I disagree. protothreads is garbage. Making code look like something it isn't. Maintainability goes down the drain.

This is why most embedded code that claude writes is rubbish.  It's because embedded code "in the public" is full of "overdone" personal, hobby horse coding styles.

MACRO_LANGUAGES

for example. 

Usually there is nothing wrong with particular "concept", it's just the over application of it, or the application outside of context.

Consider an example from my line of work.

"Thou shalt make all method parameters final/const!"

The proponents are not lying and they are not wrong in many or most cases, however, they fail to see the downsides.

Consider a common flow like this:

aFunction( const anObject ) {
   const detainted = detaint( anObject )
   const normalised = normalise( detainted )
   const validated = validate( normalised )
   const domainModel = domain_map( validated )
  // etc.
   return finished_object
}

Five copies.  5 allocations.  All in scope.  Not even garbage collector will help you.  All done for EVERY call, EVERY time.  All decallocated each and every time, except the final return.  Large cyclic garbage collection = slow = high memory footprint.

Consider instead:
aFunction( anObject ) {
   anObject = detaint( anObject )
   anObject = normalise( anObject )
   anObject = validate( anObject )
   anObject = domain_map( anObject )
  // etc.
   return anObject
}

Now runtime optimisations can actually take effect, the memory footprint drops, recycle/reuse can be utiltised.

Note... this is not the same thing as "side effects".  The original "anObject" passed to the function is untouched.  Only the 'reference' has been reused internally.

This might seem trival until "anObject" is a 2 Petabyte distributed dataset.  Creating 5 copies of it is not what will happen at the metal... even if the code tries to tell you it does.  Nor is it const. 

Obviously if you are in C/C++ you need to be very careful how you manage your memory, but you should see that the "const" approach has issues if those functions allocate memory.  It's the same thing.  Except in "enterprise" languages where memory management is "runtime" people get lazy and don't see the wood for the trees.  I do. You either use the garbage collector wisely or it bottlenecks your performance.

"Thou shalt make all method parameters final/const!"
"It depends"