Xref: utzoo comp.std.c:946 comp.lang.c:17269 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.std.c,comp.lang.c Subject: Re: Testing Equal Pointers (was: detecting invalid pointers) Message-ID: <1989Mar29.083727.8934@ateng.ateng.com> Date: 29 Mar 89 13:37:27 GMT References: <1989Mar21.085704.15894@ateng.ateng.com> <16039@cup.portal.com> <375@sdti.SDTI.COM> <9930@smoke.BRL.MIL> Followup-To: comp.std.c Organization: A T Engineering, Tampa, FL Lines: 40 Unfortunately, I apparently did not make myself clear when writing about pointer comparison under Microsoft C. Prescott Turner misunderstood me, posting his expressions of disbelief. For reference, I wrote in part: > For totally correct comparisons of all pointers, it's necessary > to normalize them by hand, or be sure that they are cast to "huge *" when > any pointer arithmetic is done. Otherwise, the different combinations of > segment+offset that actually refer to the same address do not compare equal. In the context of the quoted article, "all pointers" includes pointers constructed *by hand*, i.e. non-portably. If all pointers in a Microsoft C program are generated in the normal C fashion, that is, by use of the "&" operator and pointer arithmetic, the "==" and "!=" operators work as expected. No need to worry, Prescott. Incidentally, these comments apply equally to Turbo C. On the other hand, Doug Gwyn comments: >(Except that certain operations not permitted of conforming applications >might produce pointers that accidentally refer to the same location; but >since that would be totally erroneous code, you shouldn't worry about it.) I beg to disagree. Non-portable is not the same as erroneous, at least in the real world of applications programming. (I'm sure Doug knows what I mean here, even if he avoids such situations wherever possible, as I do.) After all, if a given algorithm is non-portable and is therefore surrounded by "#ifdef MSDOS"/"#endif", why bother trying to make its implementation portable? For an example: Name a portable way to get the complete shift state of a keyboard. No, wait, that's too hard. Name a portable way to *express* the complete shift state of a keyboard. Code involving such an entity is non- portable from the get-go; so there's no reason to avoid non-portable coding in its implementation. -- Chip Salzenberg or A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."