Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jan 2016 00:07:39 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: string word-at-a-time and atomic.h FAQ on twitter

* Alexander Cherepanov <ch3root@...nwall.com> [2016-01-13 00:09:56 +0300]:
> On 2016-01-13 00:02, Alexander Cherepanov wrote:
> >On 2016-01-05 19:46, Szabolcs Nagy wrote:
> >>i think compiler attributes should be used here on compilers that
> >>might break the code, but there is no attribute for this kind of
> >>oob access yet (although may_alias attribute is missing here too
> >>and should be added like in other string functions).
> >
> >Perhaps the noclone function attribute could be used in the meantime?
> >
> >https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007bnoclone_007d-function-attribute-3205
> 
> Probably together with the noinline attribute...
> 
> Another attribute which looks relevant is no_sanitize_address.
> 
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007bno_005fsanitize_005faddress_007d-function-attribute-3199
> 

i think a no-lto attr should be used, maybe noinline
can achieve that.

no-instrumentation attrs are ugly because new
instrumentations may appear in new compilers and then
your code becomes decorated.
(libc does not work with asan instrumentation anyway
without serious changes and asan runtime implementation
inside the libc)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.