peter@sugar.UUCP (Peter da Silva) (04/11/88)
In article <8449@agate.BERKELEY.EDU>, doug@eris.UUCP writes: > In article <893@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > > case 'REXX': > > This is bad style...it is not guaranteed to work, according to K&R, and > certainly does *not* work with many C compilers. Whadda you know. Every compiler I've hit with this so far has worked just fine. I just assumed that it was in K&R. After all, it makes perfect sense, modulo byte ordering problems, so by the principle of least astonishment it should be there. Hey! X3J11! Here's something that should be in the standard, and that has prior art, and is useful. How about it? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
daveb@geac.UUCP (David Collier-Brown) (04/11/88)
| In article <8449@agate.BERKELEY.EDU>, doug@eris.UUCP writes: || case 'REXX': | This is bad style...it is not guaranteed to work, according to K&R, and | certainly does *not* work with many C compilers. In article <1813@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: | Whadda you know. Every compiler I've hit with this so far has worked just | fine. I just assumed that it was in K&R. After all, it makes perfect sense, | modulo byte ordering problems, so by the principle of least astonishment | it should be there. Well, it works IFF you have 4-byte words, or a good promotion mechanism to make 'REXX' turn into a long automagically (some do). It truncates on many 16-bit machines... including one old pdp-11 I remember fondly. If you want something humorous, try using case `REXX` (notice the quotes) on a machine using an old copy of PCC: It tries to generate BCD for a GCOS 3 machine. --dave (prior art, yes. yucko, though) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
doug@eris (Doug Merritt) (04/11/88)
[ re: long character constants like "case 'REXX':" ] >Whadda you know. Every compiler I've hit with this so far has worked just >fine. I just assumed that it was in K&R. After all, it makes perfect sense, >modulo byte ordering problems, so by the principle of least astonishment >it should be there. > >Hey! X3J11! Here's something that should be in the standard, and that has >prior art, and is useful. How about it? Well, not really, although it sounds good at first...Consider that C does not even require longs to be 32 bits. But 'REXX' definitely does require 32 bits. Also, what you're really doing is a form of character array packing. The principle of least astonishment does not apply here, because the single quotes refer just to a one-character constant, not an array. Note that K&R similarly frowns on two char constants like 'AB'; although some compilers allow it, it cannot be depended on. If what you want is a facility for specifying packed character constants, then the issue needs to be thought out in regard to its impact on the language overall. It's not just a question of the original intended usage of 'REXX'. What people usually want is to be able to put ANYTHING in a switch statement, and in fact a number of languages have been developed that allow this. It just turns into syntactic-sugar for a sequence of if- then-elses. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (04/12/88)
In article <1813@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <8449@agate.BERKELEY.EDU>, doug@eris.UUCP writes: >> In article <893@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >> > case 'REXX': >> >> This is bad style...it is not guaranteed to work, [ ... ] > >Every compiler I've hit with this so far has worked just fine. [ ... ] >Hey! X3J11! Here's something that should be in the standard, and that has >prior art, and is useful. How about it? > ^^^^^^^^^ From what I've heard of the ANSI committee's activities so far, doesn't this condition preclude it from consideration for inclusion into the "standard"? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jss@hector.UUCP (Jerry Schwarz) (04/13/88)
Why are people complaining about the ANSI committee's treatment of 'REXX' when they did exactly what the complainers want? I quote(section 3.1.3.4) : "The value of an integer character constant containing more than one character, ..., is implementation defined." Under the dpANS the status of 'REXX' in C remains exactly what it has been. Jerry Schwarz Bell Labs, Murray Hill
peter@sugar.UUCP (Peter da Silva) (04/14/88)
In article <2563@geac.UUCP>, daveb@geac.UUCP writes: > I said... > > > case 'REXX': > > ... makes perfect sense, modulo byte ordering problems, > > so by the principle of least astonishment it should be there. > Well, it works IFF you have 4-byte words, or a good promotion > mechanism to make 'REXX' turn into a long automagically (some do). Well, that's what I'm suggesting be added to ANSI. After all, they're adding lots of stuff that's even less likely to be useful. Basically, make 'chars' map unto an unsigned integer of length necessary to fit that many characters into. The maximum would depend on how many characters you can fit into the longest long. On machines like the Cray that'd be 8 characters. > It truncates on many 16-bit machines... including one old > pdp-11 I remember fondly. I never tried case 'ABCD' on a pdp-11, but I found case 'AB' quite useful. > If you want something humorous, try using case `REXX` (notice the > quotes) on a machine using an old copy of PCC: It tries to generate > BCD for a GCOS 3 machine. That's a neat idea. That's something else that would be useful when dealing with machines like Spermys and Control Data boxes that have weird charset sizes: `xxx` means xxx in the native character set, for cases where ANSI is supported but not the lowest common denominator. On the PDP-11 that would be RAD-50 :->. Sort of like the Fortran 4 plus notation "6RMCP..." :->. > --dave (prior art, yes. yucko, though) c-b For 'C'-as-structured-assembly-weenies it's totally k00l :->. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
peter@sugar.UUCP (Peter da Silva) (04/14/88)
In article <8572@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: > [ re: long character constants like "case 'REXX':" ] > Well, not really, although it sounds good at first...Consider that C > does not even require longs to be 32 bits. But 'REXX' definitely does > require 32 bits. What this really is is an unsigned integer containing the characters. You can do this in FORTRAN, even. Anyway, if there aren't enough bits in a long to support the string 'REXX', then it should be flagged as a warning. > Also, what you're really doing is a form of character > array packing. What makes you say this? It's just a way of specifying another bit pattern that a long can have. It's just more convenient than 0x52455858L. Just as 'a' is more convenient than 0x61. There are lots of languages that don't even provide a consistent method of specifying 1-character constants. Pascal, for instance (quick, is 'a' a character or a string?). > What people usually want is to be able to put ANYTHING in a switch > statement, and in fact a number of languages have been developed that > allow this. It just turns into syntactic-sugar for a sequence of if- > then-elses. It doesn't have to be in a switch statement. Lots of programs use character constants for tokens, for all sorts of purposes. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.