On 4/1/16 12:21 PM, Diane Bruce wrote: Thanks. It appears that the stdio that I'm linking against on OS X 10.9.5 does not keep the file pointers synchronized between the system and stdio. Tumble opens a file, and handlers for various image file types read and rewind the magic number trying to figure out what format the image file is in. In the case of tiff at least (haven't checked others) a syscall file descriptor is passed to libtiff. Once it's inside, the tiff library reads the magic number with a read syscall and erroneously gets data 4K into the file, so it never saw the rewind(). http://austin-group-l.opengroup.narkive.com/2RTHr3EB/fseek-3-question-typo-… talks about this issue. Being a Unix greybeard, it took a couple of days staring at it to figure out what was going on, since I had never run into a system that behaved this way. I may try going back to a G5 running 10.5 to see if OS X stdio has always behaved this way. Maybe Guy or Camerion Kaiser know, or it may have been discussed on macports.

I wonder how clearly the various manpages state the promises. It's unfortunate that lots of programmers have the habit of blaming the tool when their code breaks because they are doing "undefined" things. There's a great paper about undefined things in C, and what compilers may do, and the way a number of well known open source projects react -- not by fixing the code but by turning off all manner of optimizations instead. paul

Unfortunately Mr. (I'm assuing this is appropriate given "John") Regehr is falling into the same trap he's trying to warn against: basically, assuming that the mental model he has is the only one that could ever possibly be relevant. For example, consider the "Comparisons of Pointers to Unrelated Objects" example: # define SQLITE_WITHIN(P,S,E) \ ((uintptr_t)(P)>=(uintptr_t)(S) && \ (uintptr_t)(P)<(uintptr_t)(E)) He writes that "[c]omparisons between unrelated objects destroy determinism because the allocator makes no guarantees about their relative locations". No. Comparisons between unrelated objects destroy determinism because pointers into different objects may not be comparable! He's assuming the "the entire address space is a single array of bytes (perhaps with holes)" memory model is the only possible one. He needs to talk with someone who wrote large-model 8086 code - or someone who's used the Lisp Machine C compiler I heard of that represents pointers as <array,index> pairs. /~\ 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 Sat, 2 Apr 2016 18:58:10 -0400 (EDT) Mouse <mouse at Rodents-Montreal.ORG> wrote: Indeed, intel segmented memory model was weird. Near pointers were uncomparable between the segments, but it wasn't that unintuitive. Far pointers were insanity-inducing, though. Since there were multiple ways to represent the same address as a far pointer, there was completely no point in doing any comparisons (unless you normalized them, of course). Thankfully, huge pointers behaved exactly as one would expect, i.e. just like pointers work in the protected mode.

(Please don't use paragraph-length lines.) Yes and no. A lot of C is undefined, or implementation-defined, to allow different disagreeing implementations to coexist. Someone writing under and for one particular implementation may indeed reasonably expect certain behaviour that the standard does not promise - for example, if I'm writing for a SS-20, I consider it reasonable to expect ints to be 32-bit two's-complement, even though C qua C does not promise either part of that, and, while a new compiler may in principle break either part or both, it would have to violate the "int is the `natural' integer type for the architecture" principle to do so. Another part of this is that C originated as, and is still used as, an OS implementation language. In such use, it is not unreasonable to treat it as the "high-level assembly language" some people have called it - apparently intending it to be a criticism while not understanding that, in some senses, that's what C is _supposed_ to be. And, from that point of view, compilers that take advantage of formally-undefined behaviour to optimize things as sketched here and in Mr. Regehr's writings are not clever; they are broken. I don't think either position is unreasonable, either. Which I suppose really means that I think there are places both for compilers that act like high-level assemblers, doing the unsurprising thing from the POV of someone familiar with the architecture being compiled for, and for compilers that take advantage of all the liberty the language spec allows to optimize the hell out of the code. I'm not sure there is any fix for the problems arising when people try to satisfy both desires with the same compiler (or the same set of configuration switches to a single compiler, or some such). It's basically the "is this language right for this task?" problem in slightly different dress. Or, to see it from the "high-level assembly" position, when a less appropriate compiler (with more aggressive optimization) is used, it is, correctly, blamed (for not being apporpriate to the task at hand). It's not possible in general, because sometimes the undefined behaviour depends on something not known until run time. Consider int v; scanf("%d",&v); printf("%d",v+1); This is perfectly well-defined - until and unless someone feeds it (a suitable textual representation of) INT_MAX. There might be a place for a compiler that flagged every instance of undefined behaviour, even if it means otherwise unnecessary run-time costs, but for most purposes that would be a Bad Thing. (I've often contemplated building a `checkout' compiler that deliberately went out of its way to break various assumptions people tend to make that aren't promised, things like "all pointers are really just memory addresses, with pointer casts being no-ops" or "all signed arithmetic is two's-complement" or "the stack grows down" or "pointers into different objects are comparable" or "shims are inserted into structs only when necessary to avoid placing objects at unusual alignments" or "there are no padding bits in integer representations" or "nil pointers are all-bits-zero"....) A pity pdos.csail.mit.edu is willing to impair its accessibility for the sake of..I'm not sure what..by refusing to serve it over HTTP. /~\ 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 04/03/2016 01:31 PM, Mike Stein wrote: Well, paragraph/lines is the way most email clients function nowadays. Maybe there's a setting in Thunderbird that wraps the lines on writing a new email, but most clients are perfectly happy to wrap incoming mail to fit the windows/screen size. At least we're not putting our mail in WINMAIL.DAT attachments. But I'll be happy to comply to the wishes for preformatted text; just tell me how. --Chuck

Windows is the way most computers function nowadays. Shall we therefore reject any suggestion that Windows is not the way everyone should work? :-) (My point is that popularity, in itself, should not be taken as a recommendation.) I should certainly hope so; if not, I would call it broken and most certainly would say it should not be used (at least not for arm's-length email; for email between mutually consenting parties with prearrangement, anything agreeable to all parties goes). Or unless the user is willing to manually insert suitable line breaks, I suppose; personally, I maintain that the software should adapt to the human, not the other way around, in such cases. Perhaps, but (a) not everyone reads mail with "client"s (my MUA, for example, is not a client in any meaningful sense) and (b) we're back to popularity being used as a touchstone of goodness, as if anything that's popular is necessarily acceptable. I'd say, for running text, wrap somewhere before 80 characters per line (preferably before about 78, since some programs lose a column or two on display - personally, I wrap at column 72). I'm sure others will differ in various details, but I suspect most will probably be somewhere close to that. Of course, if you have something where line breaks have semantic relevance, such as output from a build script, leave the breaks where they belong unless you have some _really_ long lines (1000 chars or thereabouts, I think, is the SMTP maximum), in which case you can either go ahead and break them manually (preferably with a warning in accompanying text), encode the output with base64 or btoa or uuencode or some such, put the output up for fetching somewhere and just provide a link to it, etc. /~\ 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 2016-04-03 9:48 PM, Mouse wrote: If we're doing 'the right way to email' AGAIN, at least have the courtesy of changing THE SUBJECT LINE. --Toby

On 4/3/2016 8:19 PM, Toby Thain wrote: Please do not change the subject line - people who do so do not understand how email reflector programs work on email servers. All messages using the changed subject line will continue to be archived under the original subject line. If you look at the list archives you will see that the thread "tumble under BSD" has been hijacked several times, by people who have changed the subject line instead of stating a new thread., and all of those messages are archived as part of the thread "tumble under BSD." The only correct way to change the subject on an email reflector is to start a new thread with an entirely new message. Dale H. Cook, Contract IT Administrator, Roanoke/Lynchburg, VA http://plymouthcolony.net/starcityeng/index.html

Yes, Peter, that would indeed be nice, but the only one I see "conjuring up conflicts" is you... No one "demanded their inherent right to continue to generate improperly formatted emails". As you yourself note, although it's an inconvenience both Chuck and I do indeed usually respect the wishes of a small minority and use short lines. I don't think that asking why flowed text is a problem for some people and/or expressing a different perspective is necessarily "complaining"; saying that the issues mentioned "don't actually exist" or calling them "completely baseless" doesn't seem to show much respect for the folks expressing those perspectives. Flowed text and top-posting have become the norm in mainstream email with its quick back-and-forth nature and the myriad of font and screen sizes out there. I don't think it's inappropriate to periodically explore whether perhaps we're ready to move with the times here (as is the case on most other lists I'm on), especially when Mouse and Liam bring them up as they do quite regularly. Yes, let's indeed respect each other and our various different opinions and perspectives, and maybe even explore them with an open mind without denigrating them and the folks expressing them. 'Nuff said. mike ----- Original Message ----- From: "Peter Coghlan" <cctalk at beyondthepale.ie> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Monday, April 04, 2016 5:36 AM Subject: Re: The Right Way to Email - was Re: C & undefined behaviour - was Re: tumble under BSD > Mouse made a perfectly reasonable request that we make a small effort > to ensure our emails are formatted appropriately. > > The response was that people demanded their inherent right to > continue to generate improperly formatted emails, complained about > grudgingly having to having to make configuration changes to their > email setup that might have consequences for other email they send > and made other tangential complaints which as far as I can see are > either completely baseless or are an attempt at humour that has gone > over my head (not the one about the card deck though - I got that > one, even though they were before my time). > > If anyone who complained had cared to check, they were all (as far as > I can see) already generating appropriately formatted emails and have > no need to jump to the defense of the way they do things or to make > any changes to it. > > The email which prompted the mildly phrased request in response to it > appears to have been generated by "Apple Mail (2.3124)". It looks to > me that this MUA is generating "flowed" emails but failing to mark > them as such in the headers it generates. (I agree that these emails > are difficult to reply to and I would like to add that they are also > very difficult to read when viewed in the web based list archive.) > > > Regards, > Peter Coghlan

----- Original Message ----- From: "Mouse" <mouse at Rodents-Montreal.ORG> To: <cctalk at classiccmp.org> Sent: Monday, April 04, 2016 10:48 AM Subject: Re: The Right Way to Email - was Re: C & undefined behaviour - was Re: tumble under BSD ------ ... nor would I ever expect you to ;D IMO the reason that flowed text and top posting have become the norm is that many people (myself included) find them more efficient and clearer, both reading and writing; obviously you and some others find the opposite and I try to respect that in my posts to this list (although I don't feel that my perspective gets much respect). They are personal preferences, and your spam reference is just one of the straw men that seem to invariably infest these discussions. Mainstream popularity is not just the much-maligned Windows on PCs, but also iOS and Android on smart phones and tablets, and the web-based email that you also disparage is often the only option; if you don't want to communicate with anyone using Gmail that is certainly your choice to make. As I said, although I don't share it I do respect your perspective which is presumably largely based on your particular choice of hard- and software; what I object to is your judgment that top-posting is "arrogant rudeness." It may not be the norm on this particular list, but if you were to periodically ask that everyone follow your 'standards' on any other list where top-posting, in-line posting, bottom-posting, flowed text and hard-wrapped text are all equally valid and accepted and don't elicit periodic chastisement, then that probably _would_ be considered to be "arrogant rudeness"... Potaytoes, potahtoes... m

On 04/04/2016 12:30 PM, Mike Stein wrote: How so? Who reads an email message from the bottom up? It is arrogant rudeness when it is done in a place where everyone expects inline or bottom posting. When someone is repeatedly & politely asked to play along... -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech -http://certification.comptia.org/ --- HDI Certified Support Center Analyst -http://www.ThinkHDI.com/ Registered Linux user number 464583 "Computers have lots of memory but no imagination." "The problem with troubleshooting is that trouble shoots back." - from some guy on the internet.

On Mon, 4 Apr 2016, Guy Sotomayor wrote: I think bottom-posting without trimming is actually more evil than top-posting (which I personally find a bit of nuisance, but acceptable, especially in a non-technical discussion). Though to be honest I think if you're inclined to top-post (i.e. you don't want to address parts of a message being replied to individually), then you're better off not quoting it at all in the first place. It's being addressed as a whole anyway, or you need to phrase your reply such that the recipient knows which point is being discussed, so whoever needs to remind themselves what this all was about can reach for the original message. FWIW I think the worst of all evils is actually middle-posting, where the reply to an individual original point is placed somewhere in the middle of the whole quoted tens-to-hundreds-line original message. I wonder where people come with the idea of formatting their correspondence like this from, it must be taking some effort, hmm... Maciej

On 04/04/2016 02:13 PM, Guy Sotomayor wrote: Well, yes, that's laziness there. All should be trimmed, except the bare minimum needed to understand context; when in a public forum that is viewable after the fact. -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech -http://certification.comptia.org/ --- HDI Certified Support Center Analyst -http://www.ThinkHDI.com/ Registered Linux user number 464583 "Computers have lots of memory but no imagination." "The problem with troubleshooting is that trouble shoots back." - from some guy on the internet.

I came across this: http://www.lastampa.it/2016/03/23/edizioni/biella/alberto-lingegnere-che-sa… which lead me on to http://www.lastampa.it/2015/08/25/edizioni/biella/dai-pc-di-jurassic-park-a… Alberto Rubinelli has a warehouse full of machines (8134 that have been catalogued and maybe 4000 more that are yet to be catalogued). The article mentions a VAX-11/780 and and an "IBM 390", but no pictures of either. There's a Laptop Grid Computer 1520 but it's not quite clear whether it is one that flew on the shuttle or just the same type as one that did. His aim is to have them all running and to open a museum. Antonio -- Antonio Carlini arcarlini at iee.org

Hi Looks like this is his homepage: http://www.retrocomputing.net/ Looks like he has both an 11/780 (though it looks to be in pieces) and a 390. Impressive collection. /P On Tue, Apr 05, 2016 at 10:07:16AM +0100, Antonio Carlini wrote:

On 05/04/16 15:31, Christian Corti wrote: I've never been there so I don't know for sure, but if he just had 10,000 cables he wouldn't really need to have bought a 4000sqm building :-) His online catalogue is obviously incomplete: his prized VAX-11/780 doesn't seem to be there for a start (at least not under the most obvious entries I looked at). Antonio -- Antonio Carlini arcarlini at iee.org

On 04/05/2016 04:31 PM, Christian Corti wrote: Size doesn't matter. I'm more impressed by the fact that he has an inventory, _with_ photos. I'm also impressed by the diversity and some rare items. Perhaps I'm just young and impressionable :-) /P

On 06/04/16 15:38, Dave Wade wrote: I wish I had a 4000sqm building nearby :-) I'm much more likely to (eventually) build up an inventory of the stuff I do have (that's just time and effort ...). Antonio -- Antonio Carlini arcarlini at iee.org

I realize that I have not done much (any) "advertisement" ... I have my collection in a "room" of some 2250 sq. feet (200 m2). Almost all PDP-11 models (UNIBUS and QBUS), a few VAX4000's, VLC4000, and a VAX-11/750. Also several DEC peripherals, disk, tape, printer, and terminals. Furthere, there is a DG NOVA3, NOVA4 and an HP 21MX. All you see on www.pdp-11.nl can be seen in "real", and there is probably a bit more ... I am *not* saying that everything is working, au contraire! After many years of collecting I am now trying to get everything working. A very slow process I've learned! If you are visiting The Netherlands you are welcome to my "Home of Famous Iron". I live in the southern part, near Philips headquarters city Eindhoven. All I ask, if possible, is that I get a business card from you ;-) greetz, - Henk

On Tue, Apr 5, 2016 at 10:38 AM, Henk Gooijen <henk.gooijen at hotmail.com> wrote: Hi Henk, Well, I'm in The Netherlands, but not 'in the southern part' - rather, I'm in Leiden at an academic workshop. Oh well, closer.... I'll see your collection someday! Cheers -- Ian -- Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <http://ischool.uw.edu> Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical Narrative Through a Design Lens Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org> Value Sensitive Design Research Lab <http://vsdesign.org> University of Washington There is an old Vulcan saying: "Only Nixon could go to China."

Emergency Moderation Mode On, topic closed.

----- Original Message ----- From: "Robert Jarratt" <robert.jarratt at ntlworld.com> To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org> Sent: Monday, April 04, 2016 12:44 PM ----- +1 m

----- Original Message ----- From: "Mouse" <mouse at Rodents-Montreal.ORG> To: <cctalk at classiccmp.org> Sent: Sunday, April 03, 2016 9:48 PM Subject: Re: C & undefined behaviour - was Re: tumble under BSD ... >> But I'll be happy to comply to the wishes for preformatted text; just ... --------------------------- Presumably your non-client also uses a monospaced font, since with the proportional fonts in common use today a specific number of characters can vary widely in actual line width, which, I assume, is your issue. But like Chuck I suppose I can eschew the various advances in typography and formatting that I use elsewhere and try to remember to stick to the lowest common denominator here; I will continue to use the spelling checker though, because I find typos and misspellings as in your original post a bit distracting... ;D m

For many web operations, I keep my browser wide across my screen for wide content. Wide wrap makes it hard to read when there is a lot of text. I type returns as I feel comfortable and do not like reading text with arbitrary wrap. Dwight ________________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Chuck Guzis <cclist at sydex.com> Sent: Sunday, April 3, 2016 8:27 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Wrap or not Okay, for the benefit of a very few, I've set my tbird configuration to mailnews_send_plaintext_flowed = false; Since I've got several accounts on this client and this is a *global* composition setting, I'm going to hope that it doesn't mess up composing on my other accounts. I've set the line width to 72 characters. If it does, I'm going back to flowed sent text and you can simply delete my messages when you see them. Of course, there's always the chance that this option won't work at all so If this makes you happy, fine. Otherwise, I'm not willing to do much else. --Chuck

----- Original Message ----- From: "Mouse" <mouse at Rodents-Montreal.ORG> To: <cctalk at classiccmp.org> Sent: Sunday, April 03, 2016 9:32 PM Subject: Re: C & undefined behaviour - was Re: tumble under BSD ------------ I find the opposite; my client wraps just fine, line lengths expanding or contracting according to font and window size; that seems to be the way most folks do it with the infinite range of font, screen and window sizes these days (not to mention top-posting also being the norm 'out there' ;-) On the other hand, when lines are fixed length, with a smaller screen/window or after a few quotes each adding a chevron or two to each line I end up with a hard-to-read text with most lines split into two. m