Did the test and compiled the attached programs to assembly without any
optimization flags.
The result was as you said, the code for accessing the bit field was so huge
that it wasn't worth it. The programs used equal CPU time though.
With the -Os flag, the code generated for the bit field
Quoth Chris Down:
On 14 July 2013 20:42, Nick suckless-...@njw.me.uk wrote:
I'd be inclined to check for and filter out leading .. and /
characters, to avoid tarballs doing unexpectedly evil things.
I think all security onus for stuff like that should be on the user --
they can still do
The attached patch ensures surf adheres more closely to the CSS spec
in making one px equal to 1/96 inch, regardless of the actual screen
pixel density. This is a typical web-style cop-out for the fact that
many stupid web designers only write things in terms of ~96dpi
desktop monitors. It
On Jul 16, 2013 3:58 AM, Nick suckless-...@njw.me.uk wrote:
Quoth Chris Down:
On 14 July 2013 20:42, Nick suckless-...@njw.me.uk wrote:
I'd be inclined to check for and filter out leading .. and /
characters, to avoid tarballs doing unexpectedly evil things.
I think all security onus
Nick dixit:
What other evil things can tar creators do?
Symlinks with st_nlink ≠ 1 for one ☹ need to fix that
in paxmirabilis (MirCPIO) too.
bye,
//mirabilos
--
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
On Jul 16, 2013 9:58 AM, Nick suckless-...@njw.me.uk wrote:
Going back to the workflow question, then, who here always checks
the list of all files in an archive to check that there's nothing
with a suspicious path?
I always check to see whether content is going to be placed into separate
