I need a new compiler...
in [Cobol]
|
Prev: COBOL/CICS/DB2 - COBOL for MVS and compile option DYNAM -solution from 2006
Next: Still one more Overlapping operands test
From: Michael Wojcik on 16 Dec 2008 15:41 docdwarf(a)panix.com wrote: > In article <gi63hm324ng(a)news7.newsguy.com>, > Michael Wojcik <mwojcik(a)newsguy.com> wrote: >> docdwarf(a)panix.com wrote: >>> If C, in fact, does *not* 'provide low-level access to memory' ... >> >> ISO 9899-1999 is, of course, the authoritive source; but the >> comp.lang.c FAQ would also have cleared up this misconception. > > I have found something calling it'sself the comp.lang.c FAQ at > http://c-faq.com/ . This leads me to a section about pointers, > http://c-faq.com/ptrs/index.html , and that leads me to a question about > 'what is the difference between arrays and pointers' > http://c-faq.com/aryptr/practdiff.html . From that page: > > --begin quoted text: > > A pointer is a reference to any data element (of a particular type) > anywhere. > > --end quoted text Note it says nothing about any correspondence between such a reference and "low-level memory". As defined by the specification of the C language, it is a reference to a location in the virtual machine. In a particular C implementation, it might be a reference to a physical memory location (as in many small systems), or to a location in process virtual memory (as in many general-purpose systems), or to an object in system-wide virtual store (as in the capability architecture used by IBM's iSeries, formerly AS/400, line). Or it could be a magic token that summons an invisible fairy who fetches the data from a mushroom in the forest. The definition of the language *leaves this up to the implementation*. > Now... if the reference provided by a pointer is one towards low-level > memory (a sub-set of 'anywhere') If it is. But it may not be, since there are many other subsets of "anywhere". The quoted text doesn't say that pointers could be constructed to point to anywhere; it says the object referred to by the pointer could be anywhere. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 16 Dec 2008 15:35 Paul wrote: > On 2008-12-15 10:32:41 -0600, Michael Wojcik <mwojcik(a)newsguy.com> said: >> PR wrote: >>> On Dec 12, 11:29 am, Michael Wojcik <mwoj...(a)newsguy.com> wrote: >>>> No, it doesn't. Some C implementations may extend the language to >>>> provide direct access to memory and devices (whatever that may mean on >>>> the platform), but that's not part of the C language. >>> >>> Actually, yes it it. >> >> No, it is not. I suggest you read ISO 9899-1999 (plus Technical >> Corregida), which is the definition of the C language. You will find >> that it does not require implementations to "provide low-level >> system/memory/device access", and indeed does not define any language >> constructs which remotely resemble anything such "access" might include. > > Oh yes, it is. Pointers, and address and indireciton operators were > ratified with C89, and are maintained through all current implementations. And no part of the standard requires that pointers or the address or indirection operators provide access to system memory. Feel free to cite c&v if you believe otherwise. >>> Access to memory is always defined in C, as >>> pointers are intrinsic. >> >> C pointers do not need to provide access, "low-level" or otherwise, to >> physical memory or devices. They need to support the dereference >> operator, and so could be considered as providing access to "memory" >> in the sense of the abstract machine, but there is *absolutely no >> requirement* that such access have any particular relationship to the >> hardware. > > No, they are address operators, similar to and interchangable with the & > operator. Pointers are not "address operators" in any way, shape, or form. There is one address operator (&), and there are various cases where other constructs decay to addresses. But, once more, those addresses are purely defined in terms of the virtual machine and do not have any required correspondence with the physical machine. ISO 9899-1999 5.1.2.3 #1: "The semantic descriptions in this International Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant." > There is very much an absolute requirement that they do. Care to show us where in ISO 9899 that requirement appears? > You are arguing C++, which is a totally different animal indeed. I most certainly am not. ISO 9899 is the C specification. >>> And pointers are not special variable types, >> >> Indeed. They have pointer type, which is not "special" (whatever that >> might mean). But it's not any other kind of type, either. > > Pointers are address operators, always. Pointers are not operators in C, so your claim is invalid by definition. > If you don't know what > "special" means in terms of language and compile construction, then look > it up. The usage of the term is both precise and accurate. Complete rot. "Special type" has no single special meaning as a term of art in computation theory or compiler design. The references I have to hand use it in a variety of ways, or not at all. >> Originally, yes. As the language is currently defined, no. Type >> punning between pointers and integers invokes Undefined Behavior. That >> it works in some implementations is beside the point. > > It invokes a warning at compile time that you did something without a > cast. You really can't be bothered to check, can you? 6.3.2.3 #5: "An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation." And since this conversion is not a constraint violation, conforming implementations are not required to issue a diagnostic, so you're wrong on that count, too. > You can certainly cast an address to an integer. I never claimed otherwise. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Paul on 16 Dec 2008 22:27 On 2008-12-16 14:35:39 -0600, Michael Wojcik <mwojcik(a)newsguy.com> said: > Paul wrote: >> On 2008-12-15 10:32:41 -0600, Michael Wojcik <mwojcik(a)newsguy.com> said: >>> PR wrote: >>>> On Dec 12, 11:29 am, Michael Wojcik <mwoj...(a)newsguy.com> wrote: >>>>> No, it doesn't. Some C implementations may extend the language to >>>>> provide direct access to memory and devices (whatever that may mean on >>>>> the platform), but that's not part of the C language. >>>> >>>> Actually, yes it it. >>> >>> No, it is not. I suggest you read ISO 9899-1999 (plus Technical >>> Corregida), which is the definition of the C language. You will find >>> that it does not require implementations to "provide low-level >>> system/memory/device access", and indeed does not define any language >>> constructs which remotely resemble anything such "access" might include. >> >> Oh yes, it is. Pointers, and address and indireciton operators were >> ratified with C89, and are maintained through all current implementations. > > And no part of the standard requires that pointers or the address or > indirection operators provide access to system memory. Feel free to > cite c&v if you believe otherwise. You are arguing a strawman argument here. Show me one single implementation of C that does not provide access to memory - regardless of whether it is system or application memory - and we might have more basis to talk. > >>>> Access to memory is always defined in C, as >>>> pointers are intrinsic. >>> >>> C pointers do not need to provide access, "low-level" or otherwise, to >>> physical memory or devices. They need to support the dereference >>> operator, and so could be considered as providing access to "memory" >>> in the sense of the abstract machine, but there is *absolutely no >>> requirement* that such access have any particular relationship to the >>> hardware. >> >> No, they are address operators, similar to and interchangable with the & >> operator. > > Pointers are not "address operators" in any way, shape, or form. There > is one address operator (&), and there are various cases where other > constructs decay to addresses. > > But, once more, those addresses are purely defined in terms of the > virtual machine and do not have any required correspondence with the > physical machine. > > ISO 9899-1999 5.1.2.3 #1: "The semantic descriptions in this > International Standard describe the behavior of an > abstract machine in which issues of optimization are irrelevant." Pointers in C very much are address operators, in every way, shape, and form. How can they be otherwise? The very word "dereference" is, and always has been, a term used in regards to memory operations - as in "resolve the address of this item and retrieve the value." And again, that comes from PDP-11 Assembler. > >> There is very much an absolute requirement that they do. > > Care to show us where in ISO 9899 that requirement appears? Sorry - you are alone on this one. You can show us an example of a C implementation (not C++) that doesn't allow one to access memory, and we will have more to talk about. > >> You are arguing C++, which is a totally different animal indeed. > > I most certainly am not. ISO 9899 is the C specification. > >>>> And pointers are not special variable types, >>> >>> Indeed. They have pointer type, which is not "special" (whatever that >>> might mean). But it's not any other kind of type, either. >> >> Pointers are address operators, always. > > Pointers are not operators in C, so your claim is invalid by definition. I believe you are simply wrong here, but arguing in circles won't make any difference. What do you think *myPointer is? Chopped liver? Pointers are an implementation of the PDP-11 indirect reference, meaning the content of a memory address. And are manipulated the same was a PDP-11 GPR. As such, they are also operators tht serve to provide indirect memory references. > >> If you don't know what >> "special" means in terms of language and compile construction, then look >> it up. The usage of the term is both precise and accurate. > > Complete rot. "Special type" has no single special meaning as a term > of art in computation theory or compiler design. The references I have > to hand use it in a variety of ways, or not at all. Great! Then you should not what special means. > >>> Originally, yes. As the language is currently defined, no. Type >>> punning between pointers and integers invokes Undefined Behavior. That >>> it works in some implementations is beside the point. >> >> It invokes a warning at compile time that you did something without a >> cast. > > You really can't be bothered to check, can you? Sure I can, and did. Just look at the .4 section that deals with the & operator. > > 6.3.2.3 #5: "An integer may be converted to any pointer type. Except > as previously specified, the result is implementation-defined, might > not be correctly aligned, might not point to an entity of the > referenced type, and might be a trap representation." > > And since this conversion is not a constraint violation, conforming > implementations are not required to issue a diagnostic, so you're > wrong on that count, too. > >> You can certainly cast an address to an integer. > > I never claimed otherwise. <shrug> Conversation is over on my part. I find most of your claims specious, and presented based on only a partial understanding. Perhaps based upon a Microsoft point of view. You may feel the same way about me, sans the Microsoft slant on things. I wonder if you are the same guy that was arguing that .NET was the first really object oriented design platform a year or two ago?
From: Richard on 16 Dec 2008 22:53 On Dec 17, 4:27 pm, Paul <paul-nospamatall.rauler...(a)mac.com> wrote: > On 2008-12-16 14:35:39 -0600, Michael Wojcik <mwoj...(a)newsguy.com> said: > > > > > Paul wrote: > >> On 2008-12-15 10:32:41 -0600, Michael Wojcik <mwoj...(a)newsguy.com> said: > >>> PR wrote: > >>>> On Dec 12, 11:29 am, Michael Wojcik <mwoj...(a)newsguy.com> wrote: > >>>>> No, it doesn't. Some C implementations may extend the language to > >>>>> provide direct access to memory and devices (whatever that may mean on > >>>>> the platform), but that's not part of the C language. > > >>>> Actually, yes it it. > > >>> No, it is not. I suggest you read ISO 9899-1999 (plus Technical > >>> Corregida), which is the definition of the C language. You will find > >>> that it does not require implementations to "provide low-level > >>> system/memory/device access", and indeed does not define any language > >>> constructs which remotely resemble anything such "access" might include. > > >> Oh yes, it is. Pointers, and address and indireciton operators were > >> ratified with C89, and are maintained through all current implementations. > > > And no part of the standard requires that pointers or the address or > > indirection operators provide access to system memory. Feel free to > > cite c&v if you believe otherwise. > > You are arguing a strawman argument here. > > Show me one single implementation of C that does not provide access to > memory - regardless of whether it is system or application memory - and > we might have more basis to talk. > > > > > > >>>> Access to memory is always defined in C, as > >>>> pointers are intrinsic. > > >>> C pointers do not need to provide access, "low-level" or otherwise, to > >>> physical memory or devices. They need to support the dereference > >>> operator, and so could be considered as providing access to "memory" > >>> in the sense of the abstract machine, but there is *absolutely no > >>> requirement* that such access have any particular relationship to the > >>> hardware. > > >> No, they are address operators, similar to and interchangable with the & > >> operator. > > > Pointers are not "address operators" in any way, shape, or form. There > > is one address operator (&), and there are various cases where other > > constructs decay to addresses. > > > But, once more, those addresses are purely defined in terms of the > > virtual machine and do not have any required correspondence with the > > physical machine. > > > ISO 9899-1999 5.1.2.3 #1: "The semantic descriptions in this > > International Standard describe the behavior of an > > abstract machine in which issues of optimization are irrelevant." > > Pointers in C very much are address operators, in every way, shape, and form. > How can they be otherwise? The very word "dereference" is, and always > has been, a term used > in regards to memory operations - as in "resolve the address of this > item and retrieve the value." > > And again, that comes from PDP-11 Assembler. and probably every other assembler ever. > >> There is very much an absolute requirement that they do. > > > Care to show us where in ISO 9899 that requirement appears? > > Sorry - you are alone on this one. You can show us an example of a C > implementation > (not C++) that doesn't allow one to access memory, and we will have > more to talk about. You have broadened the argument to 'access memory'. Name one useful language that does not allow an 'access to memory'. Here's an example of an 'access to memory': MOVE Var1 TO Var2 What was _actually_ being discussed was 'low-level' access, or access to _system_ memory. In many cases a C program cannot access arbitrary memory areas and has no facility, not even pointers, to access outside the memory area that it has been assigned by the operating system, just like many other languages. > >> You are arguing C++, which is a totally different animal indeed. > > > I most certainly am not. ISO 9899 is the C specification. > > >>>> And pointers are not special variable types, > > >>> Indeed. They have pointer type, which is not "special" (whatever that > >>> might mean). But it's not any other kind of type, either. > > >> Pointers are address operators, always. > > > Pointers are not operators in C, so your claim is invalid by definition.. > > I believe you are simply wrong here, Your claim was (read it twice): "Pointers are address operators". They are not "operators", &, +, =, are. Pointers are not. In many cases pointers may be addresses. Whether they are physical addresses or some other, such as a virtual address, depends on the system and the implementation. > but arguing in circles won't make > any difference. > What do you think *myPointer is? Chopped liver? Pointers are an > implementation of > the PDP-11 indirect reference, meaning the content of a memory address. > Many implementations of C do not run on PDP-11 and thus their types are not those of the PDP-11. Even if on a PDP-11 an arbitrary address in a pointer can be used to access system memory that does not mean that every implementation of C can access system memory by manipulation of pointers. > And are manipulated the same was a PDP-11 GPR. As such, they are also > operators tht > serve to provide indirect memory references. Perhaps the PDP-11 is the only computer that exists in your world. In our world the sky is blue. > >> If you don't know what > >> "special" means in terms of language and compile construction, then look > >> it up. The usage of the term is both precise and accurate. > > > Complete rot. "Special type" has no single special meaning as a term > > of art in computation theory or compiler design. The references I have > > to hand use it in a variety of ways, or not at all. > > Great! Then you should not what special means. > > > > >>> Originally, yes. As the language is currently defined, no. Type > >>> punning between pointers and integers invokes Undefined Behavior. That > >>> it works in some implementations is beside the point. > > >> It invokes a warning at compile time that you did something without a > >> cast. > > > You really can't be bothered to check, can you? > > Sure I can, and did. Just look at the .4 section that deals with the & > operator. > > > > > 6.3.2.3 #5: "An integer may be converted to any pointer type. Except > > as previously specified, the result is implementation-defined, might > > not be correctly aligned, might not point to an entity of the > > referenced type, and might be a trap representation." > > > And since this conversion is not a constraint violation, conforming > > implementations are not required to issue a diagnostic, so you're > > wrong on that count, too. > > >> You can certainly cast an address to an integer. > > > I never claimed otherwise. > > <shrug> Conversation is over on my part. > > I find most of your claims specious, and presented based on only a > partial understanding. Perhaps based upon a Microsoft point of view. > You may feel the same way about me, sans the Microsoft slant on things. I don't see _any_ Microsoft slant anywhere. > I wonder if you are the same guy that was arguing that .NET was the > first really object oriented > design platform a year or two ago?
From: Paul H on 17 Dec 2008 00:18
Wow! I have almost no idea what you guy are arguing about (maybe a little). I do understand that my comment that I want to avoid anything that seems like assembly language caused most of this. I started my career with Autocoder on an IBM 1401, then Honeywell's Easycoder, then a couple others whose names I can't remember (something on a Data general computer?) I used 8086 machine language to enable my COBOL to access serial ports, Enuf assembler!!! I conclude that no COBOL will do what I need. Maybe Clarion (I already own version 5.5), or RealBasic, if I can find a data base that stays in my target price range. Thanks for your help, everybody. Paul "Paul H" <NoSpamphobergNoSpam(a)att.net> wrote in message news:494095a5$0$5502$bbae4d71(a)news.suddenlink.net... I've been using MicroFocus Net Express for many years, but now I want to write a small application that would sell for maybe $20.00. MF would charge a run-time fee to each user, so I need to select a different Compiler. Where can I find a list of inexpensive compilers, with ratings? Does such a list exist? TIA, Paul |