On Wed, Nov 15, 2017 at 3:42 PM, Grant Edwards
wrote:
> On 2017-11-15, R0b0t1 wrote:
>> Apologies for the double post,
>>
>> On Wed, Nov 15, 2017 at 9:41 AM, R0b0t1 wrote:
>>> On Wed, Nov 15, 2017 at 1:22 AM, Jorge Almeida
On 2017-11-15, R0b0t1 wrote:
> Apologies for the double post,
>
> On Wed, Nov 15, 2017 at 9:41 AM, R0b0t1 wrote:
>> On Wed, Nov 15, 2017 at 1:22 AM, Jorge Almeida wrote:
>>> On Tue, Nov 14, 2017 at 8:42 PM, R0b0t1
On 11/15/2017 10:50 AM, Jorge Almeida wrote:
>
> Are you really sure? I was under the impression that ebuilds did it,
> and I find that natural. I didn't view that as a bug at all.
On principle, most things in the tree should respect whatever CFLAGS,
LDFLAGS, etc. you ask for. The problems
On Wed, Nov 15, 2017 at 7:41 AM, R0b0t1 wrote:
> On Wed, Nov 15, 2017 at 1:22 AM, Jorge Almeida wrote:
>> On Tue, Nov 14, 2017 at 8:42 PM, R0b0t1 wrote:
>> You can set your optimization preferences in make.conf, and still an
>> ebuild
Apologies for the double post,
On Wed, Nov 15, 2017 at 9:41 AM, R0b0t1 wrote:
> On Wed, Nov 15, 2017 at 1:22 AM, Jorge Almeida wrote:
>> On Tue, Nov 14, 2017 at 8:42 PM, R0b0t1 wrote:
>>> What I am wondering about is if C code which uses
On Wed, Nov 15, 2017 at 1:22 AM, Jorge Almeida wrote:
> On Tue, Nov 14, 2017 at 8:42 PM, R0b0t1 wrote:
>> What I am wondering about is if C code which uses
>> __attribute__((optimize(...))) is against Gentoo package standards and
>> would have to be removed
On 2017-11-15, R0b0t1 wrote:
> What I am wondering about is if C code which uses
> __attribute__((optimize(...))) is against Gentoo package standards and
> would have to be removed from the Portage tree.
Huh?
Gentoo enforces standards for the source code of packages?
"They"
On 15/11/17 11:05, Jorge Almeida wrote:
On Wed, Nov 15, 2017 at 12:54 AM, Nikos Chantziaras wrote:
On 14/11/17 19:36, Jorge Almeida wrote:
On Fri, Nov 10, 2017 at 12:09 PM, Jorge Almeida
wrote:
Unless you look at the assembly output, you can't be
On Wed, Nov 15, 2017 at 12:54 AM, Nikos Chantziaras wrote:
> On 14/11/17 19:36, Jorge Almeida wrote:
>>
>> On Fri, Nov 10, 2017 at 12:09 PM, Jorge Almeida
>> wrote:
>>
>
> Unless you look at the assembly output, you can't be sure. Some optimization
> is
On 14/11/17 19:36, Jorge Almeida wrote:
On Fri, Nov 10, 2017 at 12:09 PM, Jorge Almeida wrote:
http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html
Of course, what would really solve the optimize-into-oblivion problem
is a pragma that when invoked on a
On 13/11/17 13:38, Mart Raudsepp wrote:
On E, 2017-11-13 at 12:44 +0200, Nikos Chantziaras wrote:
explicit_bzero() is available in glibc. It's in .
Interesting. Some Xorg stuff is using libbsd explicitly, but probably
since before glibc gained this. This is new since glibc-2.25.
Oops,
On E, 2017-11-13 at 12:44 +0200, Nikos Chantziaras wrote:
> On 13/11/17 09:17, Jorge Almeida wrote:
> >
> > On Sun, Nov 12, 2017 at 7:03 PM, Mart Raudsepp
> > wrote:
> > >
> > > On L, 2017-11-11 at 00:10 +, Jorge Almeida wrote:
> > > >
> > > > Well, most programmers
On Mon, Nov 13, 2017 at 2:44 AM, Nikos Chantziaras wrote:
>>>
>>> Sounds like you want explicit_bzero from libbsd?
>>>
>> According to their man page, yes. I'll have to [try to] check the
>> source. I wonder how they do it? Even the volatile modifier doesn't
>> solve the
On 13/11/17 09:17, Jorge Almeida wrote:
On Sun, Nov 12, 2017 at 7:03 PM, Mart Raudsepp wrote:
On L, 2017-11-11 at 00:10 +, Jorge Almeida wrote:
Well, most programmers probably won't care about this stuff anyway,
and people who deal with cryptography tend to be more
On 10/11/17 11:54, Jorge Almeida wrote:
I'm trying to use memset_s() but the system (glibc?) doesn't know
about it. I also tried to compile against musl, same result.
There's precious little info about memset_s in the net. Does it exist
at all? No man page.
$ grep -r memset_s /usr/include
15 matches
Mail list logo