On Sat, Dec 17, 2011 at 7:54 PM, peter green wrote:
>> Your patch to fix ucontext namespace pollution looks good, please post
>> that to libc-ports for review
>
> should I send it immidiately or should I wait until I have test results to
> give them?
Wait until the test results are complete and y
ISO C99 says that WCHAR_MAX must be a constant expression and the
above definition is such an expression. Technically the program needs
fixing (see below though for the "standards matter but so do users"),
there is nothing wrong with a type cast and a constant value e.g.
signed -1 converted to u
On Sat, Dec 17, 2011 at 7:57 AM, peter green wrote:
>> mind also looking at WCHAR_MIN/MAX undefined for arm?
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937
>
> They most certainly are defined. The trouble is that WCHAR_MAX is defined
> in a strange way.
>
> #define __WCHAR_MAX ( (w
Konstantinos Margaritis wrote:
Does anyone know what the impact of renaming these to use a REG_ prefix like
i386, amd64 and sparc do* would be?
at worst the packages that had to be workaround on arm* for this, can
have the workaround removed.
I have prepared a patch (attatched) that eliminates t
On 17 December 2011 09:17, peter green
wrote:
> While we are talking about modifying sys/ucontext.h David Given
> raised another issue with that header (for those reading on the linaro list
> his
> post can be found at
> http://lists.debian.org/debian-arm/2011/12/msg00048.html)
> David Given>This
Ulrich Weigand>Now, glibc also provides a file that defines
Ulrich Weigand>layouts of register sets for use with signal handlers as well
Ulrich Weigand>as the makecontext/setcontext/getcontext family of routines.
Ulrich Weigand>
Ulrich Weigand>Usually, those layouts tend to be in fact identical t
Wookey wrote:
> We can
> 1) Change every app in the world that defines a 'struct user'
> 2) Stop these headers getting brought in when not actually needed
> (it's a relatively recent change that brings it in)
> 3) Change the name in glibc/GDB to something less likely to clash
Some background fro
This subject came up on debian-arm:
http://lists.debian.org/debian-arm/2011/12/msg00025.html
And it seems like the sort of architectural issue linaro should take
an interest in fixing to avoid making people's lives difficult when
building on arm. Is it on anyone's list already?
In short:
A C ap
8 matches
Mail list logo
