For your possible amusement ... As I mentioned, the background is that when [Astro Person] (an extremely computer-savvy astrophysicist) tried to build and run some allegedly-portable hunk of [ORG]-written software on the Alpha, it dropped core. So I poked around a bit and then sent him the following: | Date: Thu, 16 Dec 93 08:32:10 EST | From: Mark Bartelt | To: astroperson | Subject: Re: [ORG] [software tools library] | | Well, _that_ was, um, interesting. Basically, the problem is that whoever | wrote this code blissfully ignored something that people have been warning | about for fifteen years: never, NEVER assume that pointers and integers can | be used interchangeably. Unfortunately, there's lots of poorly written code | out there, because this sort of sloppiness didn't produce problems on those | architectures (e.g. VAX, Sun, MIPS) where integers and pointers were in fact | the same size, so people got used to doing it. But on the Alpha it breaks. | | I made a quick-and-dirty fix (sixty-odd changes, actually), mostly changes | of declarations where needed. It also required that an "integer*4" in your | fortran program be changed to "integer*8", which I suspect isn't supported | by the Sun and IRIX compilers. (I haven't tried yet.) Anyway, "[s/w]" now | runs to completion on moose without dumping core. | | The directory /basswood/sysmark/tmp/astro has a current working Alpha version. | Copies of the original stuff are in the "old" subdirectory, in case you want | to diff them. | | (And maybe someone should send a note to whoever wrote this stuff. If it was | an astronomer or astrophysicist, overlooking something like that is probably | understandable. But if it was written by someone purporting to be a software | professional, it's rather unconscionable ...) I didn't actually expect it to go any further, but [Astro] forwarded it to [ORG]'s director, who in turn forwarded it to several other [ORG] people (I seriously doubt that [Astro] expected him to send it verbatim!), and that's when things _really_ hit the fan. [Astro] received a reply saying ... | Date: Fri, 17 Dec 93 10:53:58 PST | From: director@org.somewhere.edu | To: astroperson@cita.utoronto.ca | Subject: Re: off tenderhooks | Cc: director@org.somewhere.edu | | [Astro], | | Your s/w guy certainly hit a nerve with the [ORG] s/w people. | I will pour a little water on the fires here! Sigh. I am glad | [instrument] is up and running. Hopefully we can get lots of | data to feed the hungry maw of your machine. | cheers | [director] ... and with the following appended ... | From: [author] | Subject: Re: [ORG] [software tools library]: [s/w] | To: aa@org.somewhere.edu (aa) | Cc: xxx (Xxx Xxxxxx), director ([ORG] Director), yyy (Yyyy Yyyyyy), | zzzzz (Zzzzz Zzzzzzz) | | Dear Aaa, Dear [Director], | | I am resisting a very strong temptation to cc: the original author on | this. I am extremely offended by the off-hand condemnation that this | work was done in 'blissful ignorance' or any type of 'unconscionable' | disregard for software engineering practice. | | In response to astroperson and sysmark: | | I am terribly sorry that there has been this awful misunderstanding regarding | the portability and usability of the [s/w] on platforms other than | Suns running SunOS prior to version 5.x. [s/w] is intended for first | generation Sun Sparc hardware, it has been ported to several other | hardware platforms and runs with no difficulty *However* it | was written to run on Suns - it is not "64-bit clean", nor is it expected | to run without modification outside of a BSD Unix derived kernel environment. | | The use of 4 byte integers for storing pointers is an inadvisable | practice for a number of reasons, not the least of which is that there | are numerous machines extant that implement hard typing and will not | allow a cast to an inferior type. However, the whole reason this | method was adopted in [s/w] was to make this code accessible to people | who can only write fortran which does not, in the ANSI X3.9-1978 | version, handle indirect addressing without resorting to some sort of | "extension". It is not possible to return a "pointer" to "standard | Fortran-77", and when it was written [s/w] was required to be callable | by "Fortran". | | I hope the above information will find its way back to Mr. Bartelt and | that he will in the future consider that unconventional circumstances | might require deviation from conventional practice when he is making | subjective assessments of other people's work. | | We thank Mr. Bartelt for his astute observations. We found them interesting. | I strongly suggest that in the future [s/w] not be used beyond its intended | application, and that the current application be written using a different | [software tools library]. | | [T. Author] A few years later, in a discussion with a friend re SW, this topic came up for some reason, so I sent him a copy of the above verbiage. I don't think I've got a copy of his reply, but I did send the following to him. And upon rereading it (and what I sent originally), I'm no less convinced than before that the [ORG] gang was guilty of sloppy programming. Nothing in those comments that [Author] made defines any requirement that the code be written the way they did it. It was really more a case of having taken the lazy way out, instead of thinking about portability; there were other ways to have designed this so that the code would be both portable _and_ callable from Fortran; it's not as if their approach (their non-portable approach) was the only way to tackle the lack of pointer variable types in Fortran ... | Perhaps the choice of terms was a bit strong, and I don't know what | claims (if any) were made about portability. But [Astro] certainly | inferred that they thought it would simply be a compile-and-go sort | of thing. | | It's just that their approach stemmed from a failure to give any | thought to the possibility that the code might be ported to some | other architecture. As I recall, it was clear after about ten or | so minutes of thinking, how it should have been done. What they | were doing (if I remember correctly; it's been four years or so) | was to have a Fortran-callable C routine that would do a malloc(), | and return a pointer to the new block of memory. That value was | passed as an int, and then was passed to other C routines later. | What I would have done would be to have an array of pointers (and | have a provision to realloc() space for the array if it got full) | containing the results of the various calls to malloc(), passing | back to the Fortran program the index into the array, rather than | malloc()'s return value. I think if they'd thought much about it | rather than just sitting down and doing it, they'd probably have | come up with a similar approach. And it's that lack of bothering | to think about the problem, rather than the code itself, that set | me off on my mini-tirade. The final postscript to the story came when I knew I'd be interviewing with [ORG], so I mentioned all this to [Ex Postdoc] (formerly at CITA, but then working at [ORG]), with a comment that I hoped that everybody had either forgotten this fuss, or at least had cooled down since then (it _had_ been about four and a half years), or perhaps wouldn't even remember that I was the one who precipitated it. He replied: | [Author] is well known for spinning up and taking everything | personally. His response just puts you into a very big club.