ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
You probally forgot to return 0 at the end of your main function
short a ;
printf("\n a= %d\n",a);
return 0; //Forgot to do this
Also if that still does not fix the problem you may want to use %h instead of %d, because %h is the flag for short. The bus error may be occuring cause it is trying to read and save a 4 byte integer into a 2 byte space and isnt converting right.
Last edited by stumpster123; 07-14-2005 at 11:33 AM.
printf("\n a= %d",a);
also works for me running Fedora Core 3 and gcc 3.4.3. Your post stated that you were using a 64 bit SunOs box. I wonder if the c library, or the gcc compiler for that port has a problem in either the scanf or the printf support functions when dealing with misaligned data types. For grins you could try either one (or both) of the following tests:
printf("\n a = %d\n", a);
printf("\n a = %hd\n", a);
I would be interested in hearing of your results if you run those tests.
>You cannot write "safely" 4 bytes where only 2 are expected.
> - first you are writing to undefined space
R: So, at worst I should have got a segmentation fault, bt why SIGBus?
> - alignment may matter depending on the architecture, what is yours ?
R: mine is a 64 bit SunOs
What CPU is running the 64 bit SunOS?
Alignment does matter depending upon the CPU and how misaligned data is handled. I remember that either the old Motorola 68030s or 68040s would throw a bus error exception if you tried to do a 32 bit data access and the memory address did not start on a "long word" boundary. My guess is that you are seeing the same sort of exception handling. I think that it is probably the scanf that was throwing the exception and not the printf, you could go back to your original code, remove the printf and try a test with just the scanf. You could also go back to your original code, compile it and have the compiler preserve the assembly source. Then recompile the code that works, having the compiler save the assembly code, and take a look at both versions of the assembly code to try and identify what the CPU is really trying to execute. Then take a look at the CPU's assembly code programmers manual and look up wha each of the instructions are supposed to do and what kind of exceptions they can throw. (Not sure if you want to take those steps, but it could go a long way to helping you understand the hardware architecture a little better )
I used gdb to find out the addresses being allocated to a "short int" and an "int".
I saw that a short int is allocated memory at 2 byte boundary, and an int is allocated memory at 4-byte boundary.
some post I came across in the net said that to read a n-byte entity the starting address should be at n-byte boundary.
till now I have assumed the above statement to be true.
Okay, that makes perfect sense. In your original failure case you had allocated a short int (thus being allocated on a 2 byte boundary), however your scanf was attempting to access an int (I presume that your ints are either going to be 4 or possibly even 8 bytes, but are definitely not 2 bytes) therefore that access should either require a 4 or an 8 byte address boundary. Since your data was defined using a 2 byte boundary, and your access to that memory was presuming a 4 or 8 byte boundary - bingo bus error exception.
Once you switched to either of the two examples I suggested, your access alignment matched your definition alignment and everything was okay.
I have programmed the 32 bit Sun Sparc CPUs, they are "quirky" when it comes to alignment problems. I think that the 64 bit versions are probably just as quirky if not more so.