«

I'm using glibc 2.7-r1 packaged by gentoo and gcc 4.2.2 also packaged by
gentoo. The following code results in the value of the void * component
of the sigval struct sent from the sending program being assigned to the
si_int member of the siginfo_t struct.

Sending process:

sigval sigval_data;
sigval_data.sival_int = 1;
sigval_data.sival_ptr = 5; /*only to test this*/
sigqueue(getppid(), SIGUSR1, sigval_data);
pause(); //wait for the parent to die.
exit(-1); //we should have died by SIGHUP before.

Receiving process's signal handler:

void h_mesg(int signal, siginfo_t * info, void * context) {
printf("DEBUG: h_mesg: int value = %i\n", info->si_int);
};

It prints that the value is 5. Have I done something silly, or is this
a bug in glibc or in something else?

--
--Falcon Kirtaran

> sigval sigval_data;
> sigval_data.sival_int = 1;
> sigval_data.sival_ptr = 5; /*only to test this*/
> sigqueue(getppid(), SIGUSR1, sigval_data);

you should ask that kind of stuff in comp.unix.programmer.
Regarding your question, sigval is a union, as such last assignment
wins i.e. .sival_ptr and .sival_int share the same storage location
hence the value 5.

cheers,
-- paulo

ppi wrote:
>> sigval sigval_data;
>> sigval_data.sival_int = 1;
>> sigval_data.sival_ptr = 5; /*only to test this*/
>> sigqueue(getppid(), SIGUSR1, sigval_data);
>
> you should ask that kind of stuff in comp.unix.programmer.
> Regarding your question, sigval is a union, as such last assignment
> wins i.e. .sival_ptr and .sival_int share the same storage location
> hence the value 5.
>
> cheers,
> -- paulo
>

Thank you. So I suppose I should not assign to both, then.

Falcon Kirtaran wrote:

> ppi wrote:
>>> sigval sigval_data;
>>> sigval_data.sival_int = 1;
>>> sigval_data.sival_ptr = 5; /*only to test this*/
>>> sigqueue(getppid(), SIGUSR1, sigval_data);
>>
>> you should ask that kind of stuff in comp.unix.programmer.
>> Regarding your question, sigval is a union, as such last assignment
>> wins i.e. .sival_ptr and .sival_int share the same storage location
>> hence the value 5.

> Thank you. So I suppose I should not assign to both, then.

You can, but you can only legally access the object to which the latest
write was done.

Also (n1256 - 6.5.2.3p5):

One special guarantee is made in order to simplify the use of unions: if
a union contains several structures that share a common initial
sequence (see below), and if the union object currently contains one of
these structures, it is permitted to inspect the common initial part of
any of them anywhere that a declaration of the complete type of the
union is visible. Two structures share a common initial sequence if
corresponding members have compatible types (and, for bit-fields, the
same widths) for a sequence of one or more initial members.

A footnote (not normative) also adds:

If the member used to access the contents of a union object is not the
same as the member last used to store a value in the object, the
appropriate part of the object representation of the value is
reinterpreted as an object representation in the new type as described
in 6.2.6 (a process sometimes called "type punning"). This might be a
trap representation.