Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110548 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2017-05-24 08:16 -0700 |
| Last post | 2017-06-03 11:29 +0000 |
| Articles | 20 on this page of 82 — 20 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:16 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-24 10:43 -0700
Re: C Macros Badly Defined? Ike Naar <ike@iceland.freeshell.org> - 2017-05-24 19:06 +0000
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-27 06:10 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 12:02 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-27 13:42 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 15:48 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-28 14:40 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:33 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:17 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-29 16:26 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:13 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 09:57 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 19:12 +0200
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 14:55 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 15:39 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 16:03 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 16:50 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 17:12 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:30 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:36 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:08 -0700
Re: C Macros Badly Defined? scott@slp53.sl.home (Scott Lurndal) - 2017-05-31 19:16 +0000
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:35 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:06 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 10:33 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 12:00 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 15:35 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 17:26 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 20:48 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 12:43 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:50 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:36 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 11:44 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-03 09:19 -0700
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 16:22 +0000
Re: Standards in various formats Noob <root@127.0.0.1> - 2017-06-01 13:24 +0200
Re: C Macros Badly Defined? jadill33@gmail.com - 2017-05-31 13:02 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 22:06 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 12:51 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:21 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 17:16 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 17:24 +0200
Re: C Macros Badly Defined? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-31 22:18 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:09 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 17:32 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:50 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 18:01 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 00:33 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 22:36 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 06:08 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:08 -0400
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 01:30 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 11:38 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 03:13 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 12:25 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 04:48 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 14:27 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 05:55 -0700
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:11 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 17:40 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 08:32 +1200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 23:14 +0200
Re: C Macros Badly Defined? jameskuyper@verizon.net - 2017-06-01 14:41 -0700
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 09:48 +1200
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 00:56 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:12 +1200
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:54 +0000
Re: C Macros Badly Defined? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 05:10 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-04 14:32 +0200
Re: C Macros Badly Defined? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-01 21:44 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:51 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 21:38 +0000
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:10 +1200
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 23:34 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:48 +0000
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-01 08:56 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 14:11 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-02 10:02 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:45 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:11 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:29 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-31 06:21 -0700 |
| Message-ID | <1932cc0c-4bac-4884-9062-687de6399c58@googlegroups.com> |
| In reply to | #110985 |
On Wednesday, May 31, 2017 at 5:51:51 AM UTC-5, David Brown wrote:
> On 31/05/17 01:50, supercat wrote:
> > On Tuesday, May 30, 2017 at 6:03:48 PM UTC-5, Keith Thompson wrote:
> >> The term, as you know, is "undefined behavior". Hiding it behind extra
> >> wording is not helpful.
> >
> > Many useful tasks cannot be performed efficiently, or at all, without using
> > behaviors which are defined by some implementations but are not mandated by
> > the Standard. What terminology would you use to distinguish those behaviors
> > from behaviors which are not defined by anything whatsoever?
>
> Implementation-defined behaviour, or target-specific behaviour. The C
> standards specifically refer to some behaviours as "implementation
> defined", which means the implementation must define (and document) the
> behaviour. Implementations can freely add other defined behaviour (as
> long as it does not contradict standards-defined behaviour).
The phrase "Implementation-Defined" behavior, as used by the Standard, refers
to situations where ALL implementations are REQUIRED to document something
about the behavior. Platform-defined behavior may be good.
> > The fact that programs which invoke upon not-defined-by-anything behaviors
> > are broken does not imply that programs which invoke not-defined-by-the-
> > Standard-but-instead-defined-by-other-things behaviors are broken. Some
> > compiler writers seem unable to distinguish those categories, however.
>
> A compiler will follow "defined by the standards" /and/ "defined by the
> implementation" behaviours. This second part includes extensions,
> implementation-defined behaviour, and any cases where the implementation
> specifically provides definitions for things that the standards leave
> undefined.
And if all general-purpose implementations for a platform have processed a
certain behavior a certain way, quality general-purpose implementations should
continue to do likewise unless they document a compelling reason to do
otherwise.
> A compiler has /no/ obligation to follow behaviour that is defined
> elsewhere. That includes behaviour that may seem "natural" for the
> target platform, behaviour that other compilers support, behaviour that
> existed in older C versions or standards, or behaviour that is in the
> imagination of the user.
True, but a C implementation whose behavior deviates from those of existing
general-purpose compilers for similar platforms should not call itself a
quality general-purpose compiler, since general-purpose compilers should be
suitable for processing code written for pre-existing general-purpose compilers
for similar platforms.
> You can imagine that every compiler is written using only the C
> standards (whichever versions they support) and their own reference
> manual as the requirements. /Nothing/ else matters - no other behaviour
> is defined.
Compiler writers used to recognize that an ability to run code designed for
other compilers was a useful feature, and would thus take into account the
behavior of any compilers they might be competing with. No law requires
that any compiler be compatible with non-mandated features of any other, but
a language where compiler writers try to do so will be more useful than one
where they don't.
> So where are the definitions for your
> "not-defined-by-the-Standard-but-instead-defined-by-other-things"
> behaviours? And why do you think that compiler writers need to obey
> definitions from unrelated places?
Among other things, in the corpus of programs that will work just fine on a
wide range of older compilers, but get tripped up by modern ones. If one of
the purposes of a compiler is to be suitable for use with a corpus of existing
code, then the corpus of code will, essentially by definition, establish the
what would be needed to make a compiler suitable for the purpose of using it.
I would further suggest that on most platforms a compiler that was tasked
with generating code in "mindless-translator" fashion would in many cases
not be able to avoid exposing useful behaviors which are documented by the
environment without having to generate extra code for that purpose. In such
cases, a compiler which claims to be suitable for low-level programming on
that platform should expose such behaviors likewise. Doing so may mean that
the compiler can only achieve 50-90% of the optimizations that would otherwise
be possible, but a compiler that can process a large corpus of code and
achieve 50-90% of the possible optimizations may be much more useful for many
purposes than one which can achieve more optimizations on a few programs but
can't be trusted to yield more than 0% on the rest.
> >> The C standard defines clearly and unambiguously what it means by
> >> "shall". The meaning depends on the context; it means one thing in a
> >> constraint, and something else outside a constraint.
> >
> > Most standards specify what conforming entities have to "do", and are quite
> > specific about what entities are responsible for ensuring what. The Standard
> > sometimes talks about obligations of programs or implementations, but
> > sometimes uses "shall be" to impose obligations upon grammatical constructs.
>
> Read chapter 4 of the standards. It tells you what "shall" and "shall
> not" mean.
>
> Incidentally, you might want to pay particular attention to paragraph 2:
>
> > If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtime-
> > constraint is violated, the behavior is undefined. Undefined behavior is otherwise
> > indicated in this International Standard by the words ‘‘undefined behavior’’ or by the
> > omission of any explicit definition of behavior. There is no difference in emphasis among
> > these three; they all describe ‘‘behavior that is undefined’’.
>
> Note the final sentence here. This should, I hope, put an end to your
> endless claims about what you think the standards authors actually meant.
Undefined by the standard, which is not the same as behavior which would
not be necessary to make a compiler suitable for purposes like low-level
programming.
> > Indeed, but some programmers seem to think that permission to behave
> > nonsensically should be viewed, in and of itself, as a compelling reason
> > to behave nonsensically.
>
> Name /one/ such programmer. Give even /one/ example where you can
> clearly demonstrate that the reason a compiler behaves in a
> "nonsensical" manner is purely because it is allowed to behave
> "nonsensically". Of course, you can't demonstrate this from a single
> program - you have to show that there are /no/ correct programs that
> don't benefit in some way from the compiler feature.
The whole concept behind UB-based dead-branch elimination is that all forms
of UB are equivalent. As I've demonstrated, gcc will use the fact that an
overflow may occur while evaluating two "unsigned short" values as a basis
for making inferences about those values, even if the result is truncated
mod 65536. Can you suggest any *other* basis for gcc's behavior?
> Remember, of course, that when there is no definition of the correct
> behaviour, it does not make sense to say that something is
> "nonsensically", no matter what it does.
There are a number of actions for which some compilers offer behavioral
guarantees and some don't, but for which a single behavior would satisfy the
behavioral guarantees of all general-purpose compilers for similar platforms.
Has any general-purpose (non-sanitizing) compiler for a two's-complement
silent-wraparound hardware *ever* defined a behavior for
(ushort1*ushort2) & 65535u
which was not consistent with performing an arithetical computation and
mod-65536-reducing the result? If processing such code in such fashion
would make a compiler compatible with a wider range of code than would
any other treatment, and would not impede performance, I'd say that such
behavior would be desirable in a compiler that is intended to be suitable
with the maximum corpus of existing code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-31 17:16 +0200 |
| Message-ID | <ogmmhn$q3a$1@dont-email.me> |
| In reply to | #110991 |
On 31/05/17 15:21, supercat@casperkitty.com wrote: > On Wednesday, May 31, 2017 at 5:51:51 AM UTC-5, David Brown wrote: >> On 31/05/17 01:50, supercat wrote: >>> On Tuesday, May 30, 2017 at 6:03:48 PM UTC-5, Keith Thompson wrote: >>>> The term, as you know, is "undefined behavior". Hiding it behind extra >>>> wording is not helpful. >>> >>> Many useful tasks cannot be performed efficiently, or at all, without using >>> behaviors which are defined by some implementations but are not mandated by >>> the Standard. What terminology would you use to distinguish those behaviors >>> from behaviors which are not defined by anything whatsoever? >> >> Implementation-defined behaviour, or target-specific behaviour. The C >> standards specifically refer to some behaviours as "implementation >> defined", which means the implementation must define (and document) the >> behaviour. Implementations can freely add other defined behaviour (as >> long as it does not contradict standards-defined behaviour). > > The phrase "Implementation-Defined" behavior, as used by the Standard, refers > to situations where ALL implementations are REQUIRED to document something > about the behavior. Platform-defined behavior may be good. That seems a reasonable choice to me. But I'd wait for others such as Keith to express an opinion. > >>> The fact that programs which invoke upon not-defined-by-anything behaviors >>> are broken does not imply that programs which invoke not-defined-by-the- >>> Standard-but-instead-defined-by-other-things behaviors are broken. Some >>> compiler writers seem unable to distinguish those categories, however. >> >> A compiler will follow "defined by the standards" /and/ "defined by the >> implementation" behaviours. This second part includes extensions, >> implementation-defined behaviour, and any cases where the implementation >> specifically provides definitions for things that the standards leave >> undefined. > > And if all general-purpose implementations for a platform have processed a > certain behavior a certain way, quality general-purpose implementations should > continue to do likewise unless they document a compelling reason to do > otherwise. No. If all an implementation wants to give you behaviour that you can rely on, it should document it. Otherwise you are on your own - you /can/ write code, compile it, and see that it works as you expect, but you should not expect it to remain working if you change compiler flags, update to a new version, or make other changes. What you are suggesting would be a recipe for stagnation - compilers could not change and improve because they would have to try to emulate the unwritten and unspecified behaviour of other tools. It would also make users' life a lottery - how is the user supposed to know what the compiler writer sees as a "compelling reason" ? > >> A compiler has /no/ obligation to follow behaviour that is defined >> elsewhere. That includes behaviour that may seem "natural" for the >> target platform, behaviour that other compilers support, behaviour that >> existed in older C versions or standards, or behaviour that is in the >> imagination of the user. > > True, but a C implementation whose behavior deviates from those of existing > general-purpose compilers for similar platforms should not call itself a > quality general-purpose compiler, since general-purpose compilers should be > suitable for processing code written for pre-existing general-purpose compilers > for similar platforms. The trick here is very simple - write code that relies on standards-defined behaviour, and perhaps basic implementation-defined behaviour (such as the size of an "int") if that is helpful to your code and you don't need wide portability. Some target architectures have specified ABIs that compilers will stick to, giving you a nice selection of implementation-specific behaviour you can rely on across different tools. If you need something beyond that, your code is tied tightly to the implementation (possibly even the specific version and flags). That's fine too - C is designed to allow that kind of coding. Your mistake is in thinking that /other/ compilers somehow have an obligation to support /your/ non-portable code. > >> You can imagine that every compiler is written using only the C >> standards (whichever versions they support) and their own reference >> manual as the requirements. /Nothing/ else matters - no other behaviour >> is defined. > > Compiler writers used to recognize that an ability to run code designed for > other compilers was a useful feature, and would thus take into account the > behavior of any compilers they might be competing with. Compiler writers will often support extensions that exist on other compilers. They might take inspiration from others in how they specify implementation-defined behaviour. But I have never heard of a compiler trying to emulate another compiler's treatment of undefined behaviour. Can you give real-life examples? Even if there is, I don't see that as being a useful feature, except perhaps to propagate bugs and poor coding. And since it might hinder new features or optimisations, it could be a /bad/ thing. If I write code that relies on unwritten details of an implementation (and that sometimes happens), then the code is specific to the compiler and flags - I would not even bother trying to compile it with another tool without extensive testing, checking and qualification. It is a different thing entirely if the compiler /documents/ the behaviour, perhaps using a compiler switch. For example, it would be a bad idea for gcc to emulate old compiler's behaviour of wrapping signed integer overflows, because it hinders optimisations. But it is a fine idea to provide a documented "-fwrapv" switch which enables such wrapping behaviour. /That/ is how you deal with compatibility with old code that relies on specific undefined behaviour. > No law requires > that any compiler be compatible with non-mandated features of any other, but > a language where compiler writers try to do so will be more useful than one > where they don't. > >> So where are the definitions for your >> "not-defined-by-the-Standard-but-instead-defined-by-other-things" >> behaviours? And why do you think that compiler writers need to obey >> definitions from unrelated places? > > Among other things, in the corpus of programs that will work just fine on a > wide range of older compilers, but get tripped up by modern ones. If one of > the purposes of a compiler is to be suitable for use with a corpus of existing > code, then the corpus of code will, essentially by definition, establish the > what would be needed to make a compiler suitable for the purpose of using it. The main target for a compiler is correctly written code. If it does not work well with broken code that happened to work on other compilers, that's fine. /I/ don't want a compiler that is hobbled so that it works with /your/ old broken code. I want a compiler that does the best job for /correct/ code. I also want it to be helpful in telling me about broken code - if I make a mistake, I would prefer to be informed about it, rather than for the compiler to try to guess what I meant based on what somebody might have meant in code long ago. People with old code that is badly written should stick to old compilers that they have tested with that code. Since the behaviour of their code is by definition undefined, there is no way for a new compiler to be sure it supports these unwritten rules. Only in some specific cases, such as wrapping behaviour for integer overflow, is it even possible for a new compiler to support the old broken code. > > I would further suggest that on most platforms a compiler that was tasked > with generating code in "mindless-translator" fashion would in many cases > not be able to avoid exposing useful behaviors which are documented by the > environment without having to generate extra code for that purpose. If they are documented by the tools, that's fine. If by "documented by the environment", you mean "behaviour of certain instructions on the cpu", then that is not C - C is not an assembler. If your code relies on such behaviour in old tools, then stick to the old tools - your code is only suitable for use on the specific implementations you have tested it with. I have worked with code written for "mindless translator" compilers. And when I have moved such code over to better compilers, I have gone through all the code carefully, "porting" it over to standard C (or implementation-dependent C, as necessary). I don't expect my new tools to work like mindless translators just because the old ones did. The alternative, which I also do, is simply to continue to use the mindless translator tools for that code. When I have to dig out and modify 20 year old code, I use the same 20 year old compiler as I did originally. > In such > cases, a compiler which claims to be suitable for low-level programming on > that platform should expose such behaviors likewise. Doing so may mean that > the compiler can only achieve 50-90% of the optimizations that would otherwise > be possible, but a compiler that can process a large corpus of code and > achieve 50-90% of the possible optimizations may be much more useful for many > purposes than one which can achieve more optimizations on a few programs but > can't be trusted to yield more than 0% on the rest. I think perhaps I put a lot more emphasis on writing good code than you do. I just don't see it as a problem. For the types of targets where you typically need to write "special" code that relies on weird behaviour in order to get something of acceptable efficiency, you rarely want to run that code on anything else anyway. > >>>> The C standard defines clearly and unambiguously what it means by >>>> "shall". The meaning depends on the context; it means one thing in a >>>> constraint, and something else outside a constraint. >>> >>> Most standards specify what conforming entities have to "do", and are quite >>> specific about what entities are responsible for ensuring what. The Standard >>> sometimes talks about obligations of programs or implementations, but >>> sometimes uses "shall be" to impose obligations upon grammatical constructs. >> >> Read chapter 4 of the standards. It tells you what "shall" and "shall >> not" mean. >> >> Incidentally, you might want to pay particular attention to paragraph 2: >> >>> If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtime- >>> constraint is violated, the behavior is undefined. Undefined behavior is otherwise >>> indicated in this International Standard by the words ‘‘undefined behavior’’ or by the >>> omission of any explicit definition of behavior. There is no difference in emphasis among >>> these three; they all describe ‘‘behavior that is undefined’’. >> >> Note the final sentence here. This should, I hope, put an end to your >> endless claims about what you think the standards authors actually meant. > > Undefined by the standard, which is not the same as behavior which would > not be necessary to make a compiler suitable for purposes like low-level > programming. As I have said many times, low-level programming is what I do for a living - on a wide range of targets, with a wide range of tools. In almost all cases, you can do it fine with standard defined behaviour, possibly with some implementation defined behaviour. Occasionally you need "platform defined behaviour" (the term from earlier in this post). Very occasionally, you need something that is not really defined at all, and known to work by inspection of the generated code or by testing. What you /don't/ need, ever, is guesses about what behaviour you think should have been defined, or would have been defined, or that somebody meant to define. > >>> Indeed, but some programmers seem to think that permission to behave >>> nonsensically should be viewed, in and of itself, as a compelling reason >>> to behave nonsensically. >> >> Name /one/ such programmer. Give even /one/ example where you can >> clearly demonstrate that the reason a compiler behaves in a >> "nonsensical" manner is purely because it is allowed to behave >> "nonsensically". Of course, you can't demonstrate this from a single >> program - you have to show that there are /no/ correct programs that >> don't benefit in some way from the compiler feature. > > The whole concept behind UB-based dead-branch elimination is that all forms > of UB are equivalent. As I've demonstrated, gcc will use the fact that an > overflow may occur while evaluating two "unsigned short" values as a basis > for making inferences about those values, even if the result is truncated > mod 65536. Can you suggest any *other* basis for gcc's behavior? gcc's behaviour is to follow the rules of C about integer promotion. There was a time in C's history when some tools used "value preserving promotion" while others used "signedness preserving promotion". After due consideration and debate, it was decided to use "value preserving promotion". Whether you like that or not (personally, I would be happier with /no/ promotion to int), that's the rules of C - and consistency is vital here. gcc follows these rules, and the implication of them. There are a few situations where the results can then seem strange. But you are basically accusing the gcc authors of specifically looking at code like your beloved uint16_t multiplication, and planning exciting ways to confuse programmers by generating "nonsense" code just to prove that /they/ have read the C standards. In reality, it is nothing but a side-effect of optimisation passes that are used to generate slightly more efficient object code from correct source code. Incidentally, how have the gcc authors responded to your bug report on this? What about when you asked for improved warnings when such dead code was eliminated? I presume that since you have told us in c.l.c. about this a few hundred times over the past few years, you have asked the gcc developers about it. Oh, and of course gcc already provides options that let you get the behaviour you presumably want here, even though there is no written specification for it. gcc has a wide range of flags to control optimisation - you can figure out the details yourself, or simply disable optimisation (which is, incidentally, the default - you have to /ask/ gcc to do the dead branch optimisation). > >> Remember, of course, that when there is no definition of the correct >> behaviour, it does not make sense to say that something is >> "nonsensically", no matter what it does. > > There are a number of actions for which some compilers offer behavioral > guarantees and some don't, but for which a single behavior would satisfy the > behavioral guarantees of all general-purpose compilers for similar platforms. > Has any general-purpose (non-sanitizing) compiler for a two's-complement > silent-wraparound hardware *ever* defined a behavior for > > (ushort1*ushort2) & 65535u > > which was not consistent with performing an arithetical computation and > mod-65536-reducing the result? (I assume you meant to add a requirement of "int" being longer than "short" to your list.) That is not the question you should be asking. The question is whether any compiler has ever defined a behaviour for such code? The answer, to my knowledge, is no. It doesn't matter than none have defined behaviour that is inconsistent with your expectations - none have defined it in a way that /is/ consistent with your expectations. Some might have happened to generate code that you like - equally, some generate code that you /don't/ like. /None/ specify what they should generate. (Feel free to provide references to compiler manuals if you have examples that prove me wrong here.) > If processing such code in such fashion > would make a compiler compatible with a wider range of code than would > any other treatment, and would not impede performance, I'd say that such > behavior would be desirable in a compiler that is intended to be suitable > with the maximum corpus of existing code. > I know you'd say that - you have done so many, many times. Your logic is still invalid, as are your premises.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-31 17:24 +0200 |
| Message-ID | <20170531172449.023885203d6c2d5e163c156f@gmail.com> |
| In reply to | #111003 |
On Wed, 31 May 2017 17:16:24 +0200 David Brown <david.brown@hesbynett.no> wrote: > That seems a reasonable choice to me. But I'd wait for others such as > Keith to express an opinion. I prefer undefined behaviours to emphasize the C standard POV since any C implementor manage the implementation in its own defined behaviour. In my view any specific behaviour wording is a non informative expression for the C implementation.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-05-31 22:18 +0200 |
| Message-ID | <m21sr4u6em.fsf@despina.home> |
| In reply to | #111008 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes: > On Wed, 31 May 2017 17:16:24 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> That seems a reasonable choice to me. But I'd wait for others such as >> Keith to express an opinion. > > I prefer undefined behaviours to emphasize the C standard POV since any C > implementor manage the implementation in its own defined behaviour. In my view > any specific behaviour wording is a non informative expression for the C > implementation. The problem is that it's very easy for programmers to hit undefined behavior (and without defined behavior that a warning shall be issued when undefined behavior is reached). Some other programming languages make it more difficult or more explicit to attain undefined behavior (eg. using UNSAFE modules, or some other language construct). The problem is that programmers with decades of experience programming in C still don't know they're filling their programs with undefined behavior. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-31 23:09 +0200 |
| Message-ID | <20170531230948.979a52f522803b800239cddc@gmail.com> |
| In reply to | #111051 |
On Wed, 31 May 2017 22:18:25 +0200 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > The problem is that programmers with decades of experience programming > in C still don't know they're filling their programs with undefined > behavior. If it works as expected why should they fear undefined behaviors? It give some room to manage the implementation according to the programming environment. The C programming language doesn't intend to force all implementations to conform to a specific programming environment (kernel, processor, etc).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-05-31 17:32 -0400 |
| Message-ID | <ognchn$98v$1@jstuckle.eternal-september.org> |
| In reply to | #111054 |
On 5/31/2017 5:09 PM, GOTHIER Nathan wrote: > On Wed, 31 May 2017 22:18:25 +0200 > "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > >> The problem is that programmers with decades of experience programming >> in C still don't know they're filling their programs with undefined >> behavior. > > If it works as expected why should they fear undefined behaviors? It give some > room to manage the implementation according to the programming environment. The > C programming language doesn't intend to force all implementations to conform > to a specific programming environment (kernel, processor, etc). > Because a change in compilers, different versions of the same compiler or even different compile options can change the behavior. That's what happens when the behavior is undefined. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-31 23:50 +0200 |
| Message-ID | <20170531235001.f8a7afb6280f4e5c54b2df1d@gmail.com> |
| In reply to | #111055 |
On Wed, 31 May 2017 17:32:06 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote: > Because a change in compilers, different versions of the same compiler > or even different compile options can change the behavior. That's what > happens when the behavior is undefined. If undefined behaviors are so bad why there isn't much feedback in bug reports about this? That's likely because undefined behaviors concern corner cases where a specifc behavior isn't required and is counterproductive for the implementation of C on a multitude of environments.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-05-31 18:01 -0400 |
| Message-ID | <ogne9i$ers$1@jstuckle.eternal-september.org> |
| In reply to | #111057 |
On 5/31/2017 5:50 PM, GOTHIER Nathan wrote: > On Wed, 31 May 2017 17:32:06 -0400 > Jerry Stuckle <jstucklex@attglobal.net> wrote: > >> Because a change in compilers, different versions of the same compiler >> or even different compile options can change the behavior. That's what >> happens when the behavior is undefined. > > If undefined behaviors are so bad why there isn't much feedback in bug > reports about this? That's likely because undefined behaviors concern corner > cases where a specifc behavior isn't required and is counterproductive for the > implementation of C on a multitude of environments. > Because they aren't bugs. They are by definition undefined behavior. Experienced programmers know how to stay away from them. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-06-01 00:33 +0200 |
| Message-ID | <20170601003357.0dfcbdce35f5422b5acdbede@gmail.com> |
| In reply to | #111058 |
On Wed, 31 May 2017 18:01:53 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote: > Because they aren't bugs. They are by definition undefined behavior. > Experienced programmers know how to stay away from them. I have to disagree. Some experienced C programmers know how to write good C programs but not all. If an experienced programmer avoid strcpy() on strings that he perfectly know don't overlap, it doesn't matter how long he wrote C code but he's definitely a bad C programmer.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-05-31 22:36 -0400 |
| Message-ID | <ognubo$pbp$1@jstuckle.eternal-september.org> |
| In reply to | #111061 |
On 5/31/2017 6:33 PM, GOTHIER Nathan wrote: > On Wed, 31 May 2017 18:01:53 -0400 > Jerry Stuckle <jstucklex@attglobal.net> wrote: > >> Because they aren't bugs. They are by definition undefined behavior. >> Experienced programmers know how to stay away from them. > > I have to disagree. Some experienced C programmers know how to write good C > programs but not all. If an experienced programmer avoid strcpy() on strings > that he perfectly know don't overlap, it doesn't matter how long he wrote C > code but he's definitely a bad C programmer. > Experienced C programmers know how to write good C programs. Idiots like you can't write good programs in ANY language. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-06-01 06:08 +0200 |
| Message-ID | <20170601060820.538feb7cf64cc93ead495495@gmail.com> |
| In reply to | #111066 |
On Wed, 31 May 2017 22:36:07 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote: > Experienced C programmers know how to write good C programs. Idiots > like you can't write good programs in ANY language. I'm very impressed by your undisputable argument... I'm afraid you wasted your entire life trying to write good C programs but never realized you failed.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-06-01 11:08 -0400 |
| Message-ID | <ogpadp$rcf$1@jstuckle.eternal-september.org> |
| In reply to | #111071 |
On 6/1/2017 12:08 AM, GOTHIER Nathan wrote: > On Wed, 31 May 2017 22:36:07 -0400 > Jerry Stuckle <jstucklex@attglobal.net> wrote: > >> Experienced C programmers know how to write good C programs. Idiots >> like you can't write good programs in ANY language. > > I'm very impressed by your undisputable argument... I'm afraid you wasted your > entire life trying to write good C programs but never realized you failed. > Sorry, Nathan, I write more good C programs in a month than you could write in your entire lifetime. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-06-01 01:30 -0700 |
| Message-ID | <c9909ce0-3f4d-40d4-9c93-7e10ec9b5819@googlegroups.com> |
| In reply to | #111061 |
On Wednesday, May 31, 2017 at 11:37:15 PM UTC+1, GOTHIER Nathan wrote: > On Wed, 31 May 2017 18:01:53 -0400 > Jerry Stuckle <jstucklex@attglobal.net> wrote: > > > Because they aren't bugs. They are by definition undefined behavior. > > Experienced programmers know how to stay away from them. > > I have to disagree. Some experienced C programmers know how to write good C > programs but not all. If an experienced programmer avoid strcpy() on strings > that he perfectly know don't overlap, it doesn't matter how long he wrote C > code but he's definitely a bad C programmer. > MIcrosoft pay their programmers plenty and I'd guess that a lot of people here wold work for Microsoft if they could. The terms are very attractive. Microsoft deprecated strcpy() because the problem with C is buffer overruns leading to security holes. It wasn't a perfect answer, but it's an answer of sorts.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-06-01 11:38 +0200 |
| Message-ID | <20170601113829.1d3189627e080d6825b024f6@gmail.com> |
| In reply to | #111076 |
On Thu, 1 Jun 2017 01:30:18 -0700 (PDT) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > Microsoft deprecated strcpy() because the problem with C is buffer overruns leading > to security holes. It wasn't a perfect answer, but it's an answer of sorts. Don't expect a bad programmer to recruit good ones when he doesn't know what's a good code. Removing the steering wheel won't prevent bad drivers to hit the wall.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-06-01 03:13 -0700 |
| Message-ID | <2fa4de36-2281-4702-a5ea-8e05f8a353bb@googlegroups.com> |
| In reply to | #111082 |
On Thursday, June 1, 2017 at 10:41:47 AM UTC+1, GOTHIER Nathan wrote: > On Thu, 1 Jun 2017 01:30:18 -0700 (PDT) > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > > > Microsoft deprecated strcpy() because the problem with C is buffer overruns leading > > to security holes. It wasn't a perfect answer, but it's an answer of sorts. > > Don't expect a bad programmer to recruit good ones when he doesn't know what's a > good code. Removing the steering wheel won't prevent bad drivers to hit the > wall. > So we're expected to believe that not only are Microsoft bad programmers, they're also such bad programmers that they can't recognise good programmers when they see one. Which explains why you don't have a job with them. Now writing operating systems isn't easy and Microsoft have largely been driven from the consumer / leisure computing market. They remain a very strong and profitable business in the corporate IT market. So how did they do that, if no-one working for them is any good?
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-06-01 12:25 +0200 |
| Message-ID | <20170601122526.508be7e20c2ce3340bc45316@gmail.com> |
| In reply to | #111085 |
On Thu, 1 Jun 2017 03:13:12 -0700 (PDT) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > So we're expected to believe that not only are Microsoft bad programmers, they're > also such bad programmers that they can't recognise good programmers when they > see one. Which explains why you don't have a job with them. You're assuming badly the fact that good programmers would like to work for Microsoft... that explains why Linus TORVALDS works for this company. > Now writing operating systems isn't easy and Microsoft have largely been driven > from the consumer / leisure computing market. They remain a very strong and profitable > business in the corporate IT market. So how did they do that, if no-one working for them > is any good? Does Microsoft sell its operating system only to computer experts? Should I recall you the forced sale (aka the Windows tax) of its operating system on most computer on the market?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-06-01 04:48 -0700 |
| Message-ID | <6d70705e-447e-4d98-a13f-809f5b95c674@googlegroups.com> |
| In reply to | #111086 |
On Thursday, June 1, 2017 at 11:28:46 AM UTC+1, GOTHIER Nathan wrote: > On Thu, 1 Jun 2017 03:13:12 -0700 (PDT) > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > > > So we're expected to believe that not only are Microsoft bad programmers, they're > > also such bad programmers that they can't recognise good programmers when they > > see one. Which explains why you don't have a job with them. > > You're assuming badly the fact that good programmers would like to work for > Microsoft... that explains why Linus TORVALDS works for this company. > Microsoft offer an extremely attractive compensation package. So most people will work for them rather than accept less elsewhere. Not everybody, some people are with a competitor which also pays very attractively, some people have other reasons. But most programmers would accept a job offer from Microsoft given the option. > > > Now writing operating systems isn't easy and Microsoft have largely been driven > > from the consumer / leisure computing market. They remain a very strong and profitable > > business in the corporate IT market. So how did they do that, if no-one working for them > > is any good? > > Does Microsoft sell its operating system only to computer experts? Should I > recall you the forced sale (aka the Windows tax) of its operating system on > most computer on the market? > Increasingly yes. A few years ago, many people had a Windows machine for general- purpose computing, web browsing, games, a bit of work-related stuff. Now they are increasingly likely to have an Apple notebook or a tablet / smartphone. PC sales have fallen as a result. However you can't run most business software on a phone, PCs are still very common in the office, where they are purchased by IT professionals.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-06-01 14:27 +0200 |
| Message-ID | <20170601142711.5962feb88d3868108a63fc75@gmail.com> |
| In reply to | #111093 |
On Thu, 1 Jun 2017 04:48:37 -0700 (PDT) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > Microsoft offer an extremely attractive compensation package. So most people will > work for them rather than accept less elsewhere. Not everybody, some people are > with a competitor which also pays very attractively, some people have other reasons. > But most programmers would accept a job offer from Microsoft given the option. It looks like Microsoft doesn't need a marketing department... since there are followers working for free. > Increasingly yes. A few years ago, many people had a Windows machine for general- > purpose computing, web browsing, games, a bit of work-related stuff. Now they are > increasingly likely to have an Apple notebook or a tablet / smartphone. PC sales > have fallen as a result. However you can't run most business software on a phone, > PCs are still very common in the office, where they are purchased by IT professionals. So now only IT pro buy computers... that a wonderful news for Microsoft. Windows shouldn't be preinstalled and bound to new machines to be sold like baguettes. This potentially would allow the company to make better margins selling only overpriced pro edition licenses to local distributors.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-06-01 05:55 -0700 |
| Message-ID | <043fe053-a9de-4f08-bc69-d9bd226a2ea2@googlegroups.com> |
| In reply to | #111096 |
On Thursday, June 1, 2017 at 1:30:30 PM UTC+1, GOTHIER Nathan wrote: > On Thu, 1 Jun 2017 04:48:37 -0700 (PDT) > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > > > Microsoft offer an extremely attractive compensation package. So most people will > > work for them rather than accept less elsewhere. Not everybody, some people are > > with a competitor which also pays very attractively, some people have other reasons. > > But most programmers would accept a job offer from Microsoft given the option. > > It looks like Microsoft doesn't need a marketing department... since there are > followers working for free. > Just stating the obvious. If you can get in at Microsoft then it's a good place to be, the company is very profitable and that is reflected in the compensation packages on offer. But of course you have to be very good to pass the interviews. > > > Increasingly yes. A few years ago, many people had a Windows machine for general- > > purpose computing, web browsing, games, a bit of work-related stuff. Now they are > > increasingly likely to have an Apple notebook or a tablet / smartphone. PC sales > > have fallen as a result. However you can't run most business software on a phone, > > PCs are still very common in the office, where they are purchased by IT professionals. > > So now only IT pro buy computers... that a wonderful news for Microsoft. > Windows shouldn't be preinstalled and bound to new machines to be sold like > baguettes. This potentially would allow the company to make better margins > selling only overpriced pro edition licenses to local distributors. > Apple also sells operating systems pre-installed. It just also manufactures the hardware. So Microsoft have the more open model. If you want Linux, you have to either build your own PC from components, or, as we used to do when I was working with Linux, buy a Windows machine and delete the OS. If manufacturers had to sell a Linux version alongside a Windows version, that would badly damage Microsoft's business model. But not by so much now as it would have done had that policy been in place ten years ago, as I said, they are gradually losing the domestic and consumer markets.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-06-01 11:11 -0400 |
| Message-ID | <ogpakr$rcf$2@jstuckle.eternal-september.org> |
| In reply to | #111100 |
On 6/1/2017 8:55 AM, Malcolm McLean wrote: > On Thursday, June 1, 2017 at 1:30:30 PM UTC+1, GOTHIER Nathan wrote: >> On Thu, 1 Jun 2017 04:48:37 -0700 (PDT) >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >> >>> Microsoft offer an extremely attractive compensation package. So most people will >>> work for them rather than accept less elsewhere. Not everybody, some people are >>> with a competitor which also pays very attractively, some people have other reasons. >>> But most programmers would accept a job offer from Microsoft given the option. >> >> It looks like Microsoft doesn't need a marketing department... since there are >> followers working for free. >> > Just stating the obvious. If you can get in at Microsoft then it's a good place to be, > the company is very profitable and that is reflected in the compensation packages > on offer. But of course you have to be very good to pass the interviews. And therein lies Nathan's problem. He couldn't get a job as a programmer at Microsoft or any other decent company. Maybe a fly-by-night outfit, at least until they figure out how stoopid he is. >> >>> Increasingly yes. A few years ago, many people had a Windows machine for general- >>> purpose computing, web browsing, games, a bit of work-related stuff. Now they are >>> increasingly likely to have an Apple notebook or a tablet / smartphone. PC sales >>> have fallen as a result. However you can't run most business software on a phone, >>> PCs are still very common in the office, where they are purchased by IT professionals. >> >> So now only IT pro buy computers... that a wonderful news for Microsoft. >> Windows shouldn't be preinstalled and bound to new machines to be sold like >> baguettes. This potentially would allow the company to make better margins >> selling only overpriced pro edition licenses to local distributors. >> > Apple also sells operating systems pre-installed. It just also manufactures the hardware. > So Microsoft have the more open model. If you want Linux, you have to either build > your own PC from components, or, as we used to do when I was working with Linux, > buy a Windows machine and delete the OS. If manufacturers had to sell a Linux version > alongside a Windows version, that would badly damage Microsoft's business model. > But not by so much now as it would have done had that policy been in place ten years > ago, as I said, they are gradually losing the domestic and consumer markets. > You can buy computers with no OS installed, and install the one of your choice. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web