А почему gcc4.3 а не gcc4.5?

(В ответ на комментарий №1)
> А почему gcc4.3 а не gcc4.5?
Промахнулся

(In reply to comment #0)
> Как показал дисассемблер, при сборке под 32-битную систему, компилятор не
> правильно оптимизирует этот участок кода
> (org_herac_tuxguitar_player_impl_midiport_alsa_MidiSystem.c):
> JNIEXPORT jlong JNICALL
> Java_org_herac_tuxguitar_player_impl_midiport_alsa_MidiSystem_malloc(JNIEnv*
> env, jobject obj)
> {
>     jlong ptr = 0;
> 
>     handle_t *handle = (handle_t *) malloc( sizeof(handle_t) );
>     handle->seq = NULL;
>     handle->address = NULL;
> 
>     memcpy(&ptr, &handle, sizeof( handle ));
> 
>     return ptr;
> }
> 
> Не зануляются handle->seq и handle->address

Не верю, чтобы компилятор это соптимизировал.  Что вам показал дизассемблер?

P.S. Почему они не используют calloc?

Это вообще должна была быть 1-строчная функция:

return (jlong) calloc(1, sizeof(handle_t));

Терять время на изучение аномалий в чужом бредовом коде нет никакого желания.

(В ответ на комментарий №4)
> Это вообще должна была быть 1-строчная функция:
> 
> return (jlong) calloc(1, sizeof(handle_t));

Неа. Там возвращается адрес локальной переменной. Что хотели сказать этим авторы неизвестно, читать этот код действительно нет желания.

(In reply to comment #4)
> Это вообще должна была быть 1-строчная функция:
> 
> return (jlong) calloc(1, sizeof(handle_t));

Так работать не будет на 32 битной системе, т.к. jlong всегда 64 битная

(In reply to comment #6)
> (In reply to comment #4)
> > Это вообще должна была быть 1-строчная функция:
> > 
> > return (jlong) calloc(1, sizeof(handle_t));
> 
> Так работать не будет на 32 битной системе, т.к. jlong всегда 64 битная

Очего же не будет, еще как будет.

(В ответ на комментарий №5)
> Неа. Там возвращается адрес локальной переменной.

Не надо читать багзиллу по утрам. Сморозил чушь, забудьте.