Please consider other character codes. An EBCDIC port of GCC is alive and well on several of the "legacy" operating systems (MVS, VM and Music) that run on the Hercules IBM 360/370/XA/390/z emulator. And whilst zLinux runs in ASCII (or whatever it uses to get more than 256 points in a code page) many zLinux sites also have the zVM hypervisor, which includes an optional EBCDIC C compiler. Having ported the BREXX interpreter to this environment I was stung by the fact that the original author had made assumptions about character ordering that are not true on an EBCDIC platform.

It was thus said that the Great David Riley once stated: Indeed that was the case. I had: while(size--) { dest[size] = (char)((value & 0x0F) + '0'); if (dest[size] > '9') dest[size] += 7; value >>= 4; } And when I changed the code to: while(size--) { dest[size] = "0123456789ABCDEF"[value & 0x0F]; value >>= 4; } It almost doubled the speed of the program (compiled with "gcc -O3 -fomit-frame-pointer -NDEBUG"), which really surprised me. I didn't think modern systems were that about about handling branches. -spc (But I'm still interested in my original question though ... )

On 31 Jan 2012 at 13:05, Sean Conner wrote: His approach is better--and probably faster on most hardware--and it's certainly clearer to someone reading the code. It also leaves you with the ability to make substitutions for characters (e.g. lowercase instead of uppercase). Does C require 8-bit byte addressability? Are other "byte" lengths permitted, such as 9 bits for system using 36 bit words? --Chuck

On 31 Jan 2012 at 14:17, schoedel at kw.igs.net wrote: That's what I thought--and I seem to remember a port of Unix to the Univac 1100 series that used 9 bit "bytes". So that &0x0f will have issues for creating dumps on that machine. Writing truly portable code is daunting. I recall that when "portable" text-based programs were written in FORTRAN, the first data card in the deck was the character set for the hardware, read in A1 format. In fact, you didn't even know that the system you were working on did arithmetic in binary. We seem to have forgotten decimal computers. How many modern computer languages REQUIRE binary arithmetic and logical operations? --Chuck

Any thing longer than "8". The constant CHAR_BIT as defined in "limits.h" should say how many bits/byte... The Honeywell L66 series (and later the DPS8) which some one elase has mentioned has 36-bit words which can be treated as 4x9-bit bytes or 6x6 bit BCD characters. I only ever wrote in "B" on these machines which had no notion of characters, everything was done in terms of words.. There were routines to convert to characters for i/o.. Dave Wade G4UGM Illegitimi Non Carborundum

On 31 Jan 2012 at 14:17, schoedel at kw.igs.net wrote: EXACTLY! In the early days of the Mac, I played briefly (long enough to walk away from) a compiler that had 16 bits as sizeof(char)

Depends on what you're doing. I've written plenty of code for which 256-entry tables are totally practical but 65536-entry tables are somewhere between difficult and completely out of the question. (And even without such tables, related remarks apply; for example, enumerating all pairs of chars is often reasonable for 8-bit chars but utterly out of reach for 16-bit chars.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 31/01/12 1:05 PM, Sean Conner wrote: This is essentially how Professor Knuth achieved portability to non-ASCII systems for TeX, METAFONT and his other tools. --Toby

At 7:35 pm -0800 2012/01/31, Chuck Guzis wrote: Yes. "A pointer to void shall have the same representation and alignment requirements as a pointer to a character type." Pointers to other types are not required to have the same representation, but it is necessary to be able to convert to a void* and back without losing information. Yes, because a union of a char and an int is possible. That's a separate question, which is mostly covered in a separate technical report TR 18037. The standard does allow pointers to two different objects to have the same value, and therefore be distinguished only in some other way, e.g. TR 18037 address space. -- Kevin Schoedel <schoedel at kw.igs.net> VA3TCS

Well, it does have to be in the sense that it has to be possible to (somehow) refer to individual chars. It does not have to be char-addressable in the sense of there being any machine-code object which can be trivially indirected through to obtain a single C char. Indeed, there is no _requirement_ that C use whatever indirection the machine code level supports, though if there's a way to implement the C abstract machine semantics without too much hair, it should be used. I think there was once a C implementation for the Lisp Machine that represented pointers as <array,index> pairs - Lisp arrays, of course. Only if you never use the rest of the word for any purpose, because copying something by pointer casting to char * or unsigned char * and copying the chars has to copy the entire object. (The Lisp Machine implementation above presumably took advantage of the way that model of Lisp Machine allowed two arrays to overlay one another, sharing storage.) Yes and no. They have to share the same space in the sense that copying the chars making up an object copies the object. They do not have to share the same space in the sense that the conversion between (say) a pointer-to-int and a pointer-to-char pointing to the first char making up the int may be an arbitrarily complicated operation. (As a quality-of-implementation issue, it's probably better that it not be especially complicated, but that's not a conformance issue.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Tue, 31 Jan 2012, Chuck Guzis wrote: Absolutely. In K&R C (I don't know from ANSI), it was recommended that an int be whatever type was easiest to deal with. A short int could be the same or smaller. A long int could be the same or larger. It was explicitly stated that the only given was that the sizeof long int could not be SMALLER than the size of int, and the sizeof in could not be smaller than the sizeof short int. int and unsigned int are often the same size, but that was NOT required.

[#4] The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an E2 unsigned type, the value of the result is E1?2 , reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, E2 and E1?2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined. [#5] The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity, 2 raised to the power E2. If E1 has a signed type and a negative value, the resulting value is implementation- defined. Unsigned ints, by definition, work as if they were simple binary (two's-complement, though that's not relevant for shifts). Only for negative values, in which case the result can be whatever the implementation finds convenient (undefined or implementation-defined). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Mouse wrote: Chuck Guzis wrote: That's definitely not allowed for unsigned char, which is not allowed to have any padding bits. If an unsigned char has n bits, it must be able to represent all values from 0 to (2^n)-1. For the larger integer types it is possible, as all larger integer types are allowed to have padding bits. The requirement is that any bit that is a value bit (and not a sign bit or padding bit) in a signed type must "have the same value as the same bit in the object representation of the corresponding unsigned type" (ISO/IEC 9899:1999 section 6.2.6.2 paragraph 2) Due to the requirements for the integer size limits (limits.h, section 5.2.4.2.1), if you want to do that your short and integer will have to be at least 17 bits, long will have to be at least 33 bits, and long long will have to be at least 65 bits. This would be somewhat reasonable on an 18-bit machine or 36-bit machine, with 9-bit chars, and the other integer types being 18-bit, 36-bit, and 72-bit. However, I think most people would prefer an implementation where the unsigned integer types did not have padding bits, and could represent the full range possible with the width of the type.

Yes and no. They must be implemented in a way that looks like binary as far as the semantics visible to the abstract C machine are concerned. Whether the actual underlying storage mechanism is two-state or not is beyond the scope of the standard. (This is sometimes called the "as if" rule: everything else can be thrown out the window as long as the compiler and run-time (if applicable) arrange that it look as if the spec were being followed as far as C code can tell.) So, you can use decimal if you want, but you'll have to go through gyrations to make things like & and << and + operate _as if_ everything were actually binary. (This would probably be difficult, wasteful of storage, or both, especially considering the requirement that every object be viewable as an array of chars without loss of information. It would not be impossible.) 6.2.6.1 [#3] Values stored in unsigned bit-fields and objects of type unsigned char shall be represented using a pure binary notation. [#4] Values stored in non-bit-field objects of any other object type consist of n?CHAR_BIT bits, where n is the size of an object of that type, in bytes. ... Yes. There are three allowed representations for signed integral types: two's complement, one's complement, and sign/magnitude. 6.2.6.2 [#2] For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit. There need not be any padding bits; there shall be exactly one sign bit. ... ... If the sign bit is one, the value shall be modified in one of the following ways: -- the corresponding value with sign bit 0 is negated (sign and magnitude); -- the sign bit has the value -(2N) (two's complement); -- the sign bit has the value -(2N-1) (one's complement). Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one's complement), is a trap representation or a normal value. In the case of sign and magnitude and one's complement, if this representation is a normal value it is called a negative zero. A "trap representation" is an arrangement of bits that does not represent a value of the relevant type, and is not necessarily operable on even to the extent of storing it: 6.2.6.1 [#5] Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined. Such a representation is called a trap representation. For example, on that decimal machine, a C implementation may choose to use only values 0..7 of each digit, to store three bits of information. Any value with an 8 or 9 in it could then be a trap representation. (A trap representation does not have to actually trap; undefined behaviour can include doing something sensible to someone who knows what's really going on under the hood.) I *think* this would conform; I'll ask someone I know who knows this stuff better than I. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Tue, 31 Jan 2012, Chuck Guzis wrote: On 01/31/2012 09:48 PM, Fred Cisin wrote: Not in ISO C. All types have to be a multiple of the size of the char type, which must be at least 8 bits. You could have 8-bit char, 24 bit short, 40 bit int, and 48 bit long. You can't have a 21 bit int, unless the char type is 21 bits, because 21 doesn't have any factor n such that 8 <= n < 21. ISO C section 6.2.5 paragraph 5 says about the int type: A ??plain?? int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>). Section 6.2.5 paragraph 8 and section 6.3.1.1 together require the sizes to obey the relationship: 1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long) Section 6.2.5 paragraph 6 requires that the unsigned types have the same storage and alignment requirements as the corresponding signed types, so the above relationship also holds for the unsigned types. I just learned, somewhat to my surprise, that ISO C *requires* that there be an integer type of at least 64 bits. This requirement is in sections 7.18.1.2 and 7.18.1.3, on minimum-width integer types and fastest minimum-width integer types, which require an implementation to provide the int_least64_t, uint_least64_t, int_fast64_t, and uint_fast64_t types, and in section 7.18.2.5, which gives requirements for INTMAX_MIN, INTMAX_MAX, and UINTMAX_MAX based on having at least 64 bits. I wonder how many C implementations fail to be standard-conformant due to this requirement?

On Feb 1, 2012, at 5:51 AM, ben wrote: Well, Motorola's DSP56k isn't too far removed from that. It's a 24-bit CPU (with 56-bit accumulators), complete with a 24-bit bus which is word-addressed, so there are no byte fetches. It's been a while since I've done DSP56k work (and it was never in C), but I recall doing some gymnastics to make strings work nicely (without packing them very sparsely, anyway). - Dave

It was thus said that the Great Fred Cisin once stated: How does K&R C (which I don't consider C) differ from ANSI-C? I mean, besides function prototypes, formal variable argument functions and a standardize library of functions I can rely upon to exist? -spc (struggling with C code at work that at one point must have been K&R, and it shows ... ugh)

Actually, K&R1 C it does have something of a standard; it just is vague on a number of points and does not come from a country-level (or larger) standards body. (Of course, ANSI/ISO C is vague on a number of points too, just a lot fewer.) Sure there are. The set is just smaller than it is for ANSI/ISO C, and less well defined. It's not much of a given in ANSI/ISO C, either; it's hard to build a strictly conforming program that actually does very much that's useful. So does ANSI/ISO C. It just draws the "beyond this line you are taking advantage of implementation-specific details" line much more clearly. A modern C compiler is, after all, allowed to accept code that the standard says produces undefined behaviour, or that the standard considers syntax errors; it may even produce useful results when it does so. You just can't count on another implementation doing either. (Just like K&R1, actually, in that regard.) There are some circumstances under which the compiler is required to produce "at least one diagnostic message". But the compiler is allowed to carry on, possibly even producing a runnable program if it wants. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Mouse wrote: Good catch! I'd forgotten that integer types other than char and unsigned char are allowed to have padding bits. That's covered in section 6.2.6.2 of the ISO 9899:1999 standard. The no-padding requirement for unsigned char is explicitly stated, and the no-padding requirement for signed char follows from the that together with the requirements on the range of values of the signed char type.

On 31 Jan 2012 at 23:37, Mouse wrote: Thanks, C standards really came too late after K&R for me to take a big interest in them. While I can quote chapter and verse for FORTRAN and COBOL, the closest to "knowing" ANSI C rules is writing some back-end code. --Chuck

Um... 6.2.5 Types ... [#26] A pointer to void shall have the same representation and alignment requirements as a pointer to a character type. Not quite; there are certain pairs of types which are required to be "the same". Continuing the above quote: Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 01/31/2012 08:42 PM, Mouse wrote: Correct. ISO/IEC 9899:1999 section 7.18.1.4 states that the integer types intptr_t and uintptr_t can hold the value of a void* (and hence, the value of any pointer type), but that these types are optional. *If* the implementation has intptr_t and uintptr_t, then the same properties should hold for intmax_t and uintmax_t, since these are guaranteed to be at least as large as any other integer types. However, if the implementation does not provide intptr_t or uintptr_t, then intmax_t and uintmax_t aren't guaranteed to be able to hold pointer values.

I've often thought it would be useful to have such a thing, a "checkout" compiler which deliberately goes out of its way to break pretty much every not-promised thing it can. Efficiency would sufer, of course, but for these purposes that's a minor matter. Usually. It's _hard_ to do anything useful in a strictly conforming C program. And even strict conformance is no guarantee; whichever standard you pick, there will be compilers that predate it and/or ignore various aspects of it. I once used a language for an 8-bit microcontroller whose int was only 8 bits wide - obviously not, strictly, C, though the compiler vendor called it C and it wasn't _completely_ unreasonable of them; it was very very Cish. The Jargon File has an entry for "Berkeley Quality Software", which it says "usually has nonexistent, incomplete, or incorrect documentation, has been tested on at least two examples, and core dumps when anyone else attempts to use it". Far too much "portable" software appears to fit this description.... But, yeah, portability is always only relative. Even your example "portable regarding endianess" is only relative; does this putatively portable code actually work in unusual cases such as PDP-endian, or just the two common endiannesses? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Some (all? most?) PDP-11 setups were little-endian with respect to (8-bit) bytes within a (16-bit) short, but big-endian with respect to (16-bit) shorts within a (32-bit) long. For example, 0x87654321 would come out as the four consecutive bytes 0x65 0x87 0x21 0x43. My understanding of this phenomenon is minimal, but, for what it's worth, I think this happened because bytes-within-short was done LE by the hardware, but the PDP-11 does not have any 32-bit hardware data type, so it has to be simulated by software (much the way 32-bit machines these days do 64-bit integers), and whoever created that software support did it BE, for whatever reason. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

ons 2012-02-01 klockan 09:09 -0500 skrev Toby Thain: GCC = The commissioning engineers jive but for memory. The anecdote that DEC field engineers danced on SAIL's memory cabinets to find the wrinkles in her memory banks. For the case of gcc: a common sw whose deployment is good at finding bit errors in an PC:s memory. Compile gcc, and have gcc recompile itself at least four times, if the compile fails mysteriously (for example BUS ERROR), it is a big probability that the memory is shoot somewhere.

On Feb 1, 2012, at 11:00 AM, Mouse wrote: Now I want to make a compiler that stores items on the stack based on a PRBS sequence. You end up with guaranteed order within 2^n - 1 bytes, at least, and it would make most stack-smash exploits relatively difficult. - Dave

On Feb 1, 2012, at 11:09 AM, Dave McGuire wrote: Well, it's heading that way, and I'll take that in a heartbeat over x86. ARMs have selectable endianness, too, though I can't recall an implementation that ran them big-endian. Anyone recall any? One of the things I loved about PowerPC was that the endianness was switchable at run-time (though I'm given to understand that never worked all that well) and there were penalty-free byte-reversed load and store instructions. - Dave

Please don't use paragraph-length lines. Compensating, Not surprising; it was never designed all that well. I once spent some time reading through the documentation for a particular PowerPC CPU (the 750, I think it was). Little-endian support was...incomplete, I would call it. Put the CPU into little-endian mode and you don't get a little-endian CPU; you get a big-endian CPU with some swizzling in the memory path, and the difference shows. It looked to me as though they wanted to be able to share data structures in memory between code running big-endian and code running little-endian without having to byte-swap when crossing the endianness boundary, and considered that more important than making little-endian mode a self-consistent little-endian machine. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 02/01/2012 01:34 PM, David Riley wrote: I switched to Thunderbird for precisely that reason. I really liked OS X's Mail.app for several years, but it just seemed to become less nice with each release. I wish they'd learn to just leave stuff the hell alone when it works well and does everything it needs to do. -Dave -- Dave McGuire New Kensington, PA

On Feb 1, 2012, at 2:16 PM, Alexey Toptygin <alexeyt at freeshell.org> wrote: I get super-long unwrapped lines from some people in Thunderbird. Format=flowed is evil. If I want a CR, I'll type one. -Dave -- Dave McGuire New Kensington, PA

On Feb 1, 2012, at 2:42 PM, David Riley <fraveydank at gmail.com> wrote: The fact that it gets discussed at all is indicative of a problem. -Dave -- Dave McGuire New Kensington, PA

On 02/01/2012 04:45 PM, Richard wrote: And some new ones as well. Does it honor hard carriage returns as something other than paragraph breaks? Yes. -Dave -- Dave McGuire New Kensington, PA

In article <4F29D19A.4020007 at brouhaha.com>, Eric Smith <eric at brouhaha.com> writes: I suppose if you do that, then the receive MUA isn't required to cope with format=flowed (which IIRC says you are free to *reformat* it any way you like, including ignoring EOLs in the existing message as well as adding them). That would be preferable because it still allows MUAs that support format=flowed to do whatever they want, but flows the text to a reasonable length for MUAs that don't support format=flowed. -- "The Direct3D Graphics Pipeline" -- DirectX 9 version available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Feb 1, 2012, at 6:48 PM, Mouse wrote: Let me be clear: I wasn't suggesting your MUA/MTA was defective. Someone asked the question, I was just answering my recollection. :-) As far as Mail.app not doing format=flowed anymore, I was completely unaware of that, and I find it kind of egregious. It's a shame; I rather like it in general, but it's been doing things that get on my nerves in the most recent version, so I suppose I'll have to go MUA shopping. I'm not a huge fan of Thunderbird, but it does have a much better extension architecture and doesn't lack what I would consider important features (such as line wrapping). - Dave

I suspect Google partially misled you. I don't use Mail.app myself, any more than any other closed-source program, but those who do tell me that Mail.app used to do format=flowed correctly and then was changed to not do so, so it apparently matters what version is at issue. In any case, the message that provoked my remark was not marked format=flowed - I checked - though of course I'm not in a position to know whether this is the fault of its originating UA or some intermediate software. (I'm fairly sure it is not software under my control, though.) One that recognizes that format=flowed does not apply when it's not actually present. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 02/01/2012 05:51 PM, Liam Proven wrote: Minor irritation yesterday when I upgraded to v10 and it slowed to a crawl for 16 hours while it indexed the mail store, but it seems to have finished and perked up now. Memory usage is a down a little, although the store size has increased quite a bit (presumably due to index files). I was really hoping that the latest version would do something sensible with the threading for this list, but sadly that doesn't seem to be the case :-( cheers Jules

On 02/01/2012 01:48 PM, Al Kossow wrote: That figures. Ah-HA! So THAT'S why SoftPC never worked right on G5s. -Dave -- Dave McGuire New Kensington, PA

Anyone Local to ZIP 10512 have an adapter I could borrow for a day or two, rather urgent.... Curt

On 2 Feb 2012 at 12:50, Curt @ Atari Museum wrote: I've got an extra you can have, but I'm on the other side of the country. --Chuck

At 03:00 AM 2/1/2012, Pontus Pihlgren wrote: And then there's non-portable over time... if the language keeps changing, or compilers develop different habits, then what's the difference? - John

It would ALMOST be possible to implement a K&R C (which I call "C") on an ANALOG computer. But, ANSI-C (which I do NOT call "C") introduces MANY irrelevant, but prob'ly quite useful, restrictions that are neither present in K&R 1, nor in the spirit of C. K&R never claimed, nor implied that there was ANY portability in C. ANSI took that and created a NEW, DIFFERENT language that while recognizable in its heritage, was obviously NOT the same language. NOW, "portable to ALL platforms" means one flavor of Linux, Windoze XP, and Mac OSX. ONLY.

On 1 February 2012 14:47, Ethan Dicks <ethan.dicks at gmail.com> wrote (in part): Speaking of such vile heresies, what is Henry doing nowadays?