I am on Arch Linux. I have tried gcc and cc.
I have quite a strange problem. I have a file included from /usr/include (installed from an Arch package) in a C program like so.
// prog.c
#include <foobar/foobar.h>
When I change it, nothing happens. Let me explain. It includes some C code.
// foobar/foobar.h
int baz = 1, qux = 2;
Recently, it has been updated.
// foobar/foobar.h
int baz = 1, qux = 2, norf = 3;
My test program looks something like what follows.
// prog.c
#include <foobar/foobar.h>
printf ("%d %d %d\n", baz, qux, norf);
output:
error: ‘norf’ undeclared (first use in this function)
I can duplicate the file in the same directory, name it foobar2.h, and then include that file instead and it outputs:
1 2 3
So the path is not incorrect. I can make a link to the folder, name it foobar2, and include foobar2/foobar.h and it outputs:
1 2 3
So the file is not incorrect.
To confirm that it is not registering changes, I can destroy the foobar folder entirely and try to print just the 2 variables that were originally inside the header. This outputs:
1 2
Clearly something is not updating. The same behaviour is displayed when I try updating the file with enums, functions, or new values for existing items in the file, and include them as the only lines in the file. None of the changes register. The same activity is displayed with gcc and cc. This has been going on a few months now and it still has not resolved itself.
When a file does not seem to be updating, it is a good idea to check other places on your system where your compilers search for libraries for identically named folders. In this case, it was in /usr/local/include, where I had a version that I compiled and forgot about entirely.
This can be mainly due to the include directory path mismatch. Check out the environment variable that can affect the behavior like C_INCLUDE_PATH , CPATH. Another option would be to check with gcc -I/src/directory foobar.h while compilation that can lead you closer to the problem or use #include "foobar.h" in the code.
In case if there are multiple copies of the program in your system, it is possible that completely different file is used for compilation and execution which can also lead to changes not getting reflected.
Related
Here the concise c code:
#include <stdio.h>
int main()
{
printf("abcdefg\n");
return 0;
}
when I open it with ollydbg, and then type E (executable module), right click the a module and select 'view executable file'. it will show the below window:
However, when I ctrl + B search for the 'printf', I got three result (ctrl + L will find the next)
My question is:
In my code is only one 'printf' function, why can I find 3 'printf' in the ollydbg.
My guess is, when you include stdio.h it must contain more occurrences of printf string, compiled source is not only your source but also everything you include.
I don't think names of functions should be included in the binary file (but I'm not an expert), I think only reason they are there is you compile it with debugging options on. You can check it easily by compiling the binary without debugger on and checking the executable with some hex editor.
I recommend to study how compilers work?. The link I sent might be good place to start and study.
Can I make a custom header file named stdio.h and can use it in my program along with <stdio.h>?
C11 7.1.2p3:
If a file with the same name as one of the above < and > delimited sequences, not provided as part of the implementation, is placed in any of the standard places that are searched for included source files, the behavior is undefined.
The standard places then refers to 6.10.2p2:
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
So the only guarantee given here is that if your stdio.h is not in an implementation-defined place for a searching a header, then the behaviour wouldn't be undefined. You can then include it with
#include "stdio.h"
However if you really intended that the file would be included with
#include <stdio.h>
then for the compiler to find it you need to place it in any of the standard places, and all bets are off.
However, in a freestanding - i.e. not hosted - execution environment. stdio.h might not be a standard header name so it might as well be perfectly OK there. Not that there is anything portable about the freestanding execution environment.
Thus, unless you specify more specifically what you're up to, we can only refer to the C standard and shrug. Having a source file named stdio.h isn't strictly conforming but it very much might be conforming, so YMMV.
As noted by Antti Haapala, it is explicitly described as undefined behavior to name a file stdio.h and put it in any of the directories where the compiler looks for include files.
Yet, by default, the compiler does not search for standard headers in the directory of the source file, but a command line argument of -I. can easily change this behavior.
Without this option and assuming you do not put your source files in the compiler's system directories, you could use the name stdio.h for an include file and include that with #include "stdio.h" without interfering with the standard header referred to in #include <stdio.h> (which might not even be a file at all).
You could go one step further into confusion-land by naming the source file itself stdio.h...
I you truly want to confuse the reader, name the source file a.out and compile with gcc -o stdio.h -x c a.out.
If you specify where in your file directory your custom "stdio.h" comes from (i.e. doing
#include "C:/ProgrammingC/stdio.h"
is probably fine, but
#include "stdio.h" //This only selects the standard include
//if there's no other stdio.h in the build directory
is risky, and
#include <stdio.h>
is definitely not what you want.
I've created a file named as stdio.h and main.c afterwards added this content to main.c to test out if it works properly.
#include "stdio.h"
#include <stdio.h>
int main()
{
testArea(); // this will use "stdio.h"
int test = 2;
printf("%d", test); // this will use <stdio.h>
return 0;
}
Program output:
1002 (100 from "stdio.h" and 2 from <stdio.h>)
Content of my stdio.h:
#include <stdio.h>
void testArea()
{
int abc = 100;
printf("%d", abc);
}
Surprise surprise, it does! Now, you should know that using "" means searching header file via file path. Meanwhile <> basically looks at the includes folder of the compiler.
So that, you can do that.
PS: If you're going to downvote, make an explanation so that I can learn what's wrong too. It just works fine for me.
Edit: Now, you can see that program knows what to call and what to do.
Bonus: If you try to add a same name function that exists in the file compiler will give you an error.
#include <stdio.h>
void testArea()
{
int abc = 100;
printf("%d", abc);
}
void printf()
{
}
Will return stdio.h:9:7: error: conflicting types for ‘printf’ as an example. You just should avoid using existing functions, but it's not restricted to same name header files. You just can't do it with any filename since the names are going to conflict.
Again, the usage of this is fine. There should be no problems at all.
Edit 2: I'm using Linux Mint 18.2.
Here is my gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And, here is how I compile my code:
duman#duman-pc ~/Desktop/Nuclear Test Zone $ gcc main.c -o test
duman#duman-pc ~/Desktop/Nuclear Test Zone $ ./test
Nothing fancy, and I don't really know what can cause undefined behaviour since my compiler won't allow usage of same name functions.
Edit 3: Just to see if anything related to name usage throws a warning I compiled the same code with ALL of these flags: https://stackoverflow.com/a/34971392/7735711 and there were none about the names.
That's the best I can do. Hopefully it helps you.
I'm working on an application which defines it's own printf() to get around differences between the different CRTs out there or because some other platforms don't have it.
When building the application with gcc this automatically seems to work and the custom printf is used instead of libc's one; if I understand it correctly this is because of the order in which object files/libraries appear in the link command or maybe because object files are always searched before CRT libs, correct?
I'd like to do the same using msvc. Just building the project gives the expected 'LNK2005: _printf already defined in printf.obj' because printf is also in msvcrtd.lib. Fair enough. I know about /NODEFAULTLIB but that excludes everything resulting in unresolved references for everything but printf. I scanned through the other linker settings but couldn't find anything which allows this (apart from /FORCE maybe, but the 'might produce an invalid executable' comment doesn't make it sound like a good idea). Also nothing in the module definition file docs; the latter got me thinking it might be possible to create a stub library which has all exports from msvcrt.lib except printf but that seems a brittle solution even if it works.
In the end the question is simple: how do I tell msvc's linker it should skip msvcrt's printf definition and use the one from my printf.obj instead. Basically /NODEFAULTFUNCTION:printf or so. Just an answer for one single executable is ok, though I'd also be interested to know if and how it can be done when building a dll instead where the custom printf is exported: how to tell the linker it should use the export from my .lib instead of msvcrt.lib?
edit simplest repo I could find: create a file main.c:
#include <stdio.h>
int main(int argc, char** argv)
{
printf("Hello");
return 0;
}
and a file printf.c:
int printf(const char *fmt, ...)
{
write(1, "ok\n", 3);
return 3;
}
For VS2013 (though the other versions might work as well): create a new empty C++ project and add both files then build. (For gcc: just gcc main.c printf.c and the resulting a.out prints 'ok')
The culptrit for VS is #include : without that it works ok but I have yet to find out if the original code allows getting rid of it in some way. But even if it does I'd still want to know if this can be solved at the link level.
I'm developing something on Minix 3 and, when it comes to deal with io files, I got a problem.
In the code:
#include <stdio.h> /* If I don't call any stdio funcs compiler doesnt's complain*/
int main() {
FILE * fp; /* I get the following: " * not expected " */
return 0;
}
Already tried everything that comes to my mind, can't figure it out..
/EDIT/
From what I can tell, when I include something, if I call functions not related to structs, it's OK. Is it the structs ?
I will assume you have checked whether the Minix file is present, that it really defines the type FILE and that your include path provides the correct -Ioption to the compiler to find that file.
Depending on your environment it could happen that an environment variable INCLUDE exists and is recognized by your compiler to provide additional include paths, recognized even before the include options from the command line. In such a case it might happen to include a stdio.hfrom a different compiler. Visual Studio is known to provide such an environment variable by default, and that has bitten me once before.
EDIT: Running the preprocessor in isolation may help to find out what is really happening in any case. Verify that FILEis defined in the preprocessed version of your file.
I got a slight problem implementing arrays in ocaml. For example, when on the terminal(konsole) and I type
let tab = Array.make 5 6;
I have
val tab : int array = [|6; 6; 6; 6; 6|]
as an output. So it creates an array with a length of 5 and fills all the cases with 6. Okay I understand that part. But when I type it on a text editor like kate for example, save it and compile it it I get this error:
Error: Unbound value Array.make
I don't understand why it takes Array. make as a value in kate and it takes Array.make as a function in the terminal. I saved the file with the ".ml" extension and I compile it using ocamlc -o test name_of_file.
Any suggestions please? Thanks.
I compiled your program with ocamlc and it went fine (using OCaml 3.12.0).
I would guess that you are calling an old version of the compiler when you try to compile, perhaps one from when Array.make was still named Array.create. Perhaps when you installed the new version, you overwrote some of the files (such as the toplevel) but not others (such as the compiler). In order to check, compare the versions given by ocamlc -v and ocaml.
As for the message “Unbound value”, in OCaml, functions are values. The implementors did not differentiate between “Unbound value that is not a function” and “Unbound value that is a function”, but this is not the cause of the problem. The cause of your problem is that Array.make is unbound at all.
I found the error. It's a very stupid one. I saved my file as "array.ml". So during the compilation it created an array.cmi file and I think it kinda confused this file with the one found in .../lib/ocaml/array.cmi. I'm not really sure. So I renamed the file to "table.ml" and it compiled perfectly. It's crazy that it confused these two files