--===============2541425552073832700== Content-Type: multipart/alternative; boundary=001a11c2329268431f051d355b55 --001a11c2329268431f051d355b55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2015 at 1:52 AM, Sjoerd Meijer wrote: > Hi Richard, > > Thanks for reviewing. Agree, that was a bit confusing. More specifically, > > the warning message was confusing (i.e. wrong). This patch is for > compiling .c > > input in C++ mode. The new flag should be ignored for C++ **input**, and > indeed > > not when it is in C++ *mode* as the warning message said earlier. So I > have > > changed the warning message accordingly and hope that solves it, see > attached > > patch. > What is the distinction you're trying to draw here? This patch still doesn't make sense to me. This flag is only meaningful when compiling as C++. You ignore it when compiling as C but produce a warning that says it's ignored when compiling as C++. > Cheers. > > > > *From:* metafoo@gmail.com [mailto:metafoo@gmail.com] *On Behalf Of *Richa= rd > Smith > *Sent:* 12 August 2015 23:06 > *To:* Sjoerd Meijer > *Cc:* Hal Finkel; Marshall Clow; cfe-commits > > *Subject:* Re: [PATCH] RE: [cfe-dev] missing return statement for > non-void functions in C++ > > > > This patch seems a bit confused. You warn that the flag is ignored in C++= , > but it only has an effect in C++. You have a testcase with a .c extension > that is built with -x c++. > > > > On Wed, Aug 12, 2015 at 5:23 AM, Sjoerd Meijer > wrote: > > [ + cfe-commits@lists.llvm.org ] > > > > Hi, > > The functionality is now available under a flag, see attached patch. Note > that the flag is ignored in C++ mode, so it will help the use case of > compiling (legacy) C code with a C++ compiler. > > Cheers, > > Sjoerd. > > > > *From:* Sjoerd Meijer [mailto:sjoerd.meijer@arm.com > ] > *Sent:* 03 August 2015 11:40 > *To:* 'Richard Smith' > *Cc:* Hal Finkel; Marshall Clow; cfe-dev@cs.uiuc.edu Developers; cfe > commits > *Subject:* RE: [PATCH] RE: [cfe-dev] missing return statement for > non-void functions in C++ > > > > Hi Richard, > > > > I agree with your conclusions and will start preparing a patch for option > 3) under a flag that is off by default; this enables folks to build/run C > code in C++. I actually think option 2) would be a good one too, but as i= t > is already available under a flag I also don=E2=80=99t see how useful it = is > combining options 2) and 3) with another (or one more) flag that is off b= y > default. > > > > Cheers. > > > > *From:* metafoo@gmail.com [mailto:metafoo@gmail.com ] = *On > Behalf Of *Richard Smith > *Sent:* 31 July 2015 19:46 > *To:* Sjoerd Meijer > *Cc:* Hal Finkel; Marshall Clow; cfe-dev@cs.uiuc.edu Developers; cfe > commits > *Subject:* Re: [PATCH] RE: [cfe-dev] missing return statement for > non-void functions in C++ > > > > On Fri, Jul 31, 2015 at 7:35 AM, Sjoerd Meijer > wrote: > > Hi, I am not sure if we came to a conclusion. Please find attached a > patch. It simply removes the two lines that insert an unreachable stateme= nt > (which cause removal of the return statement). Please note that at -O0 th= e > trap instruction is still generated. Is this something we could live with= ? > > > > I don't think this is an improvement: > > > > This doesn't satisfy the folks who want an 'unreachable' for better code > size and optimization, and it doesn't satisfy the folks who want a > guaranteed trap for security, and it doesn't satisfy the folks who want > their broken code to limp along (because it'll still trap at -O0), and it > is at best a minor improvement for the folks who want missing returns to = be > more easily debuggable (with -On, the code goes wrong in the caller, or > appears to work, rather than falling into an unrelated function, and > debugging this with -O0 was already easy). > > > > I think there are three options that are defensible here: > > 1) The status quo: this is UB and we treat it as such and optimize on tha= t > basis, but provide a trap as a convenience at -O0 > > 2) The secure approach: this is UB but we always trap > > 3) Define the behavior to return 'undef' for C types: this allows > questionable C code that has UB in C++ to keep working when built with a > C++ compiler > > > > Note that (3) can be combined with either (1) or (2). (2) is already > available via the 'return' sanitizer. So this really reduces to: in those > cases where C says it's OK so long as the caller doesn't look at the > returned value (and where the return type doesn't have a non-trivial copy > constructor or destructor, isn't a reference, and so on), should we attem= pt > to preserve the C behaviour? I would be OK with putting that behind a `-f= ` > flag (perhaps `-fstrict-return` or similar) to support those folks who wa= nt > to build C code in C++, but I would suggest having that flag be off by > default, since that is not the usual use case for a C++ compiler. > > > > Cheers, > > Sjoerd. > > > > *From:* cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] = *On > Behalf Of *Richard Smith > *Sent:* 29 July 2015 18:07 > *To:* Hal Finkel > *Cc:* Marshall Clow; cfe-dev@cs.uiuc.edu Developers > > > *Subject:* Re: [cfe-dev] missing return statement for non-void functions > in C++ > > > > On Jul 29, 2015 7:43 AM, "Hal Finkel" wrote: > > > > ----- Original Message ----- > > > From: "David Blaikie" > > > To: "James Molloy" > > > Cc: "Marshall Clow" , "cfe-dev Developers" < > cfe-dev@cs.uiuc.edu> > > > Sent: Wednesday, July 29, 2015 9:15:09 AM > > > Subject: Re: [cfe-dev] missing return statement for non-void function= s > in C++ > > > > > > > > > On Jul 29, 2015 7:06 AM, "James Molloy" < james@jamesmolloy.co.uk > > > > wrote: > > > > > > > > Hi, > > > > > > > > If we're going to emit a trap instruction (and thus create a broken > > > > binary), why don't we error instead? > > > > > > We warn, can't error, because it may be dynamically unreached, in > > > which case the program is valid and we can't reject it. > > > > I think this also explains why this is useful for optimization. > > > > 1. It is a code-size optimization > > 2. By eliminating unreachable control flow, we can remove branches and > tests that are not actual necessary > > > > int foo(int x) { > > if (x > 5) return 2*x; > > else if (x < 2) return 3 - x; > > } > > > > That having been said, there are other ways to express these things, an= d > the situation often represents an error. I'd be fine with requiring a > special flag (-fallow-nonreturning-functions or whatever) in order to put > the compiler is a truly confirming mode (similar to the situation with > sized delete). > > Note that we already have a flag to trap on this: -fsanitize-trap=3Dretur= n. > (You may also need -fsanitize=3Dreturn, I don't remember.) That seems > consistent with how we treat most other forms of UB. > > > -Hal > > > > > > > > > > > > > James > > > > > > > > On Wed, 29 Jul 2015 at 15:05 David Blaikie < dblaikie@gmail.com > > > > > wrote: > > > >> > > > >> > > > >> On Jul 29, 2015 2:10 AM, "mats petersson" < mats@planetcatfish.com > > > >> > wrote: > > > >> > > > > >> > > > > >> > > > > >> > On 28 July 2015 at 23:40, Marshall Clow < mclow.lists@gmail.com > > > >> > > wrote: > > > >> >> > > > >> >> > > > >> >> > > > >> >> On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer < > > > >> >> sjoerd.meijer@arm.com > wrote: > > > >> >>> > > > >> >>> Hi, > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> In C++, the undefined behaviour of a missing return statements > > > >> >>> for a non-void function results in not generating the > > > >> >>> function epilogue (unreachable statement is inserted and the > > > >> >>> return statement is optimised away). Consequently, the > > > >> >>> runtime behaviour is that control is never properly returned > > > >> >>> from this function and thus it starts executing =E2=80=9Cgarba= ge > > > >> >>> instructions=E2=80=9D. As this is undefined behaviour, this is > > > >> >>> perfectly fine and according to the spec, and a compile > > > >> >>> warning for this missing return statement is issued. However, > > > >> >>> in C, the behaviour is that a function epilogue is generated, > > > >> >>> i.e. basically by returning uninitialised local variable. > > > >> >>> Codes that rely on this are not beautiful pieces of code, i.e > > > >> >>> are buggy, but it might just be okay if you for example have > > > >> >>> a function that just initialises stuff (and the return value > > > >> >>> is not checked, directly or indirectly); some one might argue > > > >> >>> that not returning from that function might be a bit harsh. > > > >> >> > > > >> >> > > > >> >> I would not be one of those people. > > > >> > > > > >> > > > > >> > Nor me. > > > >> >> > > > >> >> > > > >> >>> > > > >> >>> So this email is to probe if there would be strong resistance > > > >> >>> to follow the C behaviour? I am not yet sure how, but would > > > >> >>> perhaps a compromise be possible/acceptable to make the > > > >> >>> undefined behaviour explicit and also generate the function > > > >> >>> epilogue? > > > >> >> > > > >> >> > > > >> >> "undefined behavior" is exactly that. > > > >> >> > > > >> >> You have no idea what is going to happen; there are no > > > >> >> restrictions on what the code being executed can do. > > > >> >> > > > >> >> "it just might be ok" means on a particular version of a > > > >> >> particular compiler, on a particular architecture and OS, at a > > > >> >> particular optimization level. Change any of those things, and > > > >> >> you can change the behavior. > > > >> > > > > >> > > > > >> > In fact, the "it works kind of as you expected" is the worst > > > >> > kind of UB in my mind. UB that causes a crash, stops or other > > > >> > "directly obvious that this is wrong" are MUCH easier to debug. > > > >> > > > > >> > So make this particular kind of UB explicit by crashing or > > > >> > stopping would be a good thing. Making it explicit by > > > >> > "returning kind of nicely, but not correct return value" is > > > >> > about the worst possible result. > > > >> > > > >> At -O0 clang emits a trap instruction, making it more explicit as > > > >> you suggest. At higher optimization levels it just falls > > > >> through/off. > > > >> > > > >> > > > > >> > -- > > > >> > Mats > > > >> >> > > > >> >> > > > >> >> -- Marshall > > > >> >> > > > >> >> > > > >> >> _______________________________________________ > > > >> >> cfe-dev mailing list > > > >> >> cfe-dev@cs.uiuc.edu > > > >> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > >> >> > > > >> > > > > >> > > > > >> > _______________________________________________ > > > >> > cfe-dev mailing list > > > >> > cfe-dev@cs.uiuc.edu > > > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > >> > > > > >> > > > >> _______________________________________________ > > > >> cfe-dev mailing list > > > >> cfe-dev@cs.uiuc.edu > > > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > > _______________________________________________ > > > cfe-dev mailing list > > > cfe-dev@cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > --001a11c2329268431f051d355b55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 13, 2015 at 1:52 AM, Sjoerd Meijer <Sjoerd.Meijer@arm.com&= gt; wrote:

Hi Richard,=

Thanks for reviewing. Agr= ee, that was a bit confusing. More specifically,

the warning message was c= onfusing (i.e. wrong). This patch is for compiling .c

input in C++ mode. The ne= w flag should be ignored for C++ *input*, and indeed

not when it is in C++ *mo= de* as the warning message said earlier. So I have

changed the warning messa= ge accordingly and hope that solves it, see attached

patch.


What is the distinction you're try= ing to draw here? This patch still doesn't make sense to me. This flag = is only meaningful when compiling as C++. You ignore it when compiling as C= but produce a warning that says it's ignored when compiling as C++.
=C2=A0

Cheers.

=C2=A0

From: metafoo@gmail.com [mailto:metafoo@gmail.com] On Behalf Of Richard Smith
Sent: 12 August 2015 23:06
To: Sjoerd Meijer
Cc: Hal Finkel; Marshall Clow; cfe-commits


Subject: Re: [PATCH] RE: [cfe-dev] missing return statement for non-= void functions in C++

=C2=A0

This patch seems a bit confused. You warn that the f= lag is ignored in C++, but it only has an effect in C++. You have a testcas= e with a .c extension that is built with -x c++.

=C2=A0

On Wed, Aug 12, 2015 at 5:23 AM, Sjoerd Meijer <<= a href=3D"mailto:sjoerd.meijer@arm.com" target=3D"_blank">sjoerd.meijer@arm= .com> wrote:

[ + cfe-commits= @lists.llvm.org ]

=C2=A0

Hi,<= /p>

The functionality is now = available under a flag, see attached patch. Note that the flag is ignored in C++ mode, so it will help the use case of compiling (legacy) C code wit= h a C++ compiler.

Cheers,<= /u>

Sjoerd.<= /u>

=C2=A0

From: Sjoerd Meijer [mailto:= sjoerd.meijer@arm.com]
Sent: 03 August 2015 11:40
To: 'Richard Smith'
Cc: Hal Finkel; Marshall Clow; cfe-dev@cs.uiuc.edu Developers; cfe commits
Subject: RE: [PATCH] RE: [cfe-dev] missing return statement for non-= void functions in C++

=C2=A0

Hi Richard,=

=C2=A0

I agree with your conclus= ions and will start preparing a patch for option 3) under a flag that is off by default; this enables folks to build/run C code in C++. I actually = think option 2) would be a good one too, but as it is already available und= er a flag I also don=E2=80=99t see how useful it is combining options 2) an= d 3) with another (or one more) flag that is off by default.

=C2=A0

Cheers.<= /u>

=C2=A0

From: metafoo@gmail.com [mailto:metafoo@gm= ail.com] On Behalf Of Richard Smith
Sent: 31 July 2015 19:46
To: Sjoerd Meijer
Cc: Hal Finkel; Marshall Clow; cfe-dev@cs.uiuc.edu Developers; cfe commits
Subject: Re: [PATCH] RE: [cfe-dev] missing return statement for non-= void functions in C++

=C2=A0

On Fri, Jul 31, 2015 at 7:35 AM, Sjoerd Meijer <<= a href=3D"mailto:sjoerd.meijer@arm.com" target=3D"_blank">sjoerd.meijer@arm= .com> wrote:

Hi, I am not sure if we c= ame to a conclusion. Please find attached a patch. It simply removes the two lines that insert an unreachable statement (which cause removal of the= return statement). Please note that at -O0 the trap instruction is still g= enerated. Is this something we could live with?

=C2=A0

I don't think this is an improvement:<= /u>

=C2=A0

This doesn't satisfy the folks who want an '= unreachable' for better code size and optimization, and it doesn't = satisfy the folks who want a guaranteed trap for security, and it doesn't satisfy the folks who want their broken code to limp along (be= cause it'll still trap at -O0), and it is at best a minor improvement f= or the folks who want missing returns to be more easily debuggable (with -O= n, the code goes wrong in the caller, or appears to work, rather than falling into an unrelated function, and debug= ging this with -O0 was already easy).

=C2=A0

I think there are three options that are defensible = here:

1) The status quo: this is UB and we treat it as suc= h and optimize on that basis, but provide a trap as a convenience at -O0=

2) The secure approach: this is UB but we always tra= p

3) Define the behavior to return 'undef' for= C types: this allows questionable C code that has UB in C++ to keep workin= g when built with a C++ compiler

=C2=A0

Note that (3) can be combined with either (1) or (2)= . (2) is already available via the 'return' sanitizer. So this real= ly reduces to: in those cases where C says it's OK so long as the caller doesn't look at the returned value (and where the return= type doesn't have a non-trivial copy constructor or destructor, isn= 9;t a reference, and so on), should we attempt to preserve the C behaviour?= I would be OK with putting that behind a `-f` flag (perhaps `-fstrict-return` or similar) to support those folks who wan= t to build C code in C++, but I would suggest having that flag be off by de= fault, since that is not the usual use case for a C++ compiler.

=C2=A0

Cheers,<= /u>

Sjoerd.<= /u>

=C2=A0

From: cfe-dev-bo= unces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] On Behalf Of Richard Smith
Sent: 29 July 2015 18:07
To: Hal Finkel
Cc: Marshall Clow; cfe-dev@cs.uiuc.edu Developers


Subject: Re: [cfe-dev] missing return statement for non-void functio= ns in C++

=C2=A0

On Jul 29, 2015 7:43 AM, "Hal Finkel" <hfinkel@anl.gov> wrote:
>
> ----- Original Message -----
> > From: "David Blaikie" <dblaikie@gmail.com>
> > To: "James Molloy" <james@jamesmolloy.co.uk>
> > Cc: "Marshall Clow" <mclow.lists@gmail.com>, "cfe-dev De= velopers" <cfe-dev@cs.uiuc.edu>
> > Sent: Wednesday, July 29, 2015 9:15:09 AM
> > Subject: Re: [cfe-dev] missing return statement for non-void func= tions in C++
> >
> >
> > On Jul 29, 2015 7:06 AM, "James Molloy" < james@jamesmolloy.co.uk >
> > wrote:
> > >
> > > Hi,
> > >
> > > If we're going to emit a trap instruction (and thus crea= te a broken
> > > binary), why don't we error instead?
> >
> > We warn, can't error, because it may be dynamically unreached= , in
> > which case the program is valid and we can't reject it.
>
> I think this also explains why this is useful for optimization.
>
> =C2=A01. It is a code-size optimization
> =C2=A02. By eliminating unreachable control flow, we can remove branch= es and tests that are not actual necessary
>
> int foo(int x) {
> =C2=A0 if (x > 5) return 2*x;
> =C2=A0 else if (x < 2) return 3 - x;
> }
>
> That having been said, there are other ways to express these things, a= nd the situation often represents an error. I'd be fine with requiring = a special flag (-fallow-nonreturning-functions or whatever) in order to put= the compiler is a truly confirming mode (similar to the situation with sized delete).

Note that we already have a flag to trap on this: -fsanitize-trap=3Dretu= rn. (You may also need -fsanitize=3Dreturn, I don't remember.) That see= ms consistent with how we treat most other forms of UB.

> =C2=A0-Hal
>
> >
> > >
> > > James
> > >
> > > On Wed, 29 Jul 2015 at 15:05 David Blaikie < dblaikie@gmail.com >
> > > wrote:
> > >>
> > >>
> > >> On Jul 29, 2015 2:10 AM, "mats petersson" <= mats@planetcatfish.com
> > >> > wrote:
> > >> >
> > >> >
> > >> >
> > >> > On 28 July 2015 at 23:40, Marshall Clow < mclow.lists@gmail.com
> > >> > > wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer = <
> > >> >> sjoerd.meijer@arm.com > wrote:
> > >> >>>
> > >> >>> Hi,
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> In C++, the undefined behaviour of a missin= g return statements
> > >> >>> for a non-void function results in not gene= rating the
> > >> >>> function epilogue (unreachable statement is= inserted and the
> > >> >>> return statement is optimised away). Conseq= uently, the
> > >> >>> runtime behaviour is that control is never = properly returned
> > >> >>> from this function and thus it starts execu= ting =E2=80=9Cgarbage
> > >> >>> instructions=E2=80=9D. As this is undefined= behaviour, this is
> > >> >>> perfectly fine and according to the spec, a= nd a compile
> > >> >>> warning for this missing return statement i= s issued. However,
> > >> >>> in C, the behaviour is that a function epil= ogue is generated,
> > >> >>> i.e. basically by returning uninitialised l= ocal variable.
> > >> >>> Codes that rely on this are not beautiful p= ieces of code, i.e
> > >> >>> are buggy, but it might just be okay if you= for example have
> > >> >>> a function that just initialises stuff (and= the return value
> > >> >>> is not checked, directly or indirectly); so= me one might argue
> > >> >>> that not returning from that function might= be a bit harsh.
> > >> >>
> > >> >>
> > >> >> I would not be one of those people.
> > >> >
> > >> >
> > >> > Nor me.
> > >> >>
> > >> >>
> > >> >>>
> > >> >>> So this email is to probe if there would be= strong resistance
> > >> >>> to follow the C behaviour? I am not yet sur= e how, but would
> > >> >>> perhaps a compromise be possible/acceptable= to make the
> > >> >>> undefined behaviour explicit and also gener= ate the function
> > >> >>> epilogue?
> > >> >>
> > >> >>
> > >> >> "undefined behavior" is exactly that.=
> > >> >>
> > >> >> You have no idea what is going to happen; there= are no
> > >> >> restrictions on what the code being executed ca= n do.
> > >> >>
> > >> >> "it just might be ok" means on a part= icular version of a
> > >> >> particular compiler, on a particular architectu= re and OS, at a
> > >> >> particular optimization level. Change any of th= ose things, and
> > >> >> you can change the behavior.
> > >> >
> > >> >
> > >> > In fact, the "it works kind of as you expected= " is the worst
> > >> > kind of UB in my mind. UB that causes a crash, stop= s or other
> > >> > "directly obvious that this is wrong" are= MUCH easier to debug.
> > >> >
> > >> > So make this particular kind of UB explicit by cras= hing or
> > >> > stopping would be a good thing. Making it explicit = by
> > >> > "returning kind of nicely, but not correct ret= urn value" is
> > >> > about the worst possible result.
> > >>
> > >> At -O0 clang emits a trap instruction, making it more ex= plicit as
> > >> you suggest. At higher optimization levels it just falls=
> > >> through/off.
> > >>
> > >> >
> > >> > --
> > >> > Mats
> > >> >>
> > >> >>
> > >> >> -- Marshall
> > >> >>
> > >> >>
> > >> >> _______________________________________________=
> > >> >> cfe-dev mailing list
> > >> >> cfe-dev@cs.uiuc.edu
> > >> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > >> >>
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > cfe-dev mailing list
> > >> > cfe-dev@cs.uiuc.edu
> > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > >> >
> > >>
> > >> _______________________________________________
> > >> cfe-dev mailing list
> > >> cfe-dev@cs.uiuc.edu
> > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev@= cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@cs.ui= uc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev=

=C2=A0

=C2=A0


-- IMPORTANT NOTICE: The co= ntents of this email and any attachments are confidential and may also be p= rivileged. If you are not the intended recipient, please notify the sender = immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782

--001a11c2329268431f051d355b55-- --===============2541425552073832700== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2ZlLWNvbW1p dHMgbWFpbGluZyBsaXN0CmNmZS1jb21taXRzQGxpc3RzLmxsdm0ub3JnCmh0dHA6Ly9saXN0cy5s bHZtLm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vY2ZlLWNvbW1pdHMK --===============2541425552073832700==--