On Sat, Feb 13, 2016 at 07:29:48AM +1100, Bruce Evans wrote:
> It needs a version number to be correct. Plain __POSIX_VISIBLE means
> all versions. __POSIX_VISBLE >= 200112 is probably good enough for
> the POSIX part. I don't know the correct number for XSI. Perhaps
> it can be simply
On Sat, 13 Feb 2016, Konstantin Belousov wrote:
On Sat, Feb 13, 2016 at 07:29:48AM +1100, Bruce Evans wrote:
It needs a version number to be correct. Plain __POSIX_VISIBLE means
all versions. __POSIX_VISBLE >= 200112 is probably good enough for
the POSIX part. I don't know the correct
On Sun, Feb 14, 2016 at 04:02:05AM +1100, Bruce Evans wrote:
> The old visibility bugs with mc_* should be fixed someday. I said that
> uc_* could be used. _mc_* should have been used originally. Maybe we
> can just change to either of these, since nothing except libc should
> have used the
On Sat, 13 Feb 2016, Konstantin Belousov wrote:
On Sun, Feb 14, 2016 at 04:02:05AM +1100, Bruce Evans wrote:
The old visibility bugs with mc_* should be fixed someday. I said that
uc_* could be used. _mc_* should have been used originally. Maybe we
can just change to either of these, since
On Sun, Feb 14, 2016 at 05:47:19AM +1100, Bruce Evans wrote:
> How likely is third party code to use undocumented internals of opqaue
> types when FreeBSD code mostly doesn't used them.
I already said that they are used. Base system cannot be a benchmark
there because base code does not implement
On Fri, 12 Feb 2016, Konstantin Belousov wrote:
Log:
POSIX states that #include shall make both mcontext_t and
ucontext_t available. Our code even has XXX comment about this.
Only newer versions of POSIX have this bug. In the 2001 version, the
bug was limited to the XSI section. was
On Sat, Feb 13, 2016 at 01:08:55AM +1100, Bruce Evans wrote:
> On Fri, 12 Feb 2016, Konstantin Belousov wrote:
>
> > Log:
> > POSIX states that #include shall make both mcontext_t and
> > ucontext_t available. Our code even has XXX comment about this.
>
> Only newer versions of POSIX have
On Fri, Feb 12, 2016 at 04:13:53PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 12, 2016 at 01:22:04PM +, Ruslan Bukin wrote:
> > On RISC-V it fails with __uint128_t:
> >
> > struct fpregs {
> > __uint128_t fp_x[32];
> >
> > how to fix?
> You did not copied the error.
sorry,
On Fri, Feb 12, 2016 at 02:18:22PM +, Ruslan Bukin wrote:
> On Fri, Feb 12, 2016 at 04:13:53PM +0200, Konstantin Belousov wrote:
> > On Fri, Feb 12, 2016 at 01:22:04PM +, Ruslan Bukin wrote:
> > > On RISC-V it fails with __uint128_t:
> > >
> > > struct fpregs {
> > > __uint128_t
On Fri, 12 Feb 2016, Konstantin Belousov wrote:
On Fri, Feb 12, 2016 at 01:22:04PM +, Ruslan Bukin wrote:
On RISC-V it fails with __uint128_t:
struct fpregs {
__uint128_t fp_x[32];
how to fix?
You did not copied the error.
If my guess is correct, the issue is that
On Fri, 12 Feb 2016, Ruslan Bukin wrote:
On RISC-V it fails with __uint128_t:
struct fpregs {
__uint128_t fp_x[32];
how to fix?
This seems to be an old bug. __uint128_t shouldn't be used unless it
is supported by . In old versions of FreeBSD, I used
something like
On RISC-V it fails with __uint128_t:
struct fpregs {
__uint128_t fp_x[32];
how to fix?
Ruslan
On Fri, Feb 12, 2016 at 07:38:20AM +, Konstantin Belousov wrote:
> Author: kib
> Date: Fri Feb 12 07:38:19 2016
> New Revision: 295561
> URL:
On Fri, Feb 12, 2016 at 01:22:04PM +, Ruslan Bukin wrote:
> On RISC-V it fails with __uint128_t:
>
> struct fpregs {
> __uint128_t fp_x[32];
>
> how to fix?
You did not copied the error.
If my guess is correct, the issue is that __uint128_t typedef is not
present in the
On Fri, 12 Feb 2016, Konstantin Belousov wrote:
On Sat, Feb 13, 2016 at 01:08:55AM +1100, Bruce Evans wrote:
On Fri, 12 Feb 2016, Konstantin Belousov wrote:
...
Modified: head/include/signal.h
==
---
On Sat, Feb 13, 2016 at 03:56:42AM +1100, Bruce Evans wrote:
> Our Standard C namespace is a subset of the POSIX namespace. Most
> Standard C headers are (were) careful about this. There aren't many
> Standard C headers or versions of Standard C or large variations in the
> versions, so this is
On Sat, Feb 13, 2016 at 02:19:21AM +1100, Bruce Evans wrote:
> On Fri, 12 Feb 2016, Konstantin Belousov wrote:
>
> > On Fri, Feb 12, 2016 at 01:22:04PM +, Ruslan Bukin wrote:
> >> On RISC-V it fails with __uint128_t:
> >>
> >> struct fpregs {
> >> __uint128_t fp_x[32];
> >>
> >>
On Fri, 12 Feb 2016, Konstantin Belousov wrote:
On Sat, Feb 13, 2016 at 03:56:42AM +1100, Bruce Evans wrote:
Our Standard C namespace is a subset of the POSIX namespace. Most
Standard C headers are (were) careful about this. There aren't many
Standard C headers or versions of Standard C or
Author: kib
Date: Fri Feb 12 07:38:19 2016
New Revision: 295561
URL: https://svnweb.freebsd.org/changeset/base/295561
Log:
POSIX states that #include shall make both mcontext_t and
ucontext_t available. Our code even has XXX comment about this.
Add a bit of compliance by moving struct
18 matches
Mail list logo
