Dear programming language types,
I wrote this to try once again to explain what is the nature of the
problem that one would have in verifying the integrity of _any_
software toolchain, whether it is aimed ultimately at the production
of other software, or of hardware.
http://livelogic.blogspo
The following is a response to what some may think an implausible
suggestion made here:
http://lists.gnu.org/archive/html/guile-devel/2014-09/msg00124.html
The suggestion is that the system of education has been subverted so
that there are "unknown" physical laws which give "the unseen enemy"
whole lot, does it?
Thanks again for your helpful response. This is progress.
Ian
On Fri, Sep 19, 2014 at 8:04 PM, Andrew Pinski wrote:
> On Fri, Sep 19, 2014 at 4:52 PM, Ian Grant
> wrote:
>> None of this is useful to me. I'm trying to make a case for why people
>> sho
e:
>> On 19 September 2014 16:21, Ian Grant wrote:
>>> Thanks. But I asked what the non-vanilla sources were. I know what
>>> the vanilla sources are, because I'm using them!
>>
>> The non-vanilla sources are everything else. That should be pretty obvious.
&g
ible in a very
crude form. By the end of the period I knew that the design of
sophisticated digital systems was the perfect field of activity for
the Mathematical Engineer."
[1] Edsger W. Dijkstra. EWD1303
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303
On Thu, Sep 18, 2014 at 10:35 PM, Thomas Preud'homme
wrote:
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Ian Grant
>>
>> And can anyone tell me what are the 'non-vanilla' sources?
>
> "Vanilla source" ref
On Thu, Sep 18, 2014 at 9:37 PM, Joe Buck wrote:
> (delurking)
> Ah, this is commonly called the Thompson hack, since Ken Thompson
> actually produced a successful demo:
How do you know Thompson's attempt was the first instance? The
document I refer to in the blog is the "Unknown Air Force Repor
In case it isn't obvious, what I am interested in is how easily we can
know the problem of infeasibly large binaries isn't an instance of
this one:
http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html
Ian
On Thu, Sep 18, 2014 at 8:32 PM, Jonathan Wakely wrote:
>> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>>text databssdechexfilename
>> 14965183 23708 74494415733835 f0144b
>> i686-pc-linux-gnu/4.9.0/cc1
>> 15882830
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> Have you compared the binaries using size(1) instead of ls(1)?
Actually, when I look at the output of size I realise
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>>>> I can compile the first stage OK, and
On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> I can compile the first stage OK, and the binaries are quite modest:
>>
>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
>> -rwxr-xr-x 1 i
On Thu, Sep 18, 2014 at 5:37 PM, Ian Grant wrote:
>
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> > The reason I'm doing this is that I want to understand why the total
>> > s
On Wed, Sep 17, 2014 at 2:59 PM, Marc Glisse wrote:
>>> Please don't call it "the Intel library", that doesn't mean anything.
>> Doesn't it? How did you know what 'it' was then? Or is that a stupid
>> question? This identity concept is much slipperier than it seems at
>> first, isn't it?
> You in
On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote:
> On Wed, 17 Sep 2014, Ian Grant wrote:
>
>> And is there any way to disable the Intel library?
> --disable-libcilkrts (same as the other libs)
> If it explicitly doesn't support your system, I am a bit surpri
The reason I'm doing this is that I want to understand why the total
size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
4.9
I can compile the first stage OK, and the binaries are quite modest:
-rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
-rwxr-xr-x 1 ian ian 1.2
The reason I'm doing this is that I want to understand why the total
size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
4.9
I can compile the first stage OK, and the binaries are quite modest:
-rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
-rwxr-xr-x 1 ian ian 1.2
17 matches
Mail list logo
