C -- Print To Screen Without #include <stdio.h>? [closed] - c

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Is there a way to have a C source file print to the screen without including <stdio.h>?
Here's my situation: I was asked to programatically handle 1000 C source files that will each implements several numerical functions in C (these functions are supposed to work on data that is in memory, eithout any I/O). The origin of these source files in unclear, and hence, I'd like to make sure there will be no harm to my machine when I compile & run these source files.
Is there a way to find out if a C source file is potentially harmful? I thought of asking the developers to avoid any #include statements whatsoever, but I do need just printf -- as I'd like them to include an output of their calculations within main().
Any ideas?

Sure, add the prototype for printf at the top of your source file, as long as you're linking to the CRT libraries you can use the function without including stdio.h
printf prototype
int printf ( const char * format, ... );

There are, though they are probably a bit larger than the scope of the format of SO. In essence you leverage assembler calls in C. The blog KSplice touches on the subject ( with code and examples ) here.

Is there a way to find out if a C source file is potentially harmful?
No, there is none. A malicious source file could possibly do anything it wanted by defining its own prototypes, or by using inline assembly -- #include is just a compile-time convenience.

I would like to clarify why we need printf and studio.h to maybe make the concept more clear. C is a portable language. You can compile c for Linux, Mac OSX, Windows. In each, causing output normally boils down to a system call, or in embedded systems, dealing directly with a frame buffer or Uart device.
So of course it is possible, do you want to do it? Depends why. If you are coding against a specific platform and dont have printf(), then you may have to look into invoking a system call directly for that platform/writing some platform specific assembly code. It all depends on your use case.

Sure, put the necessary function prototypes in your program.
If you mean by not using printf, then you have several options - you can use fwrite, or you could dispense with streams and use write, or you could invoke operating system I/O services directly, or perhaps you could talk to the display hardware directly, or many other things.
If you want a better answer, perhaps explain why you want to not include stdio.h

This is silly but still:
#include <string.h>
int main() {
puts ("hi");
return 0;
}
and Output:
$ gcc -o try try.c
$ ./try
hi

Related

Should Mac OSX have a "malloc.h" file? [duplicate]

This question already has answers here:
difference between <stdlib.h> and <malloc.h>
(6 answers)
Closed 3 years ago.
A customer's code is expecting to find an include file malloc.h in one of the "usual suspect" locations. On my Mac, AFAICT, there is no malloc.h, at least not in any place you would expect to find it, such as /usr/include, /usr/local/include, or /opt/local/include. Since the malloc() is usually defined in stdlib.h, and since the code includes stdlib.h anyway, I was able to get the code to build by just commenting out the few includes of malloc.h. I am building with gcc.
But two questions: Is my gcc messed up somehow? Should that file be there? Also, the code bombs almost immediately with a seg fault that I haven't been able to track down yet. Could this be the consequence of using the wrong malloc()?
The malloc.h is deprecated and should not be used. It contains some non-standard functions too. If you want to use malloc, then include stdlib.h. Not even the C89 standard mentions malloc.h
If it's the cause of your problems, I don't know, but it's quite probable.
The listing below can provide ideas on where the file should/could be found. I can't explain the segfault without more details, though. I do not see how it could be related to malloc() in any way.
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/malloc.h
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/malloc/malloc.h
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/malloc/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/malloc/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS.sdk/usr/include/malloc/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/malloc/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator.sdk/usr/include/malloc/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/usr/include/malloc/malloc.h
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/malloc/malloc.h
$

How to Limit C instruction set from gcc [duplicate]

This question already has answers here:
How to create a lightweight C code sandbox?
(13 answers)
Closed 9 years ago.
I'm developing a platform similar to hackerrank.com where someone can submit C code, and then that code will be compiled, and run on my server, but I want to limit the C instruction set that a person will be able to execute on my server.
For example: limit the instruction set to I/O only.
My first approach was to parse the code and look for malicious code, but that is pretty naive because it can be easily overriden (shell code, obfuscation, etc..)
My second approach (the one I think it could work) is to remove all the "unnecessary" headers, and just leave stdio.h, math.h, stdlib.h, etc... just to name a few.
But then I thought that it might be possible to limit from gcc the instruction set of C, but after reading the man entry for gcc I couldn't find anything close to what I need, so I wonder if that's even possible.
If that's not possible, what could be a safe way to solve this problem? Other than getting rid of unnecessary libraries.
Thanks!
You could limit system calls using systrace, which is available on OpenBSD. I'm sure there's an equivalent for linux and other operating systems. This would allow you to restrict syscalls to file io only and not things like sockets and forking.

What's the rationale behind C's <stdlib.h> as opposed to including these functions by default? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Every program written in C that I've ever seen #includes <stdlib.h>, at least indirectly. You can't really do much useful without it.
Why aren't its functions just part of "standard C"?
Why should I have to #include <stdlib.h> before malloc()ing something?
C is a minimalistic language. There are no built-in functions.
The C language was designed, from the start, to be used both in ordinary applications (running in a 'hosted environment') and OS kernels (and other specialized environments, running in a 'freestanding environment'). In the latter, ordinary C library functions like malloc() may be unavailable.
In order to allow the same compiler to be used for both hosted and freestanding environments, library functions are not hardcoded into the compiler, but rather are placed into header files loaded by the compiler - such as stdlib.h. OS kernels and other specialized programs do not (and cannot) include these standard headers.
Not all programs need to call malloc(). And those that do need dynamic memory allocation may prefer to do it a different way. C does not try to force a single way of working on programmers.
This is still a perfectly valid program that doesn't require libc and can do much stuff apart from interfacing with the underlying operating system:
int main (void) {
int x = 2;
int y = 3;
return x + y;
}
One reason I can think of is that by putting the stdlib functions into a library, they exist in their own namespace, making it easier to overload them.
It might sound a little crazy to think of overloading malloc, but it's one way to implement a resource buffering system that might be used for say... dynamically creating game objects during a game loop without triggering allocations. You can preallocate a buffer, then overload malloc to create the objects into the buffer rather than allocating new memory for them.

Shouldn't This File Start With Assembly Language [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
http://lxr.linux.no/#linux+v3.0.3/arch/x86/boot/header.S
This is the first file that is first read by the CPU. So shouldn't this start in Assembly Language. It starts with #include so include is a method in C?
#include is a directive to the preprocessor, not the assembler. The preprocessor has nothing to do with the compiler.
That's the source code to the file. It gets compiled into machine language before it's used as part of the OS.
Given that it's AT&T syntax, the first thing you should do is check out the manual for GAS, which is part of the GNU binutils collection:
http://sourceware.org/binutils/docs-2.21/as/Preprocessing.html#Preprocessing
According to the manual:
"You can use the gnu C compiler driver to get other “CPP” style preprocessing by giving the input file a `.S' suffix."
That means the .S assembly files are meant to be assembled by running them through the GCC frontend, which applies the C preprocessor for macros and #include commands, and then passes the result to the GNU binutils assembler.
This is a .S file, therefore it can be processed by the C-preprocessor, of which #include is a valid C-preprocessor directive. If it was only a .s file, then that would typically be considered a "pure" gas syntax assembly file, at least from the standpoint of gcc.
#include is a preprocessor statement. The compiler won't see it at all.
You are looking at a source file. It will be compiled to produce assembler code and then it will be linked by linker (or compiler in some cases). What linker will do is it will look at linking table and the sections in header.S file and arrange them in correct manner.
That's the pre-processor it will be replaced by some other code after the pre-processing state, which will include the contents of the file at the place where it was defined. After that the compiler will compile the code, and the output from it will be assembled by the assembler, which will them read by the CPU and decoded.
Whatever code you write in whatever language, it is converted into machine code before it can execute. All the C programs are and all others are converted into machine code first and then that code will be read by the CPU, and not the C language syntax.

various header files and their uses [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I am searching for some information.
I have seen in many programmes following files included
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
I want to know more what the above header files are used for i.e. in which conditions which header file is used.
Any link which clearly mentions which header file serves what purpose that will be great.
sys/types.h: "data types"
sys/socket.h: "main sockets header"
sys/un.h: "definitions for UNIX domain sockets"
unistd.h: "standard symbolic constants and types"
Header files are used for declaring items that are defined in some existing library.
If you want to use socket(), you'll need to include sys/types.h and sys/socket.h. If you want to use atan(), you'll need to include math.h. If you want to use printf(), you'll need to include stdio.h.
Knowing which header file is needed for a function is given in its documentation (man printf on Unix/Linux).
Knowing which function can be used for solving a problem is given by experience, stackoverflow and Google.
If you want to know what's in a header file, try looking at it, seriously: most will start with some comment describing the content if it's not obvious anyway.
If you want to know what part of a header file is being used by the program that's including, try removing it and looking at the error messages. That may also sound glib, but sadly there's generally not a better way to find this out. But, it may be that on one platform some functionality requires including two headers, whereas on some other platform only one of them is required (perhaps because the second header is indirectly picked up by some earlier include anyway): if you test on the platform where one header is needed and decide to remove the second include, you may break the build on the other platform. So, when you find stuff that is needed, consult the man pages for the required headers - they may be specified by some Standard that both platforms honour.
If you want to know which header files to use yourself, then again - you have to look at the documentation for the functions you need to call. Even then, as a C++ programmer you should prefer the C++ versions of certain C headers, and standard documentation tools like man - given the C function name - won't tell you about the C++ headers. Have a read of e.g. http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch03s02.html - it's GCC documentation but describes C++ Standard requirements for these headers.

Resources