I realise there are a lot of questions related to this issue but I couldn't make head nor tale from the ones I read through.
I'm trying to start learning C for the Amiga and decided to have a try following this tutorial:
http://www.pcguru.plus.com/tutorial/amiga_c.html
On reaching this point, I'm already running into noob problems:
#include <proto/intuition.h>
#include <intuition/screens.h>
#include <proto/dos.h>
#include <stdio.h>
int main(void) {
struct Screen *myScreen;
if (myScreen = LockPubScreen(NULL)) {
printf("Public Screen locked.\n");
Delay(100);
UnlockPubScreen(NULL, myScreen);
printf("Public Screen unlocked.\n");
}
return 0;
}
I'm using the GCC compiler with the following command from the Shell:
gcc -o LockPubScreen LockPubScreen.c
This returns the following:
Warning: assignment makes pointer from integer without a cast
undefined reference to 'LockPubScreen'
undefined reference to 'Delay'
undefined reference to 'UnlockPubScreen
Apart from 'HelloWorld' this is the first attempt at either C or programming the Amiga so I imagine I missing something obvious.
You probably need to include one or more of these additional files to get the prototype for the functions you're missing:
#include <intuition/gadgetclass.h>
#include <intuition/IntuitionBase.h>
#include <libraries/gadtools.h>
#include <clib/exec_protos.h>
#include <clib/intuition_protos.h>
#include <clib/gadtools_protos.h>
Then, as NPE suggests, may may run into link errors if your compiler doesn't include the requisite library by default, and if you don't specify it.
If you had mentioned that you were trying to compile the program under AmigaOS 4.x, the answer would have been obvious. Library function calls in OS4 must either contain the library interface as well - IIntuition->LockPubScreen(), IDOS->Delay(), etc. - or you must #define __USE_INLINE__ at the beginning of the code.
Related
In my current project I'm initializing a window to draw on. I'm using a function pointer to deal with initialization from multiple platforms. So I really only want one instance of the window_init function pointer.
I noticed that I had forgotten to mark this function pointer as extern in my header file and defined it a second time in my C file to give it storage.
The header is included in multiple files so should, to my understanding, generate a linker error. I tested this on my laptop and it did in fact generate a linker error. Why is my desktop not generating errors/how can I find out? In both instances I used mingw64 with cmake in Clion to build, using -Wall -Wextra -pedantic -Werror.
So for clarity: my desktop builds fine, my laptop gives me linker errors. I expect linker errors for both machines and I want to find out why that doesn't happen.
The solution is of course to use extern and then it builds on both machines, however I want to know what is going on.
Here is a minimal example which also builds fine on my desktop while I'd expect it to fail:
window.h
#ifndef CEXTERNTETS_WINDOW_H
#define CEXTERNTETS_WINDOW_H
void window_functions_init();
void(*window_init)(); //This is the first definition and should be marked as extern to my understanding if I want to give it storage in my c file
#endif //CEXTERNTETS_WINDOW_H
window.c
#include "window.h"
#include <stdio.h>
void(*window_init)(); //This is the second definition
void window_init_implementation()
{
printf("window_init_implementation\n");
}
void window_functions_init()
{
window_init = &window_functions_init;
}
second include (I need to include window.h in multiple files so I added it here and added a function so that the compiler can't optimize it away)
#ifndef CEXTERNTETS_SECOND_INCLUDE_H
#define CEXTERNTETS_SECOND_INCLUDE_H
#include "window.h"
void doit()
{
printf("doit");
}
#endif //CEXTERNTETS_SECOND_INCLUDE_H
main.c
#include <stdio.h>
#include "window.h"
#include "second_include.h"
int main() {
window_functions_init();
window_init();
doit();
printf("Hello, World!\n");
return 0;
}
edit:
Was able to find this about -fno-common.
This is a common compiler extension popular in the Unix world. To disable the extension, use -fno-common.
-fno-common is not enabled in GCC before version 10 by default with any warning or standard option. This technically does not constitute a violation of the standard, because the standard list this as undefined behaviour. Undefined behaviour does not generally require diagnostic messages. An implementation is allowed to define behaviour that the standard leaves undefined.
This is however undesirable, and GCC 10 finally defaults to -fno-common.
I am using visual studio 2017 .
First I wrote the following code :
void main()
{
printf("abcdefgh %d hjhjh %d", 5, 6);
getch();
}
It ran perfectly fine .
But after that I modified the code to the following :
void main()
{
char abc[100];
strcpy_S(abc, "premraj");
printf("%s", abc);
printf("abcdefgh %d hjhjh %d", 5, 6);
getch();
}
But now I am getting an error with getch stating that "'getch' undefined, assuming extern returning int"
But this new code has been built on the existing code which recognized getch perfectly , how can it not recognize getch the second time ?
I checked out the following question :
getch() is working without conio.h - how is that possible?
which also carried a similar problem but here with modifications only I got this error .
There is an informative answer there by user named "Fatal Error" but still I would like to know about this intriguing phenomenon that is coming in after modifications . What can be the reason behind this ?
P.S : The following was my header file declarations for the first time :
#include <stdio.h>
and the following for the second time :
#include <stdio.h>
#include <string.h>
Once upon a time, if you called a function which the compiler had never heard of, like this:
#include <stdio.h>
int main()
{
int x = foo();
printf("%d\n", foo);
}
Anyway, if you did that, the compiler quietly assumed that foo() was a function returning int. That is, the compiler behaved just as if you had typed
extern int foo();
somewhere before you called foo.
But in, I think, C99, the language was changed. It was no longer legal to call a function you had not explicitly declared. Because there was lots and lots of code out there that was written under the previous set of rules, most compilers did not immediately begin rejecting the old-style code. Some continued to quietly assume that unrecognized functions returned int. Others -- like yours -- began noisily assuming that unrecognized functions returned int, emitting warnings along the lines of "'foo' undefined, assuming extern returning int".
It sounds like your question is that some time ago, your code containing calls to getch() was accepted without warning, but today, you're getting the warning "'getch' undefined, assuming extern returning int". What changed?
One possibility is that your code changed slightly. If your code used to contain the line
#include <conio.h>
somewhere, that file would have contained a declaration along the lines of
extern int getch();
and this would have goven the compiler the declaration that it needed, and you would not have gotten the warning. But if today your code does not contain that #include line, that explain why the warning started cropping up.
It's also possible that your compiler has changed somehow. It's possible you're using a new version of the compiler, that's more fussy, that has gone from quietly assuming, to normally assuming. Or, it's possible that your compiler options have changed. Many compilers can be configured to accept different variants of the language, corresponding to the different versions of the language standards that have been released over the years. For example, if some time ago your compiler was compiling for language standard "C89", but today, it's doing "C99" or "C11", that would explain why it's now being noisy with this warning.
The change in the compiler could be a change in the defaults as configured by a system administrator, or a change in the way you're invoking the compiler, or a change in your project's Makefile, or a change in the language settings in your IDE, or something like that.
A few more points:
getch is not a Standard C function; it's specific to Windows. Your program would be more portable, in general, if you didn't use it. Are you sure you need it? (I know what it's for; what I don't know if there's some other way of keeping your program's output window on the screen after if exits.)
You should get in the habit of declaring main() as int, not void. (void will work well enough, but it's not correct, and if nothing else, you'll get lots of negative comments about it.)
I think there's something wrong with your call to strcpy_S, too,
Despite the fact that i included '#include ' to my code, when i use built-in qsort function, clang gives me the error:
schedule.o: In function `chooseTicket':
schedule.c:(.text+0x16d): undefined reference to `qsort'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
start of the file (schedule.c) is like that:
#include "sched.h"
#include "schedproc.h"
#include <assert.h>
#include <minix/com.h>
#include <machine/archtypes.h>
#include <stdlib.h>
#include <lib.h>
#include <string.h>
#include <time.h>
and here is the function in which i used qsort built-in function
int chooseTicket(int* ticketList,int length,int totalTicket){
int randomValue;
int temp=0,prevTemp=0,selectedTicket=0,selectedIndex = 0;
time_t t;
struct schedproc *rmp;
int* sortedTicketList = malloc(length*sizeof(int));
memcpy(sortedTicketList,ticketList,length);
srandom((unsigned)time(&t));
randomValue = (random() % totalTicket);
qsort(sortedTicketList,length,sizeof(int),cmpFunc);//this line
note: Same errors also occured for 'rand()' and 'srand()' function and instead i have used 'random()' and 'srandom()', then the problem was solved. I don't understand despite the fact that 'rand()' and 'srand()' is generally accepted functions and header file contains these functions, why clang gives me linking errors while i am using 'rand()' and 'srand().
First, qsort is not a built-in, but part of the C standard library (formally, for hosted environments.)
Second, you need to learn that #include only allows access to the declarations of the functions in any given library. You need to link with the library, for your program to actually perform the call to the functionnality. Since you are getting a linker error here, no #include are going to help.
I guess you are writing a MINIX service, hence linking with libminc rather than with the full standard library ("libc"); in other words, this is a freestanding environment. And it happens qsort() is not in the restricted set of C functions included in libminc.
Either link with qsort.(c|o) specifically; or expand your own local version of libminc to include qsort(); or eat the whole cake and link with full libc, perhaps by adding DPADD+= ${LIBC}; LDADD+= -lc to the Makefile (I never tried to do that but it was supposed to work at some point, according to the code; it is not usual practice, so expect problems down the road.)
I was able to run code that uses the randomize function without including the time.h library. is it automatically included with some other libraries i might have already included in my code? Below is a list of the libraries I included:
#include <graphics.h>
#include <stdlib.h>
#include <stdio.h>
#include <conio.h>
#include <dos.h>
#include <string.h>
#include <io.h>
This is very very specific to the version and implementation of your library. The standard doesn't force any header to include time.h 1 so you cannot rely on that.
In your case, it could be that one of dos.h, io.h, conio.h for example has included time.h (or any other of the headers there for all it's worth).
1 At least not the ones there and not likely in your seemingly ancient library. C11 says threads.h should include time.h
What does <compiler with high warning level> yourcode.c say? My guess would be:
either one of the non-standard DOS-specific headers (conio.h, dos.h, io.h, ...) includes it,
or there's no declaration at all, i. e. it's not included, in which case your compiler silently and implicitly assumes a function signature (specifically, it assumes a return value of int and whatever type of argument you call it with for the first time).
Note that the latter case is wrong, and you should pay attention not to do it (since it may lead your program invoking undefined behavior). Always compile with all warnings enabled so you can track down such an error.
When C compiler can't find a prototype to a function it assumes it is a function that returns int. It also prints a warning function if you didn't change the default settings.
So. In your case perhaps time.h was included, but be aware that it can cause a lot of problems if it wasn't.
I'm having some trouble with C standard functions. As an example, I'm getting that error in the memcpy function, even passing the right arguments to it.
I've included a header as #include "header.h", and I've included , and so in the "header.h" file.
(I'm also getting this error with strcpy, strtok, and some other standard functions, all respective headers included in "header.h")
Can anyone please help me with this? I'm running out of time to deploy this work...
Thanks in advance
It seems it was some trouble within eclipse. I right clicked one of those functions, selected Source->Add includes and it solved the problem (but didn't added any header).
I hope this can be helpful for someone else
Since you have not posted your code I assume that you have not included the following lines of code, at the top of your file:
#include <string.h>
In case your are using a C++ compiler (i.e. g++) then:
#include <cstring>