From cowan at mercury.ccil.org Mon Aug 1 11:08:46 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 31 Jul 2016 21:08:46 -0400 Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp) In-Reply-To: References: Message-ID: <20160801010846.GA15571@mercury.ccil.org> Rudi Blom scripsit: > To setup the 'infrastructure might be the tricky part. Many years ago > I flew from Montreal to Amsterdam and had two stacks of 5-1/4" > diskettes with me. No papers, confiscated in Amsterdam. I carried an RK05 disk full of proprietary software from West Orange NJ to a client in Kansas City back in 1977. Airport security existed, but it wasn't as anal it is today. So when I told them they couldn't X-ray the disk, it might scramble it, they wanted to do a physical inspection -- but I told them if they opened the disk they'd get dust in it and ruin it. Finally they took my word for it. When the disk got to the client's, it was completely scrambled anyway. I went back home, and next week my partner went out with a stack of 5.25s. It took him twenty hours to set up the client's system (I don't remember if it was a PDP-8 or a PDP-11), but the job got done. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. From rudi.j.blom at gmail.com Mon Aug 1 17:14:34 2016 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Mon, 1 Aug 2016 14:14:34 +0700 Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp) In-Reply-To: <20160801010846.GA15571@mercury.ccil.org> References: <20160801010846.GA15571@mercury.ccil.org> Message-ID: My 'incident' was around 1985 if I remember correctly. A time people and border guards started to realise the possible value of what was on such funny things like diskettes. Also I crossed 'National' borders. Now that can be tricky even today :-) On 01/08/2016, John Cowan wrote: > > I carried an RK05 disk full of proprietary software from West Orange NJ > to a client in Kansas City back in 1977. Airport security existed, but > it wasn't as anal it is today. So when I told them they couldn't X-ray > the disk, it might scramble it, they wanted to do a physical inspection -- > but I told them if they opened the disk they'd get dust in it and ruin it. > Finally they took my word for it. > > When the disk got to the client's, it was completely scrambled anyway. > I went back home, and next week my partner went out with a stack of 5.25s. > It took him twenty hours to set up the client's system (I don't remember > if it was a PDP-8 or a PDP-11), but the job got done. > From dot at dotat.at Mon Aug 1 21:36:35 2016 From: dot at dotat.at (Tony Finch) Date: Mon, 1 Aug 2016 12:36:35 +0100 Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp) In-Reply-To: References: <579959F6.3050803@gmail.com> <20160728112330.GP3375@yeono.kjorling.se> <20160728135739.GA14303@mercury.ccil.org> <20160730075641.GT78278@eureka.lemis.com> Message-ID: William Cheswick wrote: > > I was astonished to learn that one of those pinky-sized micro-SD cards > has 33 circuit boards in it, stacked in a staggered formation. 32 have > memory, one a fairly powerful CPU. I don't think they have what I would call a circuit board inside: the microSD card is itself a multi-chip package. http://www.bunniestudios.com/blog/?page_id=1022 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: North or northwest 4 or 5, increasing 6 at times. Slight or moderate. Fair. Good. From scj at yaccman.com Tue Aug 2 03:11:26 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Mon, 1 Aug 2016 10:11:26 -0700 Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp) In-Reply-To: References: <20160801010846.GA15571@mercury.ccil.org> Message-ID: <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com> > My 'incident' was around 1985 if I remember correctly. A time people > and border guards started to realise the possible value of what was on > such funny things like diskettes. Also I crossed 'National' borders. > Now that can be tricky even today :-) > A Canadian friend of mine, after working in the US for five or so years, was returning to Canada about 1969 with five years of research in 20 or 30 boxes of punched cards in the back of his car. He was stopped at the border and told that he would have to pay duty on the card boxes -- I think the total came to over $200. He argued with them for some time, and finally one of the agents opened one of the boxes and said "Oh! These are USED punch cards! There is no duty." From clemc at ccc.com Tue Aug 2 04:32:56 2016 From: clemc at ccc.com (Clem Cole) Date: Mon, 1 Aug 2016 14:32:56 -0400 Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp) In-Reply-To: <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com> References: <20160801010846.GA15571@mercury.ccil.org> <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com> Message-ID: On Mon, Aug 1, 2016 at 1:11 PM, wrote: > "Oh! These are > ​ ​ > USED punch cards! There is no duty." > > ​For a long time, Canada was trying to tax software going over the border, as well as some equipment. When Kelly Booth was at Waterloo, he had 5 1/2" tapes with special stamps from the Canadian Gov he had to use to carry things after having had tapes confiscated. The funny part was you could physically mail the tape, but if you tried to bring them personally; it was an issue. Kelly told me if they have been unopened and new it would not have been an issue - but it was that it they were used that tended cause issues. I also remember getting a system ready for the Toronto USENIX. It was amazing the paper we needed, and had to prove we were not going to sell the system there etc. Clem Clem The problem was putting a value on things. So they were marked as research data IIRC, which -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Aug 3 08:38:58 2016 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 3 Aug 2016 08:38:58 +1000 (EST) Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp) In-Reply-To: <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com> References: <20160801010846.GA15571@mercury.ccil.org> <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com> Message-ID: On Mon, 1 Aug 2016, scj at yaccman.com wrote: > A Canadian friend of mine, after working in the US for five or so years, > was returning to Canada about 1969 with five years of research in 20 or 30 > boxes of punched cards in the back of his car. He was stopped at the > border and told that he would have to pay duty on the card boxes -- I > think the total came to over $200. He argued with them for some time, and > finally one of the agents opened one of the boxes and said "Oh! These are > USED punch cards! There is no duty." Not Henry Spencer, perchance? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From norman at oclsc.org Wed Aug 3 21:53:03 2016 From: norman at oclsc.org (Norman Wilson) Date: Wed, 03 Aug 2016 07:53:03 -0400 Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp) Message-ID: <1470225188.15544.for-standards-violators@oclsc.org> Dave Horsfall: Not Henry Spencer, perchance? ===== Since the Canadian in question had been working in the US since 1964 or so, he must by now be pushing 70 years old. I haven't seen Henry for some years, but I don't think he has aged that much. Norman Wilson Toronto ON From random832 at fastmail.com Sun Aug 14 13:37:03 2016 From: random832 at fastmail.com (Random832) Date: Sat, 13 Aug 2016 23:37:03 -0400 Subject: [TUHS] Help with a Unix-ish project? In-Reply-To: <20160716014449.GA9414@minnie.tuhs.org> References: <20160715225617.GB30146@minnie.tuhs.org> <1468632762.1363402.667765737.350D807F@webmail.messagingengine.com> <20160716014449.GA9414@minnie.tuhs.org> Message-ID: <1471145823.1118263.694671257.09B04CBD@webmail.messagingengine.com> On Fri, Jul 15, 2016, at 21:44, Warren Toomey wrote: > I don't want to use this list as the discussion area for the project. > I'll set another one up and we can move the conversation there. Did this ever materialize? From wkt at tuhs.org Mon Aug 15 10:11:40 2016 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 15 Aug 2016 10:11:40 +1000 Subject: [TUHS] fstat(2) on pipes? Message-ID: <20160815001140.GA16138@minnie.tuhs.org> All, sorry this is slightly off-topic. I'm trying to find out what fstat(2) returns when the file descriptor is a pipe. The POSIX/Open Group documentation doesn't really specify what should be returned. Does anybody have any pointers? Thanks, Warren P.S. Why? xv6 has fstat() but returns an error if the file descriptor isn't associated with an i-node. I'm trying to work out if/how to fix it. From dave at horsfall.org Mon Aug 15 10:41:02 2016 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 15 Aug 2016 10:41:02 +1000 (EST) Subject: [TUHS] fstat(2) on pipes? In-Reply-To: <20160815001140.GA16138@minnie.tuhs.org> References: <20160815001140.GA16138@minnie.tuhs.org> Message-ID: On Mon, 15 Aug 2016, Warren Toomey wrote: > All, sorry this is slightly off-topic. I'm trying to find out what > fstat(2) returns when the file descriptor is a pipe. The POSIX/Open > Group documentation doesn't really specify what should be returned. Does > anybody have any pointers? I always thought it was undefined, but my Mac says: BUGS Applying fstat to a socket (and thus to a pipe) returns a zero'd buffer, except for the blocksize field, and a unique device and inode number. And my FreeBSD box is the same; I haven't checked my Penguins. > P.S. Why? xv6 has fstat() but returns an error if the file descriptor > isn't associated with an i-node. I'm trying to work out if/how to fix > it. Probably not much use to you, but back in Ed6 I did modify it to return the amount of data in the pipe. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jnc at mercury.lcs.mit.edu Mon Aug 15 10:27:11 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 14 Aug 2016 20:27:11 -0400 (EDT) Subject: [TUHS] fstat(2) on pipes? Message-ID: <20160815002711.3F3C418C096@mercury.lcs.mit.edu> > From: Warren Toomey > I'm trying to find out what fstat(2) returns when the file descriptor > is a pipe. In V6, it returns information about the file (inode) used as a temporary storage area for data which has been written into the pipe, but not yet read; i.e. it's an un-named file with a length which varies between 0 and 4KB. > xv6 has fstat() but returns an error if the file descriptor isn't > associated with an i-node. ?? All pipe file descriptors should have an inode? Noel From wkt at tuhs.org Mon Aug 15 10:54:52 2016 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 15 Aug 2016 10:54:52 +1000 Subject: [TUHS] fstat(2) on pipes? In-Reply-To: References: <20160815001140.GA16138@minnie.tuhs.org> Message-ID: <20160815005452.GA21951@minnie.tuhs.org> On Mon, Aug 15, 2016 at 10:41:02AM +1000, Dave Horsfall wrote: > Probably not much use to you, but back in Ed6 I did modify it to return > the amount of data in the pipe. 7th Ed seems to return the amount of free space in the pipe, if I read the code correctly: fstat() { ... /* Call stat1() with the current offset in the pipe */ stat1(fp->f_inode, uap->sb, fp->f_flag&FPIPE? fp->f_un.f_offset: 0); } stat1() { ... ds.st_size = ip->i_size - pipeadj; } Cheers, Warren From wkt at tuhs.org Mon Aug 15 10:59:04 2016 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 15 Aug 2016 10:59:04 +1000 Subject: [TUHS] fstat(2) on pipes? In-Reply-To: <20160815002711.3F3C418C096@mercury.lcs.mit.edu> References: <20160815002711.3F3C418C096@mercury.lcs.mit.edu> Message-ID: <20160815005904.GB21951@minnie.tuhs.org> Warren wrote: > > xv6 has fstat() but returns an error if the file descriptor isn't > > associated with an i-node. On Sun, Aug 14, 2016 at 08:27:11PM -0400, Noel Chiappa wrote: > ?? All pipe file descriptors should have an inode? xv6 is a Unix-like OS written for teaching purposes. I'm making changes to give it a decent runtime environment. URLs: https://pdos.csail.mit.edu/6.828/2014/xv6.html https://github.com/DoctorWkt/xv6-freebsd and it comes with it's own Lions-style commentary: https://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf Cheers, Warren From jnc at mercury.lcs.mit.edu Tue Aug 16 00:04:50 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 15 Aug 2016 10:04:50 -0400 (EDT) Subject: [TUHS] fstat(2) on pipes? Message-ID: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu> > From: Warren Toomey > xv6 is a Unix-like OS written for teaching purposes. I'm fairly well-aware of Xv6; I too am planning to use it in a project. But back to the original topic, it sounds like there's a huge amount of variance in the semantics of doing fstat() on a pipe. V6 doesn't special-case it in any way, but it sounds as if other systems do. What V6 does (to complete the list) is grow the temporary file being used to buffer the pipe contents up to a certain maximum size, whereupon it halts the writer, and waits for the reader to catch up - at which point it truncates the file, and adjusts the read and write pointers back to 0. So fstat() on V6, which doesn't special-case pipes in any way for fstat(), apparently returns 'waiting_to_be_read' plus 'already_read'. >>> xv6 has fstat() but returns an error if the file descriptor isn't >>> associated with an i-node. >> ?? All pipe file descriptors should have an inode? To answer my own question, after a quick look at the Xv6 sources (on my desktop ;-); it turns out that Xv6 handles pipes completely differently; instead of borrowing an inode, they have special 'pipe' structures. Hence the error return in fstat() on Xv6. (That difference also limits the amount of buffered data in a pipe to 512 bytes. So don't expect high throughput from a pipe on Xv6! :-) So I guess you get to pick which semantics you want fstat() on a pipe to have there: V6's, V7's (see below), or something else! :-) > 7th Ed seems to return the amount of free space in the pipe, if I read > the code correctly: I'm not sure of that (see below), but I think it would make more sense to return the amount of un-read data (which is what I think it does do), as the closest semantics to fstat() on a file. It might also make sense to return the amount of free space (to a writer), and the amount of data available to read (to a reader), since those are the numbers users will care about. (Although then fstat() on the write side of a pipe will have semantics which are inconsistent with fstat() on files. And if the user code knows the maximum amount of buffering in a pipe, it could work out the available write space from that, and the amount currently un-read.) > fstat() > { > ... > /* Call stat1() with the current offset in the pipe */ > stat1(fp->f_inode, uap->sb, fp->f_flag&FPIPE? fp->f_un.f_offset: 0); > } > stat1() > { > ... > ds.st_size = ip->i_size - pipeadj; I'm too lazy to go read the code (even though I already have it :-), but V7 seems to usually be very similar to V6. So, what I suspect this code does is pass the expression: ((fp->f_flag & FPIPE) ? fp->f_un.f_offset : 0) as 'pipeadj' (to account for the amount that's already been read), and then returns (ip->i_size - pipeadj), i.e. the amount remaining un-read, as the size. Noel From random832 at fastmail.com Tue Aug 16 01:14:45 2016 From: random832 at fastmail.com (Random832) Date: Mon, 15 Aug 2016 11:14:45 -0400 Subject: [TUHS] fstat(2) on pipes? In-Reply-To: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu> References: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu> Message-ID: <1471274085.1099635.695741217.6472725F@webmail.messagingengine.com> On Mon, Aug 15, 2016, at 10:04, Noel Chiappa wrote: > But back to the original topic, it sounds like there's a huge amount > of variance in the semantics of doing fstat() on a pipe. V6 doesn't > special-case it in any way, but it sounds as if other systems do. I expect that the single important thing, the only thing that most applications will rely on, is it returning successfully and indicating that the file type is fifo. If your version of xv6 supports file permissions and if pipes are one-way it may be worthwhile to indicate which end of the pipe it is. In the standard: the use of the size field is explicitly unspecified for pipes - for any file type other than regular files, symbolic links, and shared/typed memory objects. Other than that, it's clear from the standard that it's intended to succeed and report a sensible file type for non-filesystem objects like pipes, shared memory objects, and sockets. However, there's no discussion of what, if anything, belongs in the dev/inode*, permissions, nlink, and timestamps. On Linux: st_dev is a device number specific to pipes and st_ino is a unique inode number. I haven't tested the timestamps thoroughly (my test only covered instantaneously opening and statting a pipe), but they are valid timestamps rather than being 0 or -1 or some garbage value. st_uid/gid are [probably, haven't tested complicated cases] the user that created it, st_nlink is 1, and the permissions are set to [user-only] the read or write mode the pipe is opened in. *Though, the standard's light on the meaning of device identifiers in the first place, and what it does say could easily be read as demanding a unique device/inode pair regardless of the nonexistence of a physical device, which naturally leads to the solution that I observed on Linux and that someone else mentioned on OSX. From michael at kjorling.se Tue Aug 16 02:56:45 2016 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 15 Aug 2016 16:56:45 +0000 Subject: [TUHS] fstat(2) on pipes? In-Reply-To: <1471274085.1099635.695741217.6472725F@webmail.messagingengine.com> References: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu> <1471274085.1099635.695741217.6472725F@webmail.messagingengine.com> Message-ID: <20160815165645.GE655@yeono.kjorling.se> On 15 Aug 2016 11:14 -0400, from random832 at fastmail.com (Random832): > On Mon, Aug 15, 2016, at 10:04, Noel Chiappa wrote: >> But back to the original topic, it sounds like there's a huge amount >> of variance in the semantics of doing fstat() on a pipe. V6 doesn't >> special-case it in any way, but it sounds as if other systems do. > > I expect that the single important thing, the only thing that most > applications will rely on, is it returning successfully and indicating > that the file type is fifo. On Linux/glibc, based on the fstat(2) man page, it looks like the size field is undefined for a FIFO: > The st_size field gives the size of the file (if it is a regular > file or a symbolic link) in bytes. The size of a symbolic link is > the length of the pathname it contains, without a terminating null > byte. The mode field is used to hold the type of file: > The following POSIX macros are defined to check the file type using > the st_mode field: > > ... > S_ISFIFO(m) FIFO (named pipe)? > ... > > The following flags are defined for the st_mode field: > ... > S_IFIFO 0010000 FIFO > ... The above from Debian Wheezy. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From norman at oclsc.org Tue Aug 16 03:47:03 2016 From: norman at oclsc.org (Norman Wilson) Date: Mon, 15 Aug 2016 13:47:03 -0400 Subject: [TUHS] fstat(2) on pipes? Message-ID: <1471283229.3510.for-standards-violators@oclsc.org> I remember once, long ago--probably in the early 1980s--writing a program that expected fstat on a pipe to return the amount of data buffered in the pipe. It worked on the system on which I wrote the code. Then I tried it on another, related but different UNIX, and it didn't work. So if POSIX/SUS don't prescribe a standard, I don't think one should pretend there is one, and (as I learned back then) it's unwise to depend on the result, except I think it's fair not to expect fstat to fail on any valid file descriptor. I'm pretty sure that in 7/e and earlier, fstat on a pipe reported a regular file with zero links. There was a reason for this: the kernel in fact allocated an i-node from a designated pipe device (pipedev) file system, usually the root. So the excuse that `there's no i-node' was just wrong. In last-generation Research systems, when pipes were streams (and en passant became full duplex, which caused no trouble at all but simplified life elsewhere--I think I was the one who realized that meant we didn't need pseudo-ttys any more), the system allocated a pair of in-core i-nodes when a pipe was created. As long as such an i-node cannot be accidentally confused with one belonging to any disk file system, this causes no trouble at all, and since it is possible to have more than one disk file system this is trivially possible just by reserving a device number. (In fact by then our in-core i-nodes were marked with a file system type as well, and pipes just became their own file system.) stat always returned size 0 for (Research) stream pipes, partly because nobody cared enough, partly because the implementation of streams didn't keep an exact count of all the buffered data all along the stream, just a rough one sufficient for flow control. Besides, with a full-duplex pipe, which direction's data should be counted? Returning to the original question, I'd suggest that: -- fstat(fd) where fd is a pipe should succeed -- the file should be reported to have zero links, since that is the case for a pipe (unless a named pipe, but if you support those you probably have something else to stat anyway) -- the file type should be IFIFO if that type exists in xv6 (which it wouldn't were it a real emulation of 6/e, but I gather that's not the goal), IFREG otherwise -- permissions probably don't matter much, but for sanity's sake should be some reasonable constant. Norman Wilson Toronto ON From clemc at ccc.com Tue Aug 16 03:53:28 2016 From: clemc at ccc.com (Clem Cole) Date: Mon, 15 Aug 2016 13:53:28 -0400 Subject: [TUHS] fstat(2) on pipes? In-Reply-To: <20160815001140.GA16138@minnie.tuhs.org> References: <20160815001140.GA16138@minnie.tuhs.org> Message-ID: ​Yet Another Example of UNIX A != UNIX B​ IIRC from the /usr/group and later POSIX discussions, the only thing that is for sure on the stat structure with a PIPE is that it's marked as such. That said, I just grabbed my copy of the SVID (Vol 1 pages 126-127) st_size "For ordinary files, this field is the address of the end of file. For pipes and FIFO's, this field is the count of the data currently in the file. For block-special & char special, this field is undefined." As for st_ino and st_dev -- the SVID says the ino "uniquely identifies the file in a given file system," and dev uniquely identifies the file system that contains the file." It further states: "The pair of fields st_ino and st_dev uniquely identifies ordinary files." And then later says "No other significance is associated with this value." So..... clearly returning an error is wrong. I don't think the Linux scheme hurts anything.... On Sun, Aug 14, 2016 at 8:11 PM, Warren Toomey wrote: > All, sorry this is slightly off-topic. I'm trying to > find out what fstat(2) returns when the file descriptor > is a pipe. The POSIX/Open Group documentation doesn't > really specify what should be returned. Does anybody have > any pointers? > > Thanks, Warren > > P.S. Why? xv6 has fstat() but returns an error if the > file descriptor isn't associated with an i-node. I'm > trying to work out if/how to fix it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Aug 29 04:21:46 2016 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 29 Aug 2016 04:21:46 +1000 (EST) Subject: [TUHS] Comments on "C" Message-ID: Seen on another list... And I got quoted by Steve Bellovin :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ---------- Forwarded message ---------- From: Kent Borg To: cryptography at metzdowd.com Subject: Re: [Cryptography] "NSA-linked Cisco exploit poses bigger threat than previously thought" On 08/25/2016 06:06 PM, Steven M. Bellovin wrote: > I first heard more or less that line from Doug McIlroy himself; he > called C the best assembler language he'd ever used. Ancient fun-fact: Years ago there was an article in Byte magazine describing how a useful subset of C could be directly assembled into 68000 code. Not compiled, assembled. C is a stunning assembly language. When those wild-eyed nerds at AT&T decided to write Unix not in assembly but in C (where was management!?), it was radical. But C was up to (down to?) the task, it was pioneering then and is still doing useful things decades later: From the fastest supercomputers to some pretty slim microcontrollers (plus a hell of a lot of Android devices) multitudes of computers run a Linux kernel compiled from the *same* C source code, with almost no assembly. Big-endian, little-endian: no matter. Different word lengths: no matter. That is one impressive cross-platform assembly language! Unfortunately, C is also a dangerous language that mortal programmers cannot reliably wield. -kb, the Kent who knows he is pressing his luck on a moderated cryptography mailing list, but C deserves a lot of respect, as it also deserves to be efficiently sent into a dignified retirement. _______________________________________________ The cryptography mailing list cryptography at metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography From rochkind at basepath.com Mon Aug 29 10:37:21 2016 From: rochkind at basepath.com (Marc Rochkind) Date: Sun, 28 Aug 2016 18:37:21 -0600 Subject: [TUHS] Comments on "C" In-Reply-To: References: Message-ID: Yeah, OK, another one of those clever glib UNIXy aphorisms. But, as anyone who's actually programmed seriously in assembly language knows, C is not assembler. It is a system programming language low enough to be used for things that were once done in assembler, the most important of which is an OS. So, for most of us, we no longer had to write in assembler. But that doesn't mean C is assembler. So, are we just having fun over a few beers, or talking seriously? I like both! --Marc Rochkind On Sun, Aug 28, 2016 at 12:21 PM, Dave Horsfall wrote: > Seen on another list... And I got quoted by Steve Bellovin :-) > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > > ---------- Forwarded message ---------- > From: Kent Borg > To: cryptography at metzdowd.com > Subject: Re: [Cryptography] > "NSA-linked Cisco exploit poses bigger threat than previously thought" > > On 08/25/2016 06:06 PM, Steven M. Bellovin wrote: > > > I first heard more or less that line from Doug McIlroy himself; he > > called C the best assembler language he'd ever used. > > Ancient fun-fact: Years ago there was an article in Byte magazine > describing how a useful subset of C could be directly assembled into 68000 > code. Not compiled, assembled. > > C is a stunning assembly language. When those wild-eyed nerds at AT&T > decided to write Unix not in assembly but in C (where was management!?), > it was radical. But C was up to (down to?) the task, it was pioneering > then and is still doing useful things decades later: From the fastest > supercomputers to some pretty slim microcontrollers (plus a hell of a lot > of Android devices) multitudes of computers run a Linux kernel compiled > from the *same* C source code, with almost no assembly. Big-endian, > little-endian: no matter. Different word lengths: no matter. > > That is one impressive cross-platform assembly language! > > Unfortunately, C is also a dangerous language that mortal programmers > cannot reliably wield. > > -kb, the Kent who knows he is pressing his luck on a moderated > cryptography mailing list, but C deserves a lot of respect, as it also > deserves to be efficiently sent into a dignified retirement. > > _______________________________________________ > The cryptography mailing list > cryptography at metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Aug 29 10:42:37 2016 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 28 Aug 2016 17:42:37 -0700 Subject: [TUHS] Comments on "C" In-Reply-To: References: Message-ID: <20160829004237.GC14366@mcvoy.com> I'm with Marc. I think the C syntax is really pleasant, and while I enjoyed writing PDP-11 assembler (by far my favorite out the ones I've done which include VAX, m68k, 32032, z80, sparc, some x86 but not much), I don't want go back to writing assembler unless I have to. C is a pleasant language that easily compiles to assembler. I happen to like it so much I made a scripting language that looks very C like, with some perl pleasantness tossed in (without all the dollar signs). Check it out at http://www.little-lang.org 100% open source, actively developed, yada, yada. On Sun, Aug 28, 2016 at 06:37:21PM -0600, Marc Rochkind wrote: > Yeah, OK, another one of those clever glib UNIXy aphorisms. > > But, as anyone who's actually programmed seriously in assembly language > knows, C is not assembler. It is a system programming language low enough > to be used for things that were once done in assembler, the most important > of which is an OS. > > So, for most of us, we no longer had to write in assembler. But that > doesn't mean C is assembler. > > So, are we just having fun over a few beers, or talking seriously? I like > both! > > --Marc Rochkind > > On Sun, Aug 28, 2016 at 12:21 PM, Dave Horsfall wrote: > > > Seen on another list... And I got quoted by Steve Bellovin :-) > > > > -- > > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > > suffer." > > > > ---------- Forwarded message ---------- > > From: Kent Borg > > To: cryptography at metzdowd.com > > Subject: Re: [Cryptography] > > "NSA-linked Cisco exploit poses bigger threat than previously thought" > > > > On 08/25/2016 06:06 PM, Steven M. Bellovin wrote: > > > > > I first heard more or less that line from Doug McIlroy himself; he > > > called C the best assembler language he'd ever used. > > > > Ancient fun-fact: Years ago there was an article in Byte magazine > > describing how a useful subset of C could be directly assembled into 68000 > > code. Not compiled, assembled. > > > > C is a stunning assembly language. When those wild-eyed nerds at AT&T > > decided to write Unix not in assembly but in C (where was management!?), > > it was radical. But C was up to (down to?) the task, it was pioneering > > then and is still doing useful things decades later: From the fastest > > supercomputers to some pretty slim microcontrollers (plus a hell of a lot > > of Android devices) multitudes of computers run a Linux kernel compiled > > from the *same* C source code, with almost no assembly. Big-endian, > > little-endian: no matter. Different word lengths: no matter. > > > > That is one impressive cross-platform assembly language! > > > > Unfortunately, C is also a dangerous language that mortal programmers > > cannot reliably wield. > > > > -kb, the Kent who knows he is pressing his luck on a moderated > > cryptography mailing list, but C deserves a lot of respect, as it also > > deserves to be efficiently sent into a dignified retirement. > > > > _______________________________________________ > > The cryptography mailing list > > cryptography at metzdowd.com > > http://www.metzdowd.com/mailman/listinfo/cryptography > > > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From usotsuki at buric.co Mon Aug 29 11:54:43 2016 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 28 Aug 2016 21:54:43 -0400 (EDT) Subject: [TUHS] Comments on "C" In-Reply-To: <20160829004237.GC14366@mcvoy.com> References: <20160829004237.GC14366@mcvoy.com> Message-ID: On Sun, 28 Aug 2016, Larry McVoy wrote: > I'm with Marc. I think the C syntax is really pleasant, and while I enjoyed > writing PDP-11 assembler (by far my favorite out the ones I've done which > include VAX, m68k, 32032, z80, sparc, some x86 but not much), I don't want > go back to writing assembler unless I have to. C is a pleasant language > that easily compiles to assembler. Yeah, C's a really nice language. About as high as Pascal and at the same time almost as low as ASM. It's just a pity it's a horrible fit on the 6502 (my usual CPU of choice). -uso. From grog at lemis.com Mon Aug 29 13:16:19 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 29 Aug 2016 13:16:19 +1000 Subject: [TUHS] Comments on "C" In-Reply-To: References: Message-ID: <20160829031619.GB48170@eureka.lemis.com> On Sunday, 28 August 2016 at 18:37:21 -0600, Marc Rochkind wrote: > Yeah, OK, another one of those clever glib UNIXy aphorisms. > > But, as anyone who's actually programmed seriously in assembly language > knows, C is not assembler. It is a system programming language low enough > to be used for things that were once done in assembler, the most important > of which is an OS. Agreed, calling assembler is being deliberately a little silly. But there is a connection: when I write C, I can envision what code is going to be produced. With many languages, including C++, you can't be so sure. "A LISP programmer knows the value of everything and the cost of nothing". > So, are we just having fun over a few beers, or talking seriously? I > like both! I'll go for the beer. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From beebe at math.utah.edu Tue Aug 30 10:22:11 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 29 Aug 2016 18:22:11 -0600 Subject: [TUHS] [tuhs] the origins of fork and join Message-ID: The latest issue of the IEEE Annals of Computing was published electronically today, and it has an article that I expect many TUHS list readers will enjoy reading: Notes on the History of Fork and Join http://dx.doi.org/10.1109/MAHC.2016.34 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From rochkind at basepath.com Tue Aug 30 12:52:08 2016 From: rochkind at basepath.com (Marc Rochkind) Date: Mon, 29 Aug 2016 20:52:08 -0600 Subject: [TUHS] [tuhs] the origins of fork and join In-Reply-To: References: Message-ID: Thanks! Nice to be reminded that there was a time when everything had to be figured out. Even now, of course. On Monday, August 29, 2016, Nelson H. F. Beebe wrote: > The latest issue of the IEEE Annals of Computing was published > electronically today, and it has an article that I expect many > TUHS list readers will enjoy reading: > > Notes on the History of Fork and Join > http://dx.doi.org/10.1109/MAHC.2016.34 > > ------------------------------------------------------------ > ------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 > - > - University of Utah FAX: +1 801 581 4148 > - > - Department of Mathematics, 110 LCB Internet e-mail: > beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~ > beebe/ - > ------------------------------------------------------------ > ------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Wed Aug 31 20:02:28 2016 From: tfb at tfeb.org (Tim Bradshaw) Date: Wed, 31 Aug 2016 11:02:28 +0100 Subject: [TUHS] Comments on "C" In-Reply-To: <20160829031619.GB48170@eureka.lemis.com> References: <20160829031619.GB48170@eureka.lemis.com> Message-ID: <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org> On 29 Aug 2016, at 04:16, Greg 'groggy' Lehey wrote: > "A LISP programmer knows the value of everything and the cost of > nothing". A C programmer knows the cost of all sufficiently simple things and the value of nothing. No significant programs written since 1980 have been sufficiently simple. (This isn't meant as a hostile comment!) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cowan at ccil.org Wed Aug 31 22:59:32 2016 From: cowan at ccil.org (John Cowan) Date: Wed, 31 Aug 2016 08:59:32 -0400 Subject: [TUHS] Comments on "C" In-Reply-To: <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org> References: <20160829031619.GB48170@eureka.lemis.com> <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org> Message-ID: On Wed, Aug 31, 2016 at 6:02 AM, Tim Bradshaw wrote: A C programmer knows the cost of all sufficiently simple things and the > value of nothing The value of nothing is 0, or on unusual architectures, (void *)0. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Aug 31 23:32:10 2016 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 31 Aug 2016 09:32:10 -0400 Subject: [TUHS] Comments on "C" In-Reply-To: References: <20160829031619.GB48170@eureka.lemis.com> <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org> Message-ID: <01a901d2038c$157e4ff0$407aefd0$@ronnatalie.com> > The value of nothing is 0, or on unusual architectures, (void *)0. T null pointer constant does not need a cast on ANY architecture . -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantleycoile at me.com Wed Aug 31 23:57:45 2016 From: brantleycoile at me.com (Brantley Coile) Date: Wed, 31 Aug 2016 09:57:45 -0400 Subject: [TUHS] Comments on "C" In-Reply-To: References: Message-ID: > On Aug 28, 2016, at 8:37 PM, Marc Rochkind wrote: > > But, as anyone who's actually programmed seriously in assembly language knows, C is not assembler. It is a system programming language low enough to be used for things that were once done in assembler, the most important of which is an OS. > > So, for most of us, we no longer had to write in assembler. But that doesn't mean C is assembler. > Interestingly, assembler seems to be making a come back if one gives any credence to the Tiobe index. http://www.tiobe.com/tiobe-index/ As one who has written a lot of assembler code and no small number of assemblers, I wouldn’t like to write in assembler again. The problem is the lack of redundancy to catch errors. As you all know (preaching to the choir here) the semantic model for C is the common von Neumann architecture. With the exceptions of returning structures, the semantics map one to one with most machines. This means that I can write C code and know pretty well what instructions are going to be generated. This in turn means that I can use C for almost all cases where I would have had to use assembler. The great Niklaus Wirth demonstrated this with his Oberon and some other small languages that completely replaced the use of assembler in his systems. Some modern compliers have broken this, however. I have never been able to figure out what clang is going to do. But I should expect 28,000,000 bytes of instructions to do weird things. There’s no reason a C compiler should ever be more than about 0.25 MB of text. Brantley Coile