|Summary:||ASTERISK-07706: portability fixes: time_t vs. long|
|Reporter:||Ralf S. Engelschall (rse)||Labels:|
|Date Opened:||2006-09-09 13:09:57||Date Closed:||2011-06-07 14:01:01|
|Environment:||Attachments:||( 0) asterisk.patch|
|Description:||The POSIX "time_t" type is not always a ISO-C "long". On lots of platforms it is just an "int". On 64-bit platforms "long" often is 64-bit while "int" is still 32-bit. Hence it is incorrect to intermix "time_t" and "long". Unfortunately, Asterisk contains a bunch of code pieces which intermix "time_t" and "long" by either treating a "time_t" as a "long" or vice versa. The appended patch fixes this and this way prevents Asterisk from potentially crashing on those platforms.|
|Comments:||By: Tilghman Lesher (tilghman) 2006-09-09 16:15:59|
What platform, specifically, is this broken on? We've already gone through several cycles of these changes intended to fix specific platforms.
By: Tilghman Lesher (tilghman) 2006-09-09 16:16:45
Also, to report an issue with severity CRASH, you MUST upload a stack backtrace.
By: Ralf S. Engelschall (rse) 2006-09-10 01:53:18
Sorry, a particular platform doesn't matter here at all. I'm not talking about a particular platform where Asterisk crashed. I'm talking about _potential_ crash situations which can occur on _ANY_ platform where sizeof(time_t) != sizeof(long). An example of such a platform are 64-bit platforms like FreeBSD/amd64. So the goal is not to fix Asterisk on "specific platforms", the goal has to be to fix Asterisk for maximum portability and this way fix it on _ALL_ platforms at once.
I've no stack backtrace at hand as Asterisk still has not crashed for me (mainly as the code pieces are not run for me or that it would not crash but perhaps just create garbage in a few variables). But if you are more keen on correct "severity" classifications inside the issue tracking instead of fixing portability issues, feel free to downgrade the issue report class to whatever you think is most appropriate...