This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 23 Apr 2015 14:46, Szabolcs Nagy wrote: > On 09/03/15 15:29, Szabolcs Nagy wrote: > > members, which seems wrong (i'd expect unsigned int like in > > the kernel linux/elfcore.h) > > > > the procfs.h header seems to be something that should be > > only used by debuggers which probably rely on kernel headers > > or define their own instead of using libc headers. > > is this correct? > > can i fix this? > > should this header be removed completely? > > > > (3) __uint128_t in user.h > > > > aarch64 user_fpsimd_struct has > > > > __uint128_t vregs[32]; > > > > member to represent the 128bit floating point registers > > > > is it ok to expose __uint128_t in public headers? > > (i'd prefer 'long double' so compilers without __uint128 > can use signal.h) vregs is supposed to hold the content of the registers. it doesn't need to be able to represent the data directly (i.e. use doubles). using uint128_t is the right thing to do here. > these are abi breaking changes, what is the policy for that, > can i fix it? if they don't match the kernel, then they're already broken -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |