32bit and 64 bit pro*c program

[seek]

i compiled bellow pro*c sample by using 32bit compiler but 64 bit compiler i am getting errors.My os is AIX ver 5.2.

#include
#include
int main()
{
struct tm *timptr;
int tim;
time(&tim);
timptr=localtime(&tim);
printf("%02d",timptr->tm_mday);
return 1;
}

Can anybody help me please.

Thanks
Vasu

[Sathish_3]

something is wrong with ur compiler. b'cause i'm getting no errors when i tried the same program in a AIX 2.5 machine.

Can u show the error msg?

[Manish Srivastava]

Hi Vasu,

What error are you getting?
If it is mismatch ABI then you may have to set your paths correctly.

Manish

[Matti_Kurkela]

AIX? That's IBM's unix, nothing to do with HP. But let me try anyway...

Because you didn't tell *what* error messages you're getting, it's a bit difficult to guess what the actual problem is.

You seem to be assuming that the value of time() is a signed 32-bit integer, or in other words, anything that fits in int.

Don't assume that, or your assumption may come to haunt you on Tuesday 19. of January 2038, at about 03:14 UTC time (the end of the traditional Unix epoch).

Besides, explicitly using time_t type would be better style. It will also make it easier to fix your programs when the real rush to fix Y2038 problems finally begins.

The AIX 64-bit compiler may be already defining time_t as something larger, and you might be getting an error message because of that.

[rick jones]

You must be really desparate posting AIX compiler issues in HP's ITRC Forums... :)

FWIW, the advice about types is likely spot-on. Compiling your bit of test code on an HP-UX 11.11 system (even 32-bit) yielded the following warnings:

$ cc foo.c
cc: "foo.c", line 7: warning 604: Pointers are not assignment-compatible.
cc: "foo.c", line 7: warning 563: Argument #1 is not the correct type.
cc: "foo.c", line 8: warning 604: Pointers are not assignment-compatible.
cc: "foo.c", line 8: warning 563: Argument #1 is not the correct type.

changing the type of "tim" from int to time_t made those warnings go away, and the program compiled without warning or error in 64-bit mode with HP's C compiler. Compiling the original source in 64-bit mode under the HP compiler yields:

$ cc +DD64 foo.c
cc: "foo.c", line 7: warning 729: Argument #1 converts int* to long*.
cc: "foo.c", line 8: warning 729: Argument #1 converts int* to long*.

which, while on the surface seems silly if one thinks a pointer is a pointer, really isnt since an int and a long have different alignment requirements in 64-bit mode - int remains four-byte alignment, but long (LP64 mode) gets an eight-byte alignment requirement.

Now, for posting an AIX question in HP's ITRC Forums, you are now required to go-out and buy some additional HP kit :)

[Mike Miller_8]

I think this is what you are looking for :

#include
#include
#include

struct tm when;
time_t now;
time_t result;

int main()
{
time(&now);
when=*localtime(&now);
printf("Month %d\n",when.tm_mon);
printf("Day %d\n",when.tm_mday);
printf("Year %d\n",when.tm_year+1900);
return 1;
}

= Mike =

[R. Allan Hicks]

What happens if you go directly to the c compiler?

pro*c is a pre-processor and in theory, will have no effect on anything unless there are some #EXEC SQL lines in your code.

My basic troubleshooting technique is to simplify the problem until it works and then go back step by step until it breaks. Once it breaks you know where to look.

Since the pro*c runs a preprocessor and then the compiler, eliminate the preprocessor step. The other respondents show that they can run the C compiler. Maybe the difference is something that the pro*c is tossing in?

Typically, the pro*c has a .pc extension and emitts a .c file. Check your .c file to see if pro*c has done anything to it? In your example, it should be the same file, just with some extra stuff from pro*c.

-Good Luck

[seek]

we have to use LONG instead of INT data type