LINNDR%VUENGVAX.BITNET@wiscvm.wisc.edu (12/15/86)
Recently, a posting questioned the overloading of '+' for use as an operator for forcing order of evaluation. Since the commercial '@' sign is not otherwise used in C (because of it's former as a line kill char in Version X Unix?), maybe it would be a better choice. Because this ability is a new ability, maybe its inclusion warrants a new operator. David Linn LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU | Internet ...!psuvax1!vuengvax.bitnet!linndr | UUCP
wjjordan@watrose.UUCP (12/15/86)
In article <1499@brl-adm.ARPA> LINNDR%VUENGVAX.BITNET@wiscvm.wisc.edu writes: >Recently, a posting questioned the overloading of '+' for use as an >operator for forcing order of evaluation. Since the commercial '@' sign >is not otherwise used in C (because of it's former as a line kill char >in Version X Unix?), maybe it would be a better choice. Because this ability >is a new ability, maybe its inclusion warrants a new operator. Quantum Software Systems' C compiler for the 80x86 family uses the @ to dereference pointers off the extra segment register. They've also conveniently provided -} to do the same thing for structure references. These are useful extensions in an Intel environment only, and a bloody pain to figure out and port otherwise. These make for some really sleazy machine-dependent code. Drives project assurance and test departments nuts. Jim -- I never could get the hang of Thursdays. W. Jim Jordan Moving to Toronto for a work term... no address available yet.
meissner@dg_rtp.UUCP (Michael Meissner) (12/17/86)
In article <1499@brl-adm.ARPA> LINNDR%VUENGVAX.BITNET@wiscvm.wisc.edu writes: > Recently, a posting questioned the overloading of '+' for use as an > operator for forcing order of evaluation. Since the commercial '@' sign > is not otherwise used in C (because of it's former as a line kill char > in Version X Unix?), maybe it would be a better choice. Because this ability > is a new ability, maybe its inclusion warrants a new operator. Neither "@", "`", or "$" can be introduced into the C standard because they are not in all character sets (such as 7-bit European, EBCDIC?) -- Michael Meissner, Data General ...mcnc!rti-sel!dg_rtp!meissner
pdg@ihdev.UUCP (P. D. Guthrie) (12/19/86)
In article <763@dg_rtp.UUCP> meissner@dg_rtp.UUCP (Michael Meissner) writes: >Neither "@", "`", or "$" can be introduced into the C standard because they >are not in all character sets (such as 7-bit European, EBCDIC?) '`' (Back-tick) already is used in many C's for BCD. This did not make it into the standard, and is actually undocumented in most C compilers (BSD 4.1 has it I believe). -- Paul Guthrie ihnp4!ihdev!pdg This Brain left intentionally blank.
bzs@bu-cs.BU.EDU (Barry Shein) (12/19/86)
>Neither "@", "`", or "$" can be introduced into the C standard because they >are not in all character sets (such as 7-bit European, EBCDIC?) Whoops, let's clinch this one immediately. @ and $ are certainly in EBCDIC. EBCDIC, being a 256 character set [more or less] is pretty much a super-set of ASCII. In fact, the problems with translation (and thus lossage people infer these things from) is that it sometimes defines the same characters as two different bit patterns, one for printing and the other for, I dunno, "telecommunications" and a system appears to lose if you hand it a program with the wrong one (even tho it looks right on a printout.) Actually, the "problem" is also propagated by IBM327x EBCDIC terminals which don't have {} keys and a few others that C programmers look for (but they do have 'not' and 'cents' :-) That's a problem with those ubiquitous terminals, not EBCDIC (typing in C on an ASCII terminal via an IBM7171 YALE/ASCII mux yields no problems, throw away those data-entry stations.) However, I believe TSO used @ and # as line kill and delete, as UNIX did, perhaps that's where some of this comes from (they were settable.) -Barry Shein, Boston University