Holiday Game
in [ASM]
|
Prev: Win32 non blocking console input?
Next: hugi compo #29
From: robertwessel2 on 11 Dec 2008 15:07 On Dec 10, 2:44 pm, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > <robertwess...(a)yahoo.com> wrote in message (Discussion of the C relationship between bytes and chars snipped.) Well, I'll take your statement that you've proven your position as something approximating you being convinced, and leave it at that, and we'll have to agree to disagree. We've both said the same things to each other several times, and it's failing to make an impression. But remind me not to buy a C compiler from you. ;-) > Disregarding the fact C doesn't have arrays (since everyone I've > presented this to fails to understand this....), Certainly true for some definitions of "array". But I think it's reasonable when discussing the C standard to assume we mean the thing the C standard calls an "array." > > In what sense are the functions of setjmp and longjmp ambiguous? > > Where they are useable depends on the implementation. Since the > implementation can't be standardized due to different hardware, setjmp and > longjmp can't be completely standardized either. What can't be > standardized, can't be abstracted. > > > A couple I've already addressed, and the others > > (offsetof, for example) are quite possible to portably, if you observe > > the specified restrictions. > > The C Rationale "suggests" four methods. I.e., offsetof is non-portable. > The closest "anyone" has come to a portable definition is X11's > definition... IIRC (I can't find the code at the moment), it has one basic > macro which works for many systems, but then has a number of other custom > macro's. I'm puzzled as to what you mean by abstraction in this context. While setjmp, offsetof; malloc and fread cannot be *implemented* portably, they all must be implemented and must perform as specified. IOW, they abstract the actual implementation of the function in question. In the case of setjmp/longjmp, the hardware state of part of the machine, and how the compiled code interacts with that needs to be dealt with. In most cases it's not possible to implement without some assembler. But in all cases longjmp causes execution to (loosely) go back to the return from the setjmp; In the case of offsetof, a macro that provides the function must exist, even if it requires some compiler extension to achieve. IOW: #define offsetof(a, b) _magiccompileroffsetofsupport(a,b) is acceptable, as well as the common macro that does math on a null pointer. The one youre probably remembering is similar to: #define offsetof(st, m) ((size_t) ( (char *)&((st *)(0))->m - (char *)&((st *)(0)) )) (shamelessly copied from the Wikipedia page) The point is that the implementation provides a working definition, and Im not allowed to change it (at least not and expect it to still work). Malloc will probably (on occasion) call sbrk on *nix, HeapAlloc on Windows, and use the GETMAIN macro on MVS. But it will get storage for me, in a form usable in a C program. And fread probably has to call read on a *nix box, ReadFile on Windows, somehow invoke the GET assembler macro on MVS, or Int 21h/3fh on DOS. Your position would seem to even rule out basic arithmetic (assuming, for a moment, that the C definitions of the types were stricter), because the actual implementation (generated code) is 100% specific to the particular implementation. Unless youre trying to completely separate the compiler from the library, which is not possible even a freestanding implementation must provide several headers (including the one with the locally correct definition of offsetof). |