Sigh. This is the response on gcc and `conj.' Terms of
disgust elided, since the sentiments are undoubtedly shared.
Arnold
> Date: 11 Mar 2003 15:07:13 -0000
> To: arnold(a)skeeve.com, gcc-bugs(a)gcc.gnu.org, gcc-prs(a)gcc.gnu.org,
> nobody(a)gcc.gnu.org
> From: bangerth(a)dealii.org
>
> Synopsis: gcc 3.2.2 recognizes complex functions even without complex.h
>
> State-Changed-From-To: open->closed
> State-Changed-By: bangerth
> State-Changed-When: Tue Mar 11 15:07:12 2003
> State-Changed-Why:
> This is a gnu extension. The builtin conj function is switched
> off if you use -ansi or -std=c89.
>
> W.
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&…
Can someone clarify for me how Caldera fits in the picture? I thought
SCO sold Unix to Caldera? It was Caldera that did the BSD-ing of ancient
Unix.
FWIW I too paid $100 for an ancient Unix license, and I've got the System III
stuff that licensees had access to.
Thanks,
Arnold
A working link to the ancient-Unix license exists at
http://shop.caldera.com/caldera/ancient.html
This is a saved link; I didn't investigate how
to find it currently from a Caldera or SCO site.
In case anyone is interested, I retrieved
some fraction of the court papers from
the early 90s USL suit against BSDI and UCB.
The case seems in some ways similar to this
one. They are at
http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/bsdisuit.html
In this one, USL pulled back after an injunction
was denied. By the time the 1993 ruling was issued,
USL was being taken over by Novell.
Dennis
Well, the impression I got from IBM re: AIX and Linux's relationship, was that
they were going to give AIX a Linux makeover so that they could maintain an
apparently unified Un*xish shop - as far as AIX and Linux _are_ Un*ces, that
is!
How that gets interpreted as importing Un*x trade secrets into Linux, I have
no idea.
I also thought IBM was going to allow some of their mainframe high
availability ideas to influence Linux - not through direct porting of the
code - VM/ESA is apparently written in PL/I, and I doubt that most Linux
programmers would touch that with a barge-pole. And a waldo at a workplace
on a planet on the other side of the galaxy. Or universe.
I myself wanted to get some information on the internal structure - ie, the
part that gets passed between the SFS client and the Reusable Kernel Server -
of the VM/ESA Shared File System way back when, and was told in no uncertain
terms, not to bother trying.
I don't see SCO has much chance of doing anything except causing a bit of
unwelcome disruption and - I hope - getting bought out at bargain basement
prices by IBM and getting the entire Un*x source tree BSDed or LGPLed to stop
all this useless nonsense at the "source". Or at the "sauce", to give it a
rather appropriate spin.
Wesley Parish
On Tuesday 11 March 2003 12:45 pm, Greg 'groggy' Lehey wrote:
<snip>
>
> I am very sure that IBM has not put any UNIX code into Linux. For one
> thing, it's not their style, and in fact they keep the AIX and Linux
> people very separate. Last year I wrote a clone of AIX's JFS file
> system on Linux for IBM. This is the old JFS, not the JFS they
> released under GPL. I was not allowed to see the AIX source code, for
> exactly the reasons of the complaint. The only information I had were
> the header files they distribute with the development system.
>
> The AIX code wouldn't have helped, anyway. Linux is not UNIX, as
> anybody who's done kernel programming in both knows. I had thought
> that this childish superstition about the holiness of source code
> would have been stamped out at the end of the last UNIX wars.
>
> Greg
--
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."
DMR remarked:
> So far as I can tell from ISO/IEC 9899:1999,
> the panoply of Complex macros and functions
> are supposed to be enabled only after
>
> #include <complex.h>
>
> gcc looks to be overenthusiastic.
>
> Dennis
I would agree. I plan to file a bug report about it. I built and
checked the latest gcc, and even this file generates the
complaint:
#include <stdio.h>
int conj(a)
int a;
{
return a;
}
main()
{
printf("%d\n", conj(1));
}
Sigh.
Arnold
A thing that has puzzled me almost for ever is why the newline
character in C is 012 and not 015. Does anybody have any insight?
Greg
--
Finger grog(a)lemis.com for PGP public key
See complete headers for address and phone numbers
Lehey wondered,
> A thing that has puzzled me almost for ever is why the newline
> character in C is 012 and not 015. Does anybody have any insight?
And Haerr speculated
> Well, my take on this is that C was developed with UNIX,
> of course, and UNIX early on decided to use a single
> character rather than a two-char (CRLF) sequence for
> end-of-lines...
This came via Unix from Multics. My Multics
Programmers' Manual (1969) says, in reference
to its use of the ASCII character set: "Reference:
USA Standard X3.4-1967," and describes the LF
character, with code octal 012, "New Line.
Move carriage to the left edge of the next
line.... ASCII LF is used for this function."
I believe that either this or some other version
of ASCII standard blessed (or condoned) one
of the interpretations of the 012 character
for the new-line function. However, I haven't
turned up hard evidence of this, despite several
conversations with Eric Fischer, who has
kept track of various versions of the standards.
In the event, various of the terminals used early
on did implement the NL function. E.g. the
IBM 1050 and 2741 terminals (decidedly
non-ASCII) had a new-line function, like
a typewriter, no CR, but sometimes an
"Index" character that moved the paper
but not the printing element. The TTY 37
had an optional interpretation of 012 as
NL. Of course, other terminals required
separate CR and LF characters.
The choice of a single character to separate
lines still seems wise if you're using a byte-stream
model.
Dennis
Norman observed (about conj):
> Since the problem is a new library function that appeared in
> the official header files in C99, it makes sense that newer
> versions of gcc object. That means that as time goes by, newer
> C compilers everywhere will probably pick up the change. Any
> documentation stored next to festoon.c should definitely point
> out the problem and its full generality.
> We'll leave aside for now the question of whether complex
> conjugation really ought to be public.
So far as I can tell from ISO/IEC 9899:1999,
the panoply of Complex macros and functions
are supposed to be enabled only after
#include <complex.h>
gcc looks to be overenthusiastic.
Dennis
Since the problem is a new library function that appeared in
the official header files in C99, it makes sense that newer
versions of gcc object. That means that as time goes by, newer
C compilers everywhere will probably pick up the change. Any
documentation stored next to festoon.c should definitely point
out the problem and its full generality.
We'll leave aside for now the question of whether complex
conjugation really ought to be public.
Norman Wilson
Toronto ON
