1. The 6502 is heavily register-starved. Three limited-purpose registers is pretty rough.
2. There are no 16-bit registers, so you can't put a pointer in a register. You can put one on the zero page, but that's much more limited. Indexing into arrays larger than 256 bytes gets complicated, too.
3. The 6502's stack isn't well suited for storing data. There's no SP-relative addressing, for instance. It's possible to get the value of SP with PHP/PLA, but this is pretty awkward to work with.
I wrote a self-hosting (if you're very patient) compiler for the 6502 and Z80 a while back. Both are a bit of a shock if you're used to true 16 bit arch architectures. I did a couple of writeups on the problems of doing basic arithmetic in them:
The 6502 is more orthogonal, and while each instruction does less they're very fast; the Z80 is fundamentally more powerful but weirdly inconsistent, terrifyingly slow, and the unorthogonal register system means that you spend half your time shuffling registers.
Re: pointers, the same problem applies to int, which was always at least 16 bits. The 6809 and 8080/Z80 had 16 bit register (or register pairs) so must have been much better targets for C (among 8 bit machines).
It has a 256 byte stack, no multiplication/division, and if you look at typical 6502 code, a lot of it tends to be self-modifying - e.g. modifying the location of the most-significant-byte of addresses to copy more than 256 byes for example. That's a reasonable-ish thing to do when you have tens of KB of RAM available and can easily keep track of everything that's going on. But it's not very C friendly. It's certainly possible, and there are multiple C compilers as well as compilers for other languages, but most of the machines it's used on are small enough that using assembler and some macros tends to be closer to the sweet spot.
There are a number of c compilers for 6502. They all produce bad code and/or stray quite far from c. Looking at the architecture sort of explains why. Things c needs, it makes hard to do (pointer math, reasonably sized stacks)
1. The 6502 is heavily register-starved. Three limited-purpose registers is pretty rough.
2. There are no 16-bit registers, so you can't put a pointer in a register. You can put one on the zero page, but that's much more limited. Indexing into arrays larger than 256 bytes gets complicated, too.
3. The 6502's stack isn't well suited for storing data. There's no SP-relative addressing, for instance. It's possible to get the value of SP with PHP/PLA, but this is pretty awkward to work with.