I've invited you to fill out the following form:
Re: Order
To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSdvTz-uNrwzYEDRle3NKO8L0HG7h5hasmZNnR2EPGRKB8tXPQ/viewform?vc=0&c=0&w=1&flr=0&usp=mail_form_link
I've invited you to fill out a form:
Google
We thank you for spreading malware via Office VBA macros.
Sincerly,
Le 24/02/2016 12:07, Abigail Jones a écrit :
Please see attached
On 29 April 2014 16:25, Yaron Dayagi wrote:
> Hello,
> In gcc 4.4.6 we had no problem with the order of initialization.
> In gcc 4.7.2 we do have a problem.
> A CPP file defined GlobalObj_1 (declared extern in the H file):
> CMyClass GlobalObj_1.
> Another CPP file declared GlobalObj_2 (also declar
On Tue, Aug 04, 2009 at 05:58:05PM -0700, Vincent Lefevre wrote:
> On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> > But AFAIK neither Posix nor the C89 standard nor the C99 standard
> > say anything about -D and -U flags. It's the Single UNIX specification
> > that is the issue, and it refers to
On Wed, 5 Aug 2009, Dave Korn wrote:
> to integrate this behaviour into the driver. Perhaps we could even do the old
> behave-differently-according-to-argv[0] trick, although I'm not sure if that
> isn't slightly discouraged these days.
The proper thing is to build a separate driver binary (opti
Vincent Lefevre wrote:
> On 2009-08-05 10:07:49 +0100, Dave Korn wrote:
>> GCC does not install an executable called "c99". Or one called
>> "c89". So what any standard requires of them is irrelevant to us,
>> except that we would want to make it possible to support that mode
>> of operation. And
On 2009-08-05 10:07:49 +0100, Dave Korn wrote:
> GCC does not install an executable called "c99". Or one called
> "c89". So what any standard requires of them is irrelevant to us,
> except that we would want to make it possible to support that mode
> of operation. And we do; with our predictable
Vincent Lefevre wrote:
> On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
>> But AFAIK neither Posix nor the C89 standard nor the C99 standard
>> say anything about -D and -U flags. It's the Single UNIX specification
>> that is the issue, and it refers to a command that is spelled "c89",
>> or (in la
On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> But AFAIK neither Posix nor the C89 standard nor the C99 standard
> say anything about -D and -U flags. It's the Single UNIX specification
> that is the issue, and it refers to a command that is spelled "c89",
> or (in later versions) "c99", not "gcc
On Tue, Aug 04, 2009 at 11:42:51AM -0700, Ross Smith wrote:
>
> On 2009-08-05, at 04:03, Joe Buck wrote:
> >
> > Another alternative would be an extra flag that would turn on
> > conformance
> > to the spec.
>
> Traditionally spelled -posixly-correct in other GNU software. This would
> presumably
On 2009-08-05, at 04:03, Joe Buck wrote:
Another alternative would be an extra flag that would turn on
conformance
to the spec.
Traditionally spelled -posixly-correct in other GNU software. This would
presumably also affect other options, such as making the default -
std=c99
instead of g
On Tue, Aug 04, 2009 at 08:03:56AM -0700, Tom Tromey wrote:
> > "Erwin" == Unruh, Erwin writes:
>
> Erwin> In current gcc the order of options -D and -U is significant. The
> Erwin> Single Unix(r) Specification explicitly specifies that the order
> Erwin> should not matter for the c89 command
> "Erwin" == Unruh, Erwin writes:
Erwin> In current gcc the order of options -D and -U is significant. The
Erwin> Single Unix(r) Specification explicitly specifies that the order
Erwin> should not matter for the c89 command. It reads (cited from
Erwin> version 2, which is ten years old):
Erw
On 2009-08-04 08:23:52 +0200, Paolo Bonzini wrote:
> User-specified CFLAGS are always passed last in the Makefiles (at
> least for Automake, but it is a good practice in general) so that
> the user can override options like -D, -U, -O, -g, -f, -m.
>
> The specified behavior would make this impossi
On 2009-08-03 15:52:37 +0200, Unruh, Erwin wrote:
> In current gcc the order of options -D and -U is significant. The
> Single Unix(r) Specification explicitly specifies that the order
> should not matter for the c89 command. It reads (cited from
> version 2, which is ten years old):
[...]
FYI, I
On 08/03/2009 03:52 PM, Unruh, Erwin wrote:
2) Is this a bug?
I think it's a bug in the specification.
User-specified CFLAGS are always passed last in the Makefiles (at least
for Automake, but it is a good practice in general) so that the user can
override options like -D, -U, -O, -g, -f, -m
Bryan James wrote:
Hello there,
Greetings from BJS New Zealand Pty Ltd. My name is Bryan James the CEO of the company. i will like to place order on some products in your company,but i would like to know if you ship to Christchurch, New Zealand and also do you accept Visa or Master card as meth
Well, you are right. The code looks good and works also. But I have some
kind of a reference implementation which is based on GCC 2.7.2.3. In
this version the local variables are allocated the other way around, the
way in which I expected. Obviously, the order of allocation has changed
till now (4.
Robert Dewar writes:
> Markus Franke wrote:
>
> > Please let me know whether I missunderstood something completely. If
> > this behaviour is correct what can I do to change it to the other way
> > around. Which macro variable do I have to change?
>
> There is no legitimate reason to care a
Markus Franke wrote:
Please let me know whether I missunderstood something completely. If
this behaviour is correct what can I do to change it to the other way
around. Which macro variable do I have to change?
There is no legitimate reason to care about the order of variables
in the local stac
20 matches
Mail list logo
