Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167940
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Date | 2022-10-02 13:38 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <thbt7p$1mgus$1@dont-email.me> (permalink) |
| References | (15 earlier) <20220928162825.705@kylheku.com> <th3pik$kpdd$1@dont-email.me> <20220929104930.67@kylheku.com> <th4p4g$nns9$1@dont-email.me> <20220930100037.560@kylheku.com> |
Cross-posted to 2 groups.
On 30/09/2022 19:20, Kaz Kylheku wrote:
> [ Apologies for having had diverted this subthread to comp.lang.c ]
> On 2022-09-29, David Brown <david.brown@hesbynett.no> wrote:
>> On 29/09/2022 19:58, Kaz Kylheku wrote:
>>> On 2022-09-29, David Brown <david.brown@hesbynett.no> wrote:
>>>> On 29/09/2022 01:38, Kaz Kylheku wrote:
>>>>> On 2022-09-28, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>>> On 9/28/22 04:26, Kaz Kylheku wrote:
>>>>>>> ["Followup-To:" header set to comp.lang.c.]
>>>>>>> On 2022-09-28, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>>>>> On 9/27/22 20:03, Kaz Kylheku wrote:
>>>>>>>>> On 2022-09-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>>>>> ...
>>>>>>>>>> temp1 = complex_expr;
>>>>>>>>>> temp2 = another_complex_expr;
>>>>>>>>>> temp3 = yet_another_complex_expr;
>>>>>>>>>>
>>>>>>>>>> make_object(temp1, temp2, temp3).
>>>>>>>>>
>>>>>>>>> That transformation is the job of the compiler, though.
>>>>>>>>>
>>>>>>>>> It's not practical to do this even in small programs, let alone
>>>>>>>>> ones in which there are millions of function call expressions.
>>>>>>>>
>>>>>>>> You only do it when the order actually matters, not automatically for
>>>>>>>> all function calls.
>>>>>>>
>>>>>>> OK; I still need the compiler to tell me where those places are;
>>>>>>
>>>>>> You've got the communications direction wrong. Writing code that way is
>>>>>> how you tell the compiler that the order matters. Writing it as a simple
>>>>>> function call without explicit temporaries is how you tell the compiler
>>>>>> that you think the order doesn't matter. A good compiler should inform
>>>>>> you if realizes that the assumption is incorrect.
>>>>>
>>>>> Of course, I can tell which is the case by inspection. Problem is,
>>>>> suppose I didn't write the code myself and there are tens of thousands
>>>>> of function calls in it. I can't inspect them all, and so that's why
>>>>> I would need the compiler to tell me where the places are.
>>>>>
>>>>> I suspect that practically achievable diagnostics in this area will
>>>>> yield lots of false positives.
>>>>>
>>>>> For instance, the order probably doesn't matter in code like this:
>>>>>
>>>>> debug_pf("device %s: status %x\n", dev_name(d), dev_status(d));
>>>>>
>>>>> yet, this code potentially has behavior dependent on the order
>>>>> of the function calls. The functions are external, defined in another
>>>>> translation unit; the compiler has no idea whether they mutate the d
>>>>> object. A diagnostic feature warning about potential side effects in
>>>>> function arguments would have to flag this.
>>>>>
>>>>> Really, the best solution is not to have this class of bug at all
>>>>> by a fixed order of evaluation.
>>>>>
>>>>
>>>> The logical extension of this is saying that when some programmers don't
>>>> understand the language properly, or make unwarranted assumptions, or
>>>> write poor code, you want the language to define away the bugs.
>>>
>>> Well, it does a fair good job of that already, right?. For instance, it
>>> tells you if you're passing a "foo *" pointer to a function that expects
>>> "bar *", or accessing a nonexistent member in a structure instead of just
>>> blindly fetching from that offset, or that you're passing too few or
>>> many arguments and so on.
>>>
>>> Every time you get a diagnostic in any such an area, that's a situation
>>> in which you didn't write correct code, and which would have either not
>>> been caught at all, or possibly very late, like years later in the field
>>> somewhere.
>>>
>>>> Programmers have to take responsibility for
>>>> writing correct code.
>>>
>>> When was the last time you took responsibility that a C function
>>> call correctly pops all the arguments off the stack which it pushed?
>>>
>
>> Every time I use a function? I take responsibility for picking a good
>> compiler that I am confident I can rely on, for testing my code, and for
>> writing code correctly in the first place - that's a programmer's job.
>> And when I accidentally put bugs in the code, that is my responsibility too.
>>
>>> One way that programmers, as a group, take responsibility for writing
>>> correct code is by by developing tools, and using them.
>>
>> Sure. In particular, they are responsible for learning the tools and
>> using them properly to maximal effect for the task in hand.
>
> This is a basic principle in the field and pretty much any other
> professional field; as such, it doesn't really inform.
>
> It's true whether you're toggling switches on a panel to produce
> a binary program directly in memory, or whether you're using OCaml
> or Prolog.
>
Yes. And it is not uncommon in many fields to blame the tools for
mistakes of the users. Sometimes such blame is fair, of course - but
usually not.
> Yet it is empirically valid that those diverse alternatives
> don't have the same safety, and we evolve things accordingly.
>
> Speaking of returning the cross-posting to comp.lang.c++, that language
> as of C++17 has chosen to define some evaluation orders.
>
Yes. Primarily it is for the case of "cout << a() << b();". This is a
situation where specific ordering really does help the programmer.
Language changes are sometimes a good idea, but there are almost always
trade-offs to consider. Things that one person sees as clearly a good
idea, will sound crazy and be a pain for someone else.
> The evaluation order of function arguments is not yet defined, but
> now there is a sequence point between the argument expressions.
>
> That is obviouslly super important, because now the unspecified behavior
> stays unspecified when there are side effects like:
>
> f(i++, i++);
>
> it doesn't help with the situation
>
> f(g(), h())
>
> because those calls are sequenced. However, it helps in the
> argument space: with just the classic sequencing of function calls not
> being interleaved, this is still undefined:
>
> f(g(i++), h(i++))
>
There is always going to be things that are undefined or unspecified.
There are always going to be ways to write things that make no sense, or
at least no well-defined and consistent sense. A language can aim to
reduce these possibilities, but it comes at a big cost. There are three
disadvantages, as I see them. One is that it tells programmers that
even though a piece of code is unclear to humans, it is valid code - and
then some people write code like "f(i++, i++)" that is hard for others
to comprehend. Another is it reduces the ability of compilers and tools
to help you write good, clear code (compilers can warn on "f(i++, i++)"
when it is not defined behaviour). And it reduces optimisation
possibilities for perfectly good code.
> whereas by my understanding C++17 leaves it unspecified in which order g
> and h will be called, and which one will have receive the original value
> of i. But, I think, we can infer that that function which is called
> first receives the original value of i, and i is reliably incremented
> twice. Baby steps in the right direction, in any case.
>
No - that is the /wrong/ message to take from the C++17 changes. It is
not "baby steps in the right direction" - it is a case of minimal
changes needed to give defined behaviour to common incorrect code that
has been used in practice for years. The key motivation is that a lot
of code has been written that assumes "cout << f() << g();" calls "f()"
first, then "g()".
It is not a step in a direction towards more general changes, because
that would mean making at least some existing correct code less efficient.
> I don't understand the rationale for sequencing A before B in A << B
> (what is so special about shifting); there must be some motivating
> example where you have a side effect in A that B depends on. What I'm
> likely missing that it's probably not the built-in arithmetic << that is
> of concern, but overloads.
>
Correct.
>> But you don't get to pick different rules that you'd prefer to have for
>> the language, and then blame the language when your code doesn't work.
>> It is not the language that is at fault if someone writes code that
>> relies on execution order that is left unspecified by the standards -
>> it's the programmers' fault.
>
> It's not a game of blame, but of reducing the unfortunate situations in
> which someone has a reason to look for something to blame.
>
Fair enough.
> I can't look at a large body of code (that I perhaps didn't write: so no
> responsibility of mine) and easily know whether there is a problem due
> to eval order.
Analysing the correctness of other people's code is never an easy job!
However, I don't think a specified evaluation order would help. If you
see "f(g(), h());" in the code, you are concerned that the programmer
might be assuming that "g()" is evaluated before "h()". But if you know
the programmer was good at his/her job, you will know that he/she would
have used temporaries and run g() and h() before f() if the order
mattered. So you know the code is correct, and the order does not matter.
However, if the order were specified by the language, then you still
know the code is correct but you don't know if the order of the call
matters (and the programmer relied on the evaluation order), or if it
does not matter.
The lack of specification in the language gives you /more/ information,
not less.
And if you can't rely on the original programmer's competence, you can't
rely on anything in the code without more detailed checking anyway.
Sometimes tighter specification for things like evaluation order gives
you benefits, but not always - it can just as well be a disadvantage.
> If I'm charged with the responsibility of finding out,
> I could just give a quick answer "almost certainly no, modulo compiler
> bugs" if eval order is defined by the language, without any effort. (On
> the other hand, that leaves money on the table, doesn't it! Now I have
> to find alternative ways to get paid for the saved hours.)
>
> Scrambled eval orders in a language in which side effects are the
> principal means of getting anything done is a poor technical situation.
>
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
“Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-21 14:04 -0500
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-21 12:28 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:16 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 09:45 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Single Stage to Orbit <alex.buell@munted.eu> - 2022-09-22 09:42 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 11:16 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:48 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 23:12 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 01:40 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:07 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:42 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 15:24 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? The Real Non Homosexual <cdalten@gmail.com> - 2022-10-10 19:12 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 09:41 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:46 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 16:15 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 20:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 20:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 22:56 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-22 23:15 +0100
g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 13:44 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Bart <bc@freeuk.com> - 2022-09-23 13:53 +0100
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:31 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:53 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 16:21 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-24 17:05 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] red floyd <no.spam.here@its.invalid> - 2022-09-24 12:33 -0700
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Muttley@dastardlyhq.com - 2022-09-25 08:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 00:08 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-23 12:13 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 10:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:58 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:03 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? red floyd <no.spam.here@its.invalid> - 2022-09-23 14:43 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-23 12:35 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-23 12:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:09 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 13:25 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:13 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-26 10:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-27 09:56 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-27 10:50 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 01:57 -0400
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-09-22 14:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Ben Collver <bencollver@tilde.pink> - 2022-09-22 15:19 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 15:23 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-22 12:13 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Andrea Biscuola <a@abiscuola.com> - 2022-09-22 20:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” scott@slp53.sl.home (Scott Lurndal) - 2022-09-22 19:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Richard Harnden <richard.nospam@gmail.com> - 2022-09-22 17:36 +0100
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-23 03:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:50 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:37 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:19 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 13:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 14:31 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-26 16:05 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:36 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:21 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 13:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-27 16:53 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 10:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 18:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-27 22:32 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 23:52 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 19:57 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:03 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 01:30 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 08:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 15:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 13:15 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 23:38 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:46 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-29 17:58 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 20:45 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 17:20 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 20:59 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-01 11:40 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 13:38 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-02 13:00 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 16:20 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-30 09:17 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 16:39 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-01 12:47 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 09:40 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 07:56 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 15:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:21 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 16:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 16:56 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 18:48 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 19:33 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-26 09:04 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:27 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-27 12:41 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-27 15:22 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:13 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 16:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 08:11 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:10 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 17:30 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 11:00 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-28 13:33 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-09-25 19:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-26 04:53 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? BGB <cr88192@gmail.com> - 2022-10-01 16:07 -0500
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Opus <ifonly@youknew.org> - 2022-09-23 18:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:08 -0400
csiph-web