Wiring pi is defunct.

WiringPi certainly does work with Pi 4, I have used it myself on Pi 4. 

However, it is not maintained (the author doesn't wish to maintain it anymore), so it won't work with Pi 5 at all (unless someone adapts it, which the original author I think doesn't have an interest in pursuing). There is a list of alternatives (some are for Python, but there are some listed for C) here: https://raspberrypi.stackexchange.com/questions/117591/controlling-raspberry-pi-gpio-with-c-and-python

However, I've not tried any alternative personally on Pi 4. With C, I've only used WiringPi on Pi 4.

I suspect some people (those that need it for, say, a job and thus have the time - several days of effort to do it properly) are directly programming registers (i.e. do a mmap, followed by writing/reading the registers that are mapped) for the particular Pi they are using, and effectively creating their own API. I've had to do that myself on some platforms (e.g. BeagleBone Black), but it's a lot of effort to initially do, and to maintain. 

In summary, if it's only Pi 4 that interests you, and you wish to use C programming, then WiringPi should work. Otherwise, if you may eventually want Pi 5 support too, you'd need to choose a different library (e.g. pigpio, but there are various options at that link), which today may not work for Pi 5 but at least has a chance of being supported eventually, if it is actively being maintained currently, or create your own.

If you don't need fast GPIO, then there are other options (e.g. using /sys/class/gpio) but those are slower. Not every application will need speed, so that may be a possibility. 

Yet another possibility is to use SPI or I2C (e.g. SPI or I2C GPIO expander) and avoid the WiringPi and its alternatives altogether since you'd be using the normal Linux i2cdev or spidev API, which will always be supported (unless something better comes along one day).

Here's yet another, more generic, C programming option for Linux, which looks to be quite active in development but is not found in that list. Have yet to test performance...

github.com/.../c-periphery

Nice find. Regarding your performance comment, I think for general I/O they have a wrapper around /sys/class/gpio, so it won't be super-fast, but most users just want a wrapper anyway, with a simple API, so it should still be fine for a lot of purposes.

I'm currently writing a direct register access API for a different board that I need to use, it's going to be basic because I don't wish to maintain something complex. but I wish SBC manufacturers had standardized on a way to make it simple for C/C++ developers to use fast access without having to delve into tech ref manuals, e.g. some C/C++ API framework and a config file that was tailored for the processor/SBC.  I wish raspberrypi.com had taken the initiative and come up with something like a framework that any SBC supplier could use to implement GPIO with the same underlying API calls. That way, people could modify apps to suit Pi 5, 6, etc or other manufacturer boards too.

A few things that would be useful for that would be the ability to write an API on top (such as DigitalIn/DigitalOut for those who want an Arduino-style API), plus the ability to map different identifiers. For instance, if a different SBC used completely different GPIO pins, it would be good if they could be mapped to Pi GPIO numbers (if people were porting code), or even map to physical pin numbers if desired. Lots of SBCs have a 40-way connector, but of course, the registers will be different.

Also, as well as C++, such a library would also be linkable to C code (since some legacy stuff might not compile as C++ without a load of errors).

All that, plus maintaining it, is quite some work for an individual, but a nice constrained, not-insurmountable uni project for a sponsored student for raspberrypi org etc.

I'm checking out the memmap register access on the RPi. To test if I can plug in another implementation in the little oo lib I made. Got sidetracked by LoRaWAN things

I'm checking out the memmap register access on the RPi. To test if I can plug in another implementation in the little oo lib I made. Got sidetracked by LoRaWAN things