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 varian
Quoth Chris Down:
> On 14 July 2013 20:42, Nick 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 unexpectedly evi
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 suck
On Jul 16, 2013 3:58 AM, "Nick" wrote:
>
> Quoth Chris Down:
> > On 14 July 2013 20:42, Nick 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 b
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
17:10⎜«Vutra
On Jul 16, 2013 9:58 AM, "Nick" 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
directory.
Dmi
