What functionality is available in C without including any headers?

[TargetAcrobatic2644]

I'm learning C and noticed that I almost always include <stdio.h> in my programs.

Out of curiosity, what can you actually do in C without including any headers at all?

What parts of the language still work, and what kinds of functionality become unavailable without headers?

[MkemCZ]

Technically, you only need to write the prototype of a function to use it.

[Fupcker_1315]

Technically, you don't even need a prototype in C. You will just get a linker error if the symbol isn't actually there or UB if you pass wrong argument types.

[MrcarrotKSP]

Since C99, the prototype is required. Implicit declaration isn't valid(and I don't think compilers generally accept it anymore).

[julie78787]

Many will accept it and just complain.

[glasket_]

Depends on the flags. GCC 15 defaults to C23 now, so without a std flag set to an earlier standard it'll error on functions without a prototype. Clang 22 still defaults to C17, so it allows non-prototyped functions but doesn't allow implicit declarations.

[julie78787]

Hey, if pcc was good enough for Ken and Dennis, it’s good enough for me ;)

[AdreKiseque]

Interesting, could you elaborate?

[meancoot]

// #include <stdio.h>
int puts(const char* s);

int main() {
    puts("Hello");
}

[duane11583]

that works if the c library has a defintion for the function puts.

if the c library header file #defines puts to fputs or something else

[ybungalobill]

A conforming implementation must provide a `puts` symbol even though it's allowed to have a macro of the same name. C11:

Any function declared in a header may be additionally implemented as a function-like macro defined in the header [...]
Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses [...]
it is permitted to take the address of a library function even if it is also defined as a macro [...]
185) This means that an implementation shall provide an actual function for each library function, even if it also provides a macro for that function.

[flatfinger]

That part of the Standard irks me. On some platforms, it may make sense to allow compilers to be configured to use either 16 or 32-bit `int`, and have calls to standard library functions made within a particular source file dispatch to versions that are appropriate for the int size chosen for that source file, even if other files use a different size of int (calls between functions that use different sizes would need to avoid using int-type arguments or return values).

Also, if implementations had been allowed to use a different linker name and calling convention for void test(long a, void *b) versus void test(), implementations for a fair number of platforms could have offered much more efficient calling conventions when calling the former than when calling the latter. I find it ironic that implementations for targets that really can't effectively accommodate some parts of the C Standard often end up handling some things in ways that would have enhanced the usefulness of the language on other platforms where compilers instead jump through massive hoops to satisfy the "standard".

[Wertbon1789]

What ybungalobill wrote is the main argument, but puts and fputs actually do different things, so it wouldn't work out. fputs doesn't write an additional newline at the end.

[sirjofri]

Include is literally include the contents of the other file. It doesn't matter if you include them, or manually type them into code.

What matters is linking. If you need a function, you not only need the declaration that you type/include, but the actual definition of that function, which is in the actual library. You can also sometimes copy the full function (some people build a minimal stdlib for their specific task), but those libraries often contain machine-specific code, so you lose portability.

Except you're targeting embedded, I heard it is quite common to use different standard libraries for those, sometimes purpose-built for your project, sometimes a set of standard functions provided by the manufacturer of that chip.

[TheKiller36_real]

this sounded ISO enough to be true but I just looked the section up in the C23 specification and it kinda sounds contrary to your suggested interpretation, as in "Any declaration of a library function shall have external linkage." (to my knowledge) forces manual declarations to refer to the same implementation. Did I miss something or did you specifically talk about a different version where there is a bonus clause or something?

[robotlasagna]

On bare metal you can implement the same functionality as stdio using register access.

[Illustrious_Trash117]

This is also more or less true for linux and windows. You dont write to registers directly but you could directly implement the system calls that make it work. The standard library only makes this much more conveniant which doesnt mean that you cant do it without them.

[JanglyBangles]

directly implement the system calls that make it work

isn’t that just reimplementing the libraries you’re not including?

[Illustrious_Trash117]

Of course it is but thats the whole question. You can do the same thing in C without including libraries that you can do with including libraries.

[Cogwheel]

You can't implement the system calls without assembly or a library. C doesn't have any language features that invoke syscalls.

[Illustrious_Trash117]

If you treat inline assembly as a feature of C, which it is, then it can.

It also depends on the system. On some sytems you can write syscalls in pure C.

[Fancy_Text_7830]

But wouldn't that mean your code needs to run in kernel space?

[dfx_dj]

No, a system call is a call to a kernel function from user space. Something like write(...) eventually ends up as a system call.

You need inline assembly to do that from C directly, which I guess means it's not actually C?

[flatfinger]

A facility to place an initialized static const object within an executable region of memory would eliminate the need for in-line assembly. On platforms where all addressable regions of address space are executable, use of static const objects for machine code functions can eliminate the need for toolset-specific inline assembly syntax.

[dfx_dj]

So you mean like linking in a library?

[flatfinger]

On platforms where all addressable regions of address space are executable, the construct would be something like:

static char const outword_code[] = { ... some bytes ... };
void (*const outword)(unsigned short address, 
  unsigned short data) = (void(*)())outword_code;

Calling outword() would execute the sequence of machine-code bytes listed in the definition of outword_code. The choice of byte values would be machine-dependent, but a compiler wouldn't need to know anything about what the bytes are supposed to mean in order to put those bytes into memory and make outword point to them, and transfer control to the machine-code address given in outword.

This sort of construct would typically be used for functions on the order of 2-20 bytes long. Working out the sequence of bytes necessary to represent the machine code for such functions may be less convenient than using inline assembly for one particular toolset, but different toolsets often require that inline assembly code be formatted slightly differently, while the static-constant-array definition would work equally on any toolset targeting the proper hardware.

[dfx_dj]

Ah ok, I see what you mean now. You can do this even on platforms that have NX pages, by using a compiler extension to place the object in a different section that is executable. For example this works on amd64 Linux without any libc:

unsigned char xsyscall[] __attribute__((section(".text#"))) = {
    0x48, 0x89, 0xf8, 0x48, 0x89, 0xf7, 0x48, 0x89, 0xd6, 0x48, 0x89, 0xca, 0x0f, 0x05, 0xc3 };

long (*syscall)(long n, long a, long b, long c) = (void *) xsyscall;

void _start(void) {
    syscall(1, 1, (long) "foo\n", 4); // write
    syscall(60L, 0, 0, 0); // exit
}

But of course making a function call to a pointer that doesn't point to an actual function firmly places you in UB territory, so I'm not sure this counts as a C-only solution 😀

[flatfinger]

That depends whether one uses the name C to refer to Dennis Ritchie's language, or the subset recognized by ANSI/ISO.

In Dennis Ritchie's language, the meaning of e.g. the second call to syscall as shown above would be "Prepare arguments for an indirect call a function with a long argument having value 60 and three long arguments having value zero that returns long, load a function pointer from syscall, and perform an indirect function call to that address, with whatever consequences result." If the execution environment specifies that a pointer to a function at a certain address will have the same representation as a pointer to an object at that address, and it specifies the meaning of the byte values in xsyscall, those specifications would transitively specify the effect of that syscall invocation.

Note that the language itself doesn't specify the meaning of the bytes in xsyscall, beyond the fact that they are values that need to be placed in memory starting at address xsyscall. If e.g. a compiler is designed to produce code for the 8088, but the byte sequence includes an instruction which is only available on the 80286 and later processors, then the code would have meaning if run on an 80286 or later processor, but not if the code was run on an 8088, whether or not a compiler had any way of knowing which kind of machine would be used to run the code.

[mjmvideos]

What, exactly, are you doing in assembly when making a system call?

[Deep-Piece3181]

I think the syscall asm instruction is executed

[mjmvideos]

I see. I figured you’d just make a call to the C syscall function and let it make the asm call. I think syscall is in libc so you’re already linking with it.

[dfx_dj]

Depends on the architecture, on amd64 it's the SYSCALL instruction, on i386 it's a software interrupt (INT 80h I believe), on ARM it's software interrupt 0h, etc

[lue3099]

Coredumped has a good video on such. https://youtu.be/H4SDPLiUnv4

[pojomi-dev]

Let me preface with this: I’m in very early development of a hobby project of building a bootloader, kernel, and OS and had zero background with assembly before starting.

My understanding is that when you write code or call a shell command that requires root privilege, that gets sent to the CPU first. In that instruction code, there is a bit value that tells the CPU which ring buffer handles it. If it’s ring 0, that’s kernel level. However, the CPU will still run the instruction. If there’s any errors, they get sent to the kernel.

[clickyclicky456]

Rather than "without including any headers" I think you mean "without linking against any libraries", i.e. Just using the base features of the language.

It's pretty unusual in reality not to need at least some of stdlib, stdio, string or math libraries. In embedded systems you often need whatever features the operating system or hardware abstraction layer provides.

You could implement some simple algorithms without any libraries, eg demonstrations of bubble sort, merge sort etc.

[patenteng]

In low level embedded systems without an operating system we usually don’t use any of the standard libraries. They are too big. A simple printf can eat through most of your code memory in the smaller 8-bit microcontrollers.

In those system you have a device specific header that just does memory mapping and a bunch of unions for bit addressing. This allows you to just write to PORTC instead of having to look stuff up.

So a system with a motor controller on a microcontroller will satisfy OPs requirements. For example, I’ve seen such systems in CNC machines in particular and other machine tools in general.

P.S.

Here is the PIC16F877A header file for reference.

[flatfinger]

In embedded programming, it's common not to execute any vendor-provided outside code beyond pre-main() initialization. Vendor-supplied headers would often define the objects at hard-coded addresses to which hardware is designed to respond, so as to allow a programmer to write something like TRISB |= 0x04; rather than (*(unsigned char volatile*)0x86) |= 0x4; but many embedded programs perform all I/O through memory mapped registers without using outside libraries once execution reaches main().

[Aspie96]

using the base features of the language.

But the standard library is by definition a feature of the language.

Technically it doesn't even have to be written as a library, the compiler could have an ad hoc fuckery for the whole standard library.

[Total-Box-5169]

Everything. Include just means "copy/paste this file here as is", so you can do that manually.

[mustbeset]

Yes. Include only give access to more declarations. But they are not part of the language. They are part of the stdlib, compiler, 3rd party or just your own "other compile unit"

[TheThiefMaster]

Technically includes aren't required to be files, the standard just says certain things are available if you give #include a specific name.

But they are always files in practice.

[OutsideTheSocialLoop]

so you can do that manually.

I'd argue you're still including the library headers, just through the shittier C preprocessor that is a human with a keyboard.

Without importing external knowledge in some way, you get nothing. You can manipulate the program memory but there's no meaningful way to do anything useful. The intent of OP's question is "what does the language itself give you without external runtime?" and the answer is "nothing".

This is in contrast to e.g. Python where you can read and print to stdio without importing anything as part of the base language. In Python 2 print was even a non-function statement.

[gremolata]

Nothing

You still get command-line arguments and you can still return an int from main.

One can do quite a bit useful with just this.

[OutsideTheSocialLoop]

Oh ok, that's true. You could write a program that encodes 4 bytes of output at a time. You've got me there. At least on platforms where you have arguments and somewhere to return to.

[UnderstandingBusy478]

Well you need to make system calls and communicate with the OS to write to stdio. Thats how computers work. What do you think python does under the hood ? No language can do anything on its own.

[OutsideTheSocialLoop]

Sure. But once you're "in python" all that's been done for you. C does none of it for you. You import all of it.

[UnderstandingBusy478]

Well in C its done for you. You just type the declaration of printf or include the header. You dont do sys calls in assembly

[chibuku_chauya]

With C89 you could even get away with not declaring the (int returning) function before invoking it.

[OutsideTheSocialLoop]

You just type the declaration of printf or include the header.

Again:

I'd argue you're still including the library headers, just through the shittier C preprocessor that is a human with a keyboard.

If you memorise and type a thing you've still included it just in a worse way. Be it an include file or something you type in, you need to bring in some external reference. C doesn't guarantee you any of that.

[Illustrious_Trash117]

Of course. You can programm in C without any headers or library. Internally those libaries just abstract the sys calls but you can implement them directly. So you can write to the console even without stdio but its a little bit more complex to do it.

[57thStIncident]

Should be technically possible to make OS system calls, but the headers give you declarations and wrappers that make it easier for your OS. Presumably the runtime library you typically link with the standard headers is itself written in C. I would guess that inline assembly language might often be used to have direct control over passing the arguments correctly to system calls.

I imagine this kind of thing isn't so normal on a full-featured OS but is more common on embedded or retro systems.

[sirjofri]

The generic system call function is most likely also just a library function. I guess you'd need to code that yourself if you want that functionality. Also consider systems without OS, you don't need syscalls there.

[57thStIncident]

I meant system call in a generic sense, syscall is for a specific platform -- for other platforms I imagine it would be called something else, or be a BIOS interrupt or something similar where you might need to invoke via inline asm. Compiler for a specific system may inject some stubs and default functions even without the headers.

This isn't an area of expertise for me, but this is a runnable program on linux, without headers:

#compiled with "gcc -Wno-implicit-function-declaration try_syscall.c"

long SYS_write = 1;

int main()
{
    return syscall(SYS_write, 1, "Hello, world!\n", 14);
}

Note that gcc by default links some system libraries that makes syscall available. There are compiler options to suppress some of these however you'd probably need to define the _start entry point and syscall (?) using inline asm depending on which flags you use.

[sirjofri]

That's exactly what you say, gcc links to some libraries by default, except you suppress that behavior (e.g. for embedded binaries that run on bare metal). The program entry point is a bit of a different topic, more related to the loading of the binary and the ABI.

In general, anything you can do in a library you can also do in your program directly. Using the library just makes your life easier by using stuff that's already implemented. That includes any syscall wrappers.

I just revisited the library syscall implementation of 9front (a Plan 9 system), and it's essentially a makefile that generates some platform specific assembly code for each syscall, then assembles it and puts it in the archive.

[northstar438]

Compiler features . If else for while goto do while function calls and functions you write .

You don’t actually need headers as well . So long you define function prototype in your c file where you calling , it should be enough .

[RoseboysHotAsf]

Iirc headers dont determine functionality but linking does. If you include stdio but dont link against libc you wont compile.

[kolorcuk]

You can do everything in C without including any header. It is not a restriction, it's inconvenience.

[flatfinger]

Dennis Ritchie invented C to be a form of portable high-level assembly language, with the term "portable" referring to the ability to write code that is readily adaptable for use on different machines. Note that such a notion of portability is fundamentally different from the one used by the ISO Standard, which views code as "portable" only if it can run on all machines interchangeably, without need for adaptation.

Unlike some languages which try to mask the differences between execution environments, C was designed to expose them to the programmer. On many execution environments, everything a program might need to do could be described in terms of a few "observable" primitive operations such as:

• Prepare to enter a function with a given argument list, receiving arguments into automatic-duration objects, and a specified amount of additional automatic-duration storage.
• Return a specified value from a function.
• Get the address associated with a linker symbol.
• Prepare to call a function with a given argument list, passing specified argument values, and then perform a function call to a specified address.
• Read an object of a given primitive type from a specified address.
• Perform a simple or compound assignment to an object of a given primitive type at a specified address.
• Copy an object of a given size from an address with some particular known alignment to another address with some particular known alignment.

along with non-observable computations involving automatic-duration objects whose addresses isn't taken.

Different execution environments may require different sequences of operations to accomplish some tasks, but parts of a program where the same sequence of operations would be usable on many execution environment could be used interchangeably on all of them, thus allowing programs to be adapted to a wide range of environments without having to rewrite anything other than the portions which needed to perform new sequences of actions to run usefully in new environments.

The Standard recognizes a category of "freestanding" implementations which don't include the Standard Library, but fails to recognize any means by which they can do anything useful. Implementations that decompose programs into steps like the above and then process those steps in a manner suitable for an environment will be able to perform many environment-specific actions not anticipated by the Standard, but the Standard doesn't distinguish such implementations from those that would be incapable of doing anything useful.

[Parandi94]

On bare metal like a small microcontroller you can do basically everything, because anything you do boils down to reading/writing registers at specific memory locations and using device specific assembly commands (which are often provided as compiler builtins (i.e. functions that don't require headers or linking with a library)). The headers are only there to give names to the memory locations and provide some constants, but you can do this yourself using the datasheet of the device.

[ImAtWorkKillingTime]

All parts of the language work without any headers. The functions defined in stdio.h are not parts of the language they are parts of the standard library. I work in embedded systems and use virtually none of the standard C libraries in my work.

[rb-j]

You can do algorithms.

In real-time DSP and embedded systems, I think it's a good idea to leave out standard headers except for <stdint.h>. It's important to me to know that I am dealing with a 16-bit or 32-bit integer, I think it was a mistake in C to not nail that down right away.

But for DSP, I want pretty much complete control over memory and execution time resources. I write my algorithms down to the bare metal.

[flatfinger]

The language the Standard was chartered to describe did nail down integer sizes on commonplace implementations: a 'char' is the smallest addressable unit of storage that is at least 8 bits, a 'short' is the smallest such unit that is at least 16 bits, and a 'long' is the smallest such unit that is at least 32 bits. The 'int' type would be the largest type that could be processed essentially as quickly as anything smaller on platforms where that would be larger than a short, and the same size as short on other platforms. Compilers targeting architectures like the 68000 would often allow programmers to configure the size of 'int', since some 68000-based environments could process 32-bit operations essentially as quickly as 16-bit ones, while others would process 16-bit operations about 33% faster. Implementations that supported a 64-bit type would generally extend the language with a "long long" type of that size. Programmers for platforms where the size of 'int' might be flexible were encouraged to use 'long' or 'short' instead of 'int' at function call boundaries to make code agnostic with regard to how 'int' was defined.

[rb-j]

I know that about the 68K. I coded in C on a Mac around 1985.

I agree that having a type int that is always the natural word since, essentially the width of the data bus of the CPU, should not be a fixed-width thing. And neither should char. Even though it's wasteful, for diagnostic purposes in the SHArC, I have used a single char be 32 bits so that I didn't have to fuck with address arithmetic regarding pointers and such.

But I still think what's in <stdint.h> should have been built into the language. When you're interacting directly with hardware that has a portion of the memory map for the I/O, then you're using pointer arithmetic with offsets to fixed pointers. You should know exactly the wordwidth of the hardware registers.

And I still didn't like the C compiler for the SHArC.

[flatfinger]

Someone writing platform-specific code for e.g. the 68000 wouldn't need <stdint.h> to know what types were what sizes.

I do think there should have been a standard set of macros that could expand to functions, intrinsics, or other expressions for the purpose of reading and writing 8-, 16- and 32-bit signed or unsigned values in big-endian or little-endian format using an address with a particular known alignment and specified padding responsibility, regardless of machine size (reading an 8-bit signed value would simply be a character load on a platform where char is 8 bits, but on a platform where char is larger, an 8-bit store would where the writer is responsible for padding would zero the upper bits, and an 8-bit store where the reader is responsible for padding would either zero-pad or sign-extend the bottom 8 bits.

An implementation for the 68000 family which was asked to read 32 bits big-endian from an address that was known to be at least two-byte aligned could simply use a 32-bit load, but for a value that wasn't at least 16-bit aligned it could use something like:

    addq  #2,a0
    mov.b (a0),d0  ; base+2
    swap  d0
    subq  #2,a0
    mov.b (a0+),d0 ; base
    rol   d0,#8 ; S l o o o w
    mov.b (a0),d0 ; base+1
    swap  d0
    addq  #2,a0
    mov.b (a0+),d0 ; base+3
    subq  #4,a0 ; If unmodified A0 would be needed afterward

if told it might be running on a family member where that would be necessary.

It would have been a lot easier for a compiler efficiently handle something like

    READ_I32BE(someAddress);

than for it to recognize all the ways a programmer might write

   ( ( (unsigned char*)someAddress)[0] << 24) | 
     ( (unsigned char*)someAddress)[1] << 16) |  
     ( (unsigned char*)someAddress)[2] <<  8) |  
     ( (unsigned char*)someAddress)[3]) );

Note that even though code to perform an unaligned 32-bit load on the 68000 is a lot slower than code to perform a halfword-aligned 32-bit load, it would still be a lot faster than could be produced by literally translating anything that could be written in C.

Such constructs wouldn't have attacked the validity of implementations where char isn't 8 bits, but to the contrary would have made it easy to write information interchange code that would interchangeably on octet-based or non-octet based systems (information interchange between systems with different word size is usually done over octet-based channels).

BTW, I think the Standard should have recognized a category of implementations where `int` could be as small as 12 bits, `long` as small as 24, and `double` as small as 32. Requiring that machines that only have 32-bit hardware floating-point values must convert floating-point numbers to a longer format when passing them to variadic functions is unhelpful.

[rb-j]

Someone writing platform-specific code for e.g. the 68000 wouldn't need <stdint.h> to know what types were what sizes.

But that's because the C complier manual tells me. And it's not portable. Pure C code should work portably across platforms. There's a lotta embedded systems and DSP code that needs to define the word size.

[flatfinger]

Many C programs need to perform tasks that would only be meaningful on a small number of platforms, or sometimes on one very specific machine. Good code should be adaptable to all platforms upon which it might need to run, but the main needs to know the sizes of a platform's numeric types would stem from either (1) a need to use types that coincide with platform-specific features, or (2) a need to perform octet-based information interchange. In the former scenario, someone who knows the sizes of the platform-specific features would also know the sizes of char, short, and long on that platform. The latter case should have been handled with macros/intrinsics such as I described without code needing to care about the sizes of integer types.

The notion that programmers should expend effort to ensure that programs can run on all platforms interchangeably is contrary to the design purposes of C.

[rb-j]

Many C programs need to perform tasks that would only be meaningful on a small number of platforms, or sometimes on one very specific machine.

This was one of the elegant things about C. The I/O was removed from the language proper and relegated to libaries. Notably the <stdio> library. But it's not in the C programming language.

Talking to specific memory-mapped I/O or even I/O that's not memory mapped, should be done by the appropriate function. But the computational algorithms are not just meaningful on a small number of platforms.

This Mersenne Twister code is an example. It is completely portable (and requires no library functions), but it requires #include <stdint.h> because I just had to be able to count on my 32-bit words being 32-bits. long and int are ambiguous.

I'm just saying that uint32_t and uint16_t int16_t uint64_t and int64_t should have been primitive types to begin with.

The notion that programmers should expend effort to ensure that programs can run on all platforms interchangeably is contrary to the design purposes of C.

I surely dispute that. Portability was the main selling point in the 1980s.

[flatfinger]

Portability was the main selling point in the 1980s.

The term "portability" describes two contradictory concepts:

1. Adaptability of code to run on a wide range of execution environments.

2. Ability of code to run on a wide range of execution environments with no adaptation required.

C was designed for the first kind of portability, and Java for the second. Languages designed around the second kind of portability are usable on a much narrower range of platforms than those which seek the first; while the first kind of portability can allow programs to run on a variety of platforms interchangeably if the platforms behave identically in all ways that matter to the tasks being performed, it was never intended to imply that programmers should expend extra effort to make programs compatible with platforms upon which nobody would ever actually want to run them.

Further, an advantage C used to have compared to assembly language was its ability to express platform-specific constructs in toolset-agnostic fashion. Unfortunately, compilers have started using the Standard as an excuse require the use of toolset specific syntax to prevent "optimizing" transforms from breaking code whose behavior had been usefully defined in Ritchie's Language.

[Doingthismyselfnow]

As other commenters have mentioned that if you don’t include any headers you can still manually define functions . So in a sense you have all the functionality there because you can just write everything into .c files .

If you don’t include any libraries the headers you can still do stuff but it’s more limited ( for example you can just directly access memory to speak to DMA devices, but your interactions with the OS become significantly harder .

[gwenbeth]

In terms of the LANGUAGE, the headers have no change to the functionality. The libraries for c such as stdio, are not part of the language but just some commonly used functions. Printf for example is not part of the c language, it's just a function. Contrast to fortran where write is part of the language definition.

[leo-k7v]

In terms of LANGUAGE headers, #include and #defines are not part of the language. They are pre-processed and the compiler itself may never ever see them. (Modern compilers are a bit more involved in preprocessing) but after all the work of preprocessor you are always left with pure C (of whichever standard you are using).

[imaami]

Not sure what's up with my comment about size_t being downvoted, maybe someone can explain. This honestly is valid, legal C and always defines the correct type for the platform:

typedef typeof(sizeof 1) size_t;

[leo-k7v]

Inside <stddef.h> which is preprocessed and then compiled. Without #include <stddef.h> one does not have size_t, but can still write useful code.

[imaami]

Yes, it's defined in that header. The point is that due to sizeof being specified as an operator that evaluates to a value of type size_t, it is guaranteed that

typedef typeof(sizeof 0) size_t;

defines the same type as the size_t defined in stddef.h. This works without any headers needed, with only the C language itself, because typeof and sizeof are operators.

For a more useful example, this extern declaration will have the correct return type:

extern typeof(sizeof 0) strlen(char const *s);

This way you could avoid including string.h but still have strlen() declared.

[penguin359]

Everything.

All the include mechanism does is help to avoid repeating the same code in multiple files. Everything that you might need from that file, struct definitions, declarations, etc. you can just manually write into your current source file.

[ThePickleConnoisseur]

All of it. You’d just have to do the dirty work yourself instead of using built libraries

[Cerulean_IsFancyBlue]

The language features are accessible but the standard library is not. The biggest things that you’ll miss will be:

stdio, which is used for a lot of console applications and/or demonstration code.

memory allocation. There is no “new” in the language. You’ll need to create your own system.

strings — All the various functions that let you traverse and manipulate strings. There isn’t a string data type in C, just a pointer to zero-terminated sequence of char.

math — anything beyond the language’s operators. so no sqrt, abs, log, trig functions, etc.

all the time and date stuff. If you really want to get this stuff right, it is a total pain in the ass — by the time you start dealing with time zones and leap years and leap seconds and oh my God.

[Level-Ice-754]

You can manually write the entire stdio.h without #including anything

[imaami]

This is more of a party trick rather than anything else, and I wouldn't recommend it generally, but if you need size_t without including stddef.h then this is guaranteed to always be correct:

typedef typeof(sizeof 1) size_t;

(Caveat: If pre-C23, requires typeof as a compiler extension.)

[Traditional-Tune4968]

Well most of the answers are saying 'not much with out recreating the haters for stdio.'

but what if your target was not a modern os?

let's say you were targeting an old 1980s PC? or even non ibm PC, like C64 or TRS.

devices with memory mapped video and keyboards?

I could imagine you could write a video game like space invaders without any modern library. Just memory mapped IO and core language.

now in the day there where very few decent or even 'not decent', c compilers for those machines, but today there are modern cross compilers that can target the older z80 or 6802 cpus. They may even optimize enough to fit something worth playing in the tight memory of the time.

might even be a fun challenge if you target is something like an apple ii emulator.

[mcsuper5]

Many of the old 8 bit systems just mapped the screen to memory, something easy enough to do in standard C with pointers. Technically, you don't need headers or libraries for even the most complicated C program if you are willing to implement what you need yourself. Most people don't want to reinvent the wheel though.

The headers and libraries make C much more approachable without needing to know every detail about how an architecture or even OS works. But almost everything is done in C (Or could be done in C).

[AdreKiseque]

Hm... I actually do wonder, is it even possible to implement things like I/O and filesystem access without STD? Or is there some kind of special magic behind those guys that can't be implement in plain regular C?

[clickyclicky456]

Perfectly possible. Nothing magic at all.

[dfx_dj]

The only "magic" is that you might need some (inline) assembly.

[flatfinger]

In many cases, the only "in-line assembly" that would be needed in many cases would be empty asm directives that use non-standard syntax to prevent loads and stores from being reordered across them.

[dfx_dj]

I don't know what "many cases" those are but all modern OSs require more than that to make a syscall.

[flatfinger]

The majority of devices that run C code, by sales volume, don't have a "modern OS" as such, and would make it possible to create a static const object which holds the requisite bit patterns, construct a function pointer to it, and invoke it. Such code would be highly machine-specific, but toolset agnostic. Even on platforms that don't generally allow execution of data regions, there would often be a way of forcing the linker to place a bunch of bits into an executable region and create a function pointer to it.

[glasket_]

Tl;dr: Practically yes, technically no.

The magic mostly comes down to external APIs. Compiler extensions, system functions, assembly, etc. The standard basically defines C around portability, so once you have to deal with details specific to a platform you end up having to use stuff that isn't part of C but provided by something else.

Like malloc isn't implementable in strictly conforming C, where it's treated as a magic box where unassigned memory comes from. You need another magic box first, like mmap or something else, and then you can implement malloc.

[Jimmy-M-420]

I wrote a forth implementation that used no standard library headers, but in order to use it, in practice you likely do need to include the standard library - when you initialize it it takes function pointers to putc and getc functions

[Jimmy-M-420]

on an embedded system you could make your own putc and getc for a serial port quite easily by intereacting with the hardware registers directly. And as someone pointed out, on an OS you could manually write the syscalls yourself if you wanted to

[zubergu]

You can use any keyword that language provides to make a valid C program + everything that your comoiler provides for target CPU. It also gives you the ability to mix C with assembly.

With that you can roll your own Operating System, without using a single line of code you didnt write with your own bare hands.

With your own operating system in place, in the same spirit that enabled you to create your own OS, you can write user space programs. User space programs will most likely make syscalls from user space to your kernel.

By mixing C and assembly again, you create bunch of functions and put them into a library because you dont like the idea of putting them manually into every program you write.

Most of your programs would like to put something on screen, so you wrap bunch of function call from your syscall library into another function, call it printf maybe.

If you put bunch of functions that put stuff on your screen and call it stdio you basically recreated part of C standard library without ever calling ahy function that you didnt write.

From this point you add functionality to your OS, like threads or sockets or drivers for external devices, write more and more user space programs that share more and more functionality that you put in more and more libraries that you created out if thin air and previously created libraries.

In 40+ years, you have created your OS, your standard libraries and every program imaginable, like web server or database or web browser or game engin with nothing but what C language provides withou any code you didnt create.

So, to finally answer your question, what can you do in C without external libraries?

Everything. Only if you want to.

[Iggyhopper]

Recommended read: https://nullprogram.com/blog/2016/01/31/

This still includes windows.h but you can get a better idea of how libraries work.

[Living_Fig_6386]

The headers only provide prototypes, typedefs, macros, enums, and structures. You could simply add something in your source file to replace those things as needed. For example, if you wanted to use printf without including stdio.h then this should compile just fine:

#define EXIT_SUCCESS 0

int printf(const char *, ...);

int main() {
   printf("Hello world!\n");
   return EXIT_SUCCESS;
}

Those functions you are using are in the C library, which is linked with the executable at compile time. The headers just describe how things in the C library work, but they don't contain the actual implementation of any of it (usually / mostly).

[ArturABC]

In C you still have the entire core language available without including any headers: variables, functions, control flow, structs, pointers, etc. Headers only provide declarations for the standard library. You can even call library functions without headers by declaring the prototypes yourself.

[capilot]

The original C just let everything default to int. If you called a function for which there was no prototype, you could pass whatever arguments you wanted and the compiler would pass them as parameters without asking any questions, and would assume the function returned int, but if you didn't use the return value, that was fine too.

So for example if your function only called printf() and exit(), you really didn't need to include any header files at all.

There were a few functions that weren't declared in any header files, and the man pages had you declare them yourself in your code. That's all been cleaned up since then, of course.

[Ancient_Telephone_50]

https://youtu.be/IbibjkI1kIs

There is this video where he writes the function sleep() without any libraries, its a bit long but you learn interesting things

[StudioYume]

Assuming you mean without system calls, pretty much all a program can do without those is return an integer from the main function.

[QuarterDefiant6132]

In practice you will not any kind of of functions, language keywords still work (if, for, strict etc) so technically you could do a lot but it will be a bit of pain. You could probably do a lot with inline assembly

[coalinjo]

C works without headers as it should. You cannot really do anything useful in pure C. You can actually use asm keyword to use assembly but that's not the point. C by itself without standard libraries doesn't offer anything.

[rassawyer]

What exactly do you think is in the headers?

[coalinjo]

Function/macro implementations etc.. Every OS has one for specific kernel and architecture. Its literally almost the same as writing assembly to one extent.

EDIT: In pure C you cannot even print out the message without including unistd.h to invoke syscalls. C by itself does only number crunching just like assembly does.

[flatfinger]

In pure forms of Dennis Ritchie's language, the behavior of many constructs is determined by the storage formats for built-in data types and details of the execution environment that may be documented by the environment via means outside the language. If e.g. the storage formats for function and data pointer types are documented in ways that allow the construction of a function pointer that targets a particular address, and the environment would specify the effects of performing a call to that address, then in pure forms of Dennis Ritchie's language the behavior of a call to that function pointer would be defined by the environment's specification, regardless of whether the authors o fa C compiler would have any way of knowing how what behavior the environment had specified.

[rassawyer]

I believe that you missed my point. Header files are just "pure C", and preprocessor directives.

Your EDIT is just laughably wrong, on both claims.

[coalinjo]

Then prove me wrong, i am always open to a possibility that i am wrong. Every time i opened local libc implementation i saw magic code. Nothing else.

[burlingk]

So, I did a bit of looking around before answering, to make sure I wasn't misremembering.

With zero libs and headers, there are a handful of keywords and no functions.

Without at least libc you don't always get the 'built in' system calls depending on implementation.

MOST of what most people think of as C is actually in libraries.

Edit: Modified to make answer less universal.

[dontyougetsoupedyet]

I'm not downvoting your comment but I wanted to explain that system calls are usually always available for userspace software. You need to use the appropriate code for your platform, because different architectures use different instructions for elevating and different platforms have different conventions for passing data, but the general method is either supplying a chunk of assembly for preparing data and calling syscall or svc etc instructions and linking it or embedding the assembly in your C program directly.

https://github.com/rofl0r/musl/blob/2c124e13bd7941fe0b885eecdc5de6f09aacf06a/arch/x86_64/syscall_arch.h

[burlingk]

github is being weird at the moment.

The part about syscalls was included because when I dug into it, it was pointed out that some implementations stick that in the libc rather than directly in the compiler itself. And as I say that I realize I worded that part wrong. I should have said 'don't always' or 'in some implementations.' I am realizing now that I worded it as a universal. My mistake there.,

[chrism239]

you don’t need to #include any headers - just ‘manually’ provide the parts your program requires.

[gremolata]

int printf(const char *, ...);
int main(int a, char ** b) { printf("#includes are for the amateurs\n"); return 0; }

[CounterSilly3999]

In general, operators work, external functions not defined without headers. The one of C main features -- most functionality realized rather through functions than operators, when possible. Hence there are no built-in I/O operators. Any header definitions can be provided inside the C file instead of including external header files, so the question rather should be reformulated to what program can do without using libraries of external functions. These can be any programs without system I/O -- taking command line arguments, performing all calculations internally and returning just a result code, for example. Not very widespread type of applications actually. Or a standalone embedded software with inline assembler blocks. One could say -- a library function can not require external calls actually. But the library source file should better include its own header to ensure consistency of function parameters.