Linux-Development-Sys Digest #965, Volume #6 Thu, 15 Jul 99 23:13:45 EDT
Contents:
Newbie Needs Help on Port-Specifically User Interfaces ([EMAIL PROTECTED])
Re: Why we are still holding on to X Windows (Michel Bardiaux)
Re: OLE in Linux? (Peter Allen)
Re: DMA from/to user space? (Clark Williams)
Re: New OS development (Philip Brown)
Re: The opportunities that I would like to see Linux address. [Not that anyone
reads these things] - rather long (Ashley Penney)
Re: when will Linux support > 2GB file size??? (Greg Yantz)
Re: Why we are still holding on to X Windows (Philip Brown)
Re: when will Linux support > 2GB file size??? ("kryliss")
request for help w/TCP analysis app (Ed Macke)
Re: ioctl() / security (Tony Saba)
Re: OLE in Linux? (Christopher Browne)
Re: Bug of GCC (Ulrich Drepper)
Re: Network stack rewrite (Lew Pitcher)
Bug of GCC ("Cute Panda")
Re: Kernel version 2.3.9+ (Peter Samuelson)
Re: Package manager as a VFS (Peter Samuelson)
Re: Kernel version 2.3.9+ (Peter Samuelson)
Re: Bug of GCC (Scott Lanning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Newbie Needs Help on Port-Specifically User Interfaces
Date: Thu, 15 Jul 1999 17:32:51 GMT
I am attempting to port an DOS controls system to
Linux. Currently, I have a text-mode user
interface-it has text and color that I have to
emulate. I have started reading docs on NCURSES,
and XTERM, but I do not know all the different
interfaces (visual, user) for Linux.
I need:
1. a list of available user interfaces with the
capability to write colored text to a x,y location
on the window (be it X window or a terminal
window).
2. Which of the above is the most 'standard' for
Unix in general.
3. A specific example of how this is done - a
'Hello World' type of example- what libraries I
will need, etc.
I am using a Red Hat 5.2 distribution with GCC
2.7.2.3, I have ncurese 4.2-10 installed according
to RPM.
Any help would be GREATLY appreciated.
Thanks-Doug Springer
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Michel Bardiaux <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Thu, 15 Jul 1999 20:03:33 +0200
mlw wrote:
>
> Michael Gu wrote:
>
> >If Microsoft is a monopoly, X Windows acts more like a monopoly in the
> >Unix world.
> >
> >Let's face it. X Windows is a really premitive base for modern GUI,
> >terrible font support breaks GUI all the time, no sound capability, ....
> >If Linux is going to desktops to compete with Microsoft, it got to come
> >up with something much better then X.
> >
> >So, why don't we drop the X and innovate?
>
> You are joking right?
>
> X is at least 5 to 10 years ahead of anything Microsoft has going. They
> are working like crazy to get terminal server and Citrix to be reliable.
> We have what they are trying to do already.
>
> With X, I can run a program anywhere on any machine, Windows can't touch
> that.
>
> As for fonts, yes, some tweaking needs to be done, but, that does not
> demand dropping X.
Much more than tweaking. IIRC there is absolutely no way for the *client
app*
to supply a font, fonts have to be installed on a font server.
>
> As for Audio, what the hell does a GUI have to do with audio? Yes, Linux
> needs a standard networked streaming audio spec, but that is not "X."
>
For any 'animated' app, one needs to synchronize both audio and video
with
some 'beat'. I dunno what audio servers like NAS do in that area, but
there is
no way with X11R6.3 to send eg a Pixmap copy command to the server with
the
provisio that it has to be done at time so-and-so. Admittedly, that is
no small problem,
since an X server can have many clients, and which one will be the
'authority'
on time?
Greetings
--
Michel Bardiaux
UsrConsult S.P.R.L. Rue Margot, 37 B-1457 Nil St Vincent
Tel : +32 10 65.44.15 Fax : +32 10 65.44.10
------------------------------
From: Peter Allen <[EMAIL PROTECTED]>
Subject: Re: OLE in Linux?
Date: Thu, 15 Jul 1999 20:10:07 +0100
Igor Zlatkovic wrote:
>
> Habin wrote:
>
> > Hello,
> >
> > I've studied OLE (Object Linking and Embedding) programming under
> > Windows 95 using VC++ 5.0. The OLE has many functions and Windows 95
> > support it as system level.
> >
> > I'm interesting about OLE in Linux.
> >
> > Is there any project or group which implement OLE functions
> > on Linux, especailly X-Window?
> > KDE or GNOME do the OLE stuff? I heard that KDE has OLE stuff which
> > almost the same as Microsoft's architecture: In-Place editing and
> > look.
>
> There is a complete COM/DCOM implementation for Linux on
> http://www.softwareag.de. Since OLE bases completely on it, go there
> and take a look.
>
> In itself, it is not that easy. For OLE, you need at an existing base
> of apps that support it in order to be interresting, but everything
> must begin somewhere.
>
> Ciao
> Igor
>
I thought that all gnome apps supported the com superset orbs, so
any native gnome apps should have com features, therefore ole.
Peter Allen
------------------------------
Date: Thu, 15 Jul 1999 14:03:47 -0500
From: Clark Williams <[EMAIL PROTECTED]>
Subject: Re: DMA from/to user space?
Maciej Golebiewski wrote:
> Clark Williams wrote:
>
> > Thanks for your reply. Do you have a URL or ftp address to their source?
>
> Yep. You can find it at http://www.nersc.gov/research/FTG/via/
>
> Maciej
Thank you very much.
I've got the M-VIA code and the kernel patch by Robert Kaiser and am in the
process of studying them. I would like to incorporate a set of user memory
locking and unlocking functions such as in the patch, but I don't really want
to modify the kernel proper. I'd rather just incorporate the locking code into
my loadable module and do all the grungy details there.
My intent is to lock down the pages that form the buffer specified by a
read/write request and DMA to/from them using scatter-gather. One question
I've got is: do I have to be back in process context to unlock them? Or will
it be safe to do so from interrupt context?
Also, any hints as to where in the via code you got the memory locking code?
;-)
Clark
--
Clark Williams
Chief Architect
WireSpeed Communications
[EMAIL PROTECTED]
(256) 704-9256
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Subject: Re: New OS development
Reply-To: [EMAIL PROTECTED]
Date: 15 Jul 1999 18:38:00 GMT
On 15 Jul 1999 12:39:40 -0400, [EMAIL PROTECTED] wrote:
>well, C doesn't suport objects either. it's done like so:
>
>struct superclass{
> func1 = generic_func1();
> func2 = generic_func2();
>}
>
>struct subclass{
> func1 = NULL;
> func2 = super_func2()
> func3 = some_nifty_func_unknown_to_parent;
>}
>
well, that's one way.
Another simpler way, with a higher level of object opaqueness, is
/********externaldefs.h******/
/* externally visible stuff here */
typedef struct myobjinternals *MYOBJ;
MYOBJ getnewobj();
void manipobj(MYOBJ, int sometweak);
/*********** internals.c ************/
struct myobjinternals {
blah bla;
blah blah blah;
};
void manipobj(MYOBJ, int sometweak){ .....}
######################################################################
You can now distribute "externaldefs.h" and "internals.o".
The third-party programmer will never get to see the internals of
your objects.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
--------------------------------------------------
The word of the day is mispergitude
------------------------------
From: [EMAIL PROTECTED] (Ashley Penney)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: The opportunities that I would like to see Linux address. [Not that
anyone reads these things] - rather long
Date: 15 Jul 1999 20:43:25 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 15 Jul 1999 02:03:33 GMT, Christopher Browne ([EMAIL PROTECTED]) gabbered:
:On 14 Jul 1999 20:46:42 GMT, Darren Winsper
:Rumor has it that the Debian folk have a plan to have the next "major"
:version of dpkg have the ability to preferentially look for sources,
:with the benefit that you could have defaults set up to compile
:programs in a manner tuned to your hardware. Thus, if you have a
:PentiumPro, you might run something like:
:
:# apt-get build-from-source glibc
:
:and it would go off, grab sources to glibc from ftp.debian.org,
:compile them in a manner tuned for your architecture, and install it.
:
:This is, of course, an 'evil commandline' way of doing things; they
:already have text-UI and GUI apps that put a "friendlier" frontend
:onto this sort of thing.
apt-get -b source glibc
They've already got the system in place, the -b tells it to actually
build it, otherwise it just downloads and unpacks it. :)
--
Ashley Penney - <[EMAIL PROTECTED]>
The dinosaurs died because they didn't have a space program. -- Arthur C Clarke
------------------------------
From: Greg Yantz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 15 Jul 1999 16:02:28 -0400
[EMAIL PROTECTED] () writes:
> On 13 Jul 1999 02:27:29 GMT, Rowan Hughes <[EMAIL PROTECTED]>
> wrote:
> >In article <7m8qtt$[EMAIL PROTECTED]>, Byron A Jeff wrote:
> > [snip]
> >>So BTW why exactly do you need 2GB+ files?
I'm sure people can think of reasons. Computers *are* tools, after all.
> >They're needed more and more. In 6-12 months 50GB IDE disks
> >with media speeds of 30MB/sec will be the norm. I'm using
> >this sort of H/W already at work (GIS type stuff) and Linux
> >would get a lot more use in this field if it could do >2GB files.
Ah, GIS stuff. I've heard a little bit about that. :) Kind of scary,
the amount of data that gets thrown around.
> That makes for 100 (or less) whole files for the entire disk.
For one disk, yes. Somewhat more for the whole array. :)
> Mind you, I already have a 22G disk on my system and
> have yet to have a burning need for really big files.
OK, you've slipped into autopilot mode here. I'm not sure you're really
playing attention to what the other fellow was saying. He was suggesting
an area where 2+ GB files are needed, an area where Linux might be
popular if it supported such files.
Unless you're doing GIS work, the fact that you personally have no
need for 2+ GB files is quite irrelevent.
> 1.3G will get you 2 hours of bootleg MPEG2 video.
Again, a fact that is true but not helpful.
-Greg
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Reply-To: [EMAIL PROTECTED]
Date: 15 Jul 1999 20:57:02 GMT
On Thu, 15 Jul 1999 20:03:33 +0200, [EMAIL PROTECTED] wrote:
>...
>Much more than tweaking. IIRC there is absolutely no way for the *client
>app*
>to supply a font, fonts have to be installed on a font server.
you just contradicted yourself.
The app can say "Add this font server to the font path"
The app can ALSO open a port and act as a font server.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
--------------------------------------------------
The word of the day is mispergitude
------------------------------
From: "kryliss" <kryliss_at_navix.net>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: Thu, 15 Jul 1999 16:45:42 -0500
Other things such as DVD burners?? They will be here and affordable real
soon, media production, backups. Just to name a few things.
------------------------------
From: Ed Macke <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.development.apps
Subject: request for help w/TCP analysis app
Date: Thu, 15 Jul 1999 16:56:32 -0500
Hi. Apologies in advance if this is the wrong forum for this question,
but I need some pointers from the Linux community in order to convince
management here to go with a Linux solution in place of Windows NT.
I'm trying to write a network analysis application, which opens an IPv4
TCP connection to a cooperating host, sends and receives large amounts
of
data, and then analyzes the connection behavior for throughput,
retransmission and window size statistics, etc. In addition, the
throughput must be throttled, if necessary, to avoid exceeding some
pre-defined threshold (for instance, T1 speed). Throughput is readily
measured at the socket, but I need access to either the raw packet
contents or else internal protocol stack information to analyze items
such as retransmissions. Questions:
1. Does anyone know of any tools (preferably ones with source code
available) which perform similar types of analysis on Linux? (I'm
aware of HP's netperf.)
2. Does anyone know how to probe inside a socket (eg with getsockopt())
to determine TCP information (such as retransmissions) for a given
connection? Looking at the 2.2.10 kernel, it looks like a simple hack
to net/ipv4/tcp.c:tcp_getsockopt() along the lines of:
switch(optname) {
case TCP_MAXSEG:
val = tp->user_mss;
break;
/* begin hack */
case TCP_RETRANSMISSIONS: /* some suitable define for this */
val = tp->retrans_out;
break;
/* end hack */
...
will furnish the retransmission count. This assumes that the
retrans_out value in the tcp_opt structure given by
sk->tp_pinfo.af_tcp
is actually the number of retransmissions. Can someone knowledgeable
comment on the validity of this approach?
3. Is there a kernel mechanism for throttling a TCP connection so that
it
does not exceed a specified throughput rate? (The application can
attempt this by judicious sleeps between send()s, but internal buffering
in the TCP/IP stack can interfere with this.)
Please send any replies to [EMAIL PROTECTED], as I normally do not read
this newsgroup. Thanks in advance for any and all help!
Ed Macke
Savvis Communications
[EMAIL PROTECTED]
------------------------------
From: Tony Saba <[EMAIL PROTECTED]>
Subject: Re: ioctl() / security
Date: Thu, 15 Jul 1999 16:38:57 -0700
This may be a bug or feature, depending on how the devices driver writers thought the
device
would be most used.
> This is the whole point of my post. If this is a bug, I can update the
> kernel and see what happens. But I just don't know which behaviour is
> to be considered 'normal'... There are so many different behaviours
> depending on the ioctl arguments and on the device driver, that I don't
> know what is correct behaviour anymore. Is all this documented somewhere?
> Where are file permissions and UID checked? In a single place somewhere
> in the kernel (doesn't seem so at first sight...)?
>From what I understand about device drivers, any device driver function acting on the
>part
of a process implements its own policy about allowing access to the device, presumably
after
the fs layer has checked the permisions on the device special file.
> - to eject CD-ROMs, 'eject' uses:
> status = ioctl(fd, CDROMEJECT);
>
> - to eject from SCSI devices other than CD-ROMs, 'eject' uses:
> /* ... */
> scsi_cmd.cmd[0] = ALLOW_MEDIUM_REMOVAL;
> /* ... */
> status = ioctl(fd, SCSI_IOCTL_SEND_COMMAND, (void *)&scsi_cmd);
> /* ... */
> scsi_cmd.cmd[0] = START_STOP;
> /* ... */
> status = ioctl(fd, SCSI_IOCTL_SEND_COMMAND, (void *)&scsi_cmd);
> /* ... */
> scsi_cmd.cmd[0] = START_STOP;
> /* ... */
> status = ioctl(fd, SCSI_IOCTL_SEND_COMMAND, (void *)&scsi_cmd);
So a call to different ioctl will result in a different behavior, since the scsi
driver and
the IDE/ATAPI driver are independent. And of course, the drivers were probably written
by
completely different people, but I don't have the code in front of me to check for
sure. It
is also entirely possible that these policies could change between kernel versions.
I can't tell you why cdroms and scsi devices should behave differently, but the
maintainers
of the respective drivers could tell you. It may even be documented in the source
code.
(Unfortunately I can't check right now.)
Tony Saba
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: OLE in Linux?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 16 Jul 1999 00:13:57 GMT
On Thu, 15 Jul 1999 20:10:07 +0100, Peter Allen
<[EMAIL PROTECTED]> wrote:
>I thought that all gnome apps supported the com superset orbs, so any
>native gnome apps should have com features, therefore ole.
"COM Superset ORBs?"
What on earth is that?
Can you provide a URL link to some reference to that?
It's fair to say that GNOME has the *intent* to provide a CORBA-based
analogue to OLE. (They call it "BABOON" - "BABOON Allows BABOON Objects
Over Networks.")
There is some code written; I've been monitoring the Gnumeric mailing
list, and it is one of the early apps that is being made to support
BABOON.
The notion that this has anything *directly* to do with COM or OLE is
quite mistaken. You *might* be able to bridge using a CORBA-to-DCOM
adaptor to some DCOM code, but I seriously doubt that anybody has tried
such.
--
"Jeez, got me. Unix is sorta like Heroin, It feels good for about 5 minutes
a day and horrible the rest of the time." -- Jim O'Dell
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/corba.html>
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Subject: Re: Bug of GCC
Date: 15 Jul 1999 18:07:13 -0700
Reply-To: [EMAIL PROTECTED] (Ulrich Drepper)
"Cute Panda" <[EMAIL PROTECTED]> writes:
> I'm using RedHat Linux 6.0, 4CD Full Package, I encounter a bug of gcc as
> follows:
This is no bug in gcc, it's a bug in your program.
--
===============. drepper at gnu.org ,=. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Crossposted-To: comp.os.linux.networking
Subject: Re: Network stack rewrite
Date: Fri, 16 Jul 1999 01:53:08 GMT
Reply-To: [EMAIL PROTECTED]
I'm curious. What in the linux 'com stack' do you think is not needed?
What new functions would you add?
On Thu, 15 Jul 1999 15:38:30 +0100, "Daniel" <[EMAIL PROTECTED]>
wrote:
>I wish to add some new function and remove some of the unneeded stuff from
>the lunix com stack. The roblem is that I have no idea where to start. I
>have entered many IRC chats on the subject and get told "Go to the source!"
>
>Well the source is a bit too OTT for me at the moment and I want to gently
>accustome myself to it.
>
>The question is.
>
>Where can I get information about the structure of the linux comstack? Some
>simple stuff at first and perhaps a few whitepapers or development docs. I
>will contact the writer of the stack as a last
>move.
>
>Dan
>
>Answers here or to [EMAIL PROTECTED]
>
>Thanks...
>
>Last time I posted this i was told that the development was undocumentated.
>I believe that for anything as sucessfull a linux must have some recording
>process behind it to let all the developers work togeather.
>
>
>
>
>
Lew Pitcher
JOAT-in-training
------------------------------
From: "Cute Panda" <[EMAIL PROTECTED]>
Subject: Bug of GCC
Date: 16 Jul 1999 00:47:24 GMT
Hi Friend,
I'm using RedHat Linux 6.0, 4CD Full Package, I encounter a bug of gcc as
follows:
#if 0
It's a bug
#endif
gcc will parse the lines inside #if 0 .... #endif and then complains
about "not end of
string" about "It's a bug", I wonder why gcc parses the lines inside "#if 0
.... #endif",
anybody knows why ? please help! thanks!
Murphy
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Kernel version 2.3.9+
Date: 15 Jul 1999 21:02:01 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[N1ho <[EMAIL PROTECTED]>]
> I don't subscribe to the kernel mailing list because I don't have
> time to wade through it all. It's a lot quicker and easier to unpack
> a new kernel tree and check a text file or two for a list of known
> problems and workarounds rather than wait several hours or a day or
> two for someone to put up a page on the Web somewhere telling me that
> the kernel tree is bad.
As may be. The way the distribution works (and much has been said
about this in the past), we have Linus as effective single point of
failure, meaning also single point of applying patches. To update the
README whenever necessary either means (a) Linus maintaining the README
and editing it every release where something big changes, or (b)
someone else doing so and sending him a patch for it just before he
releases an interesting kernel. Choice (a) is bad because Linus
manages to keep plenty busy and wouldn't probably be interested in one
more thing to have to do, and (b) is bad because synching with him for
this would be very difficult for any but the top few developers (who
know what all the "interesting" changes are), which brings us to the
(a) problem but with s/Linus/Alan/g or whatever.
Next best thing is for someone (not Linus) to maintain a web site with
"breaking news" on known kernel issues, and try to keep it reasonably
up-to-date. This has the advantage that the maintainer doesn't have to
be constantly feeding Linus patches.
Oddly enough, we have such a page: Kernel Newsflash by Richard Gooch.
>From memory:
http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
It makes a nice bookmark, and Richard does manage to keep up pretty
well, for the most part.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Package manager as a VFS
Date: 15 Jul 1999 21:14:07 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Peter Samuelson <[EMAIL PROTECTED]>]
> > Anyway, package management doesn't really fit the file paradigm at all.
[Mark WARDLE <[EMAIL PROTECTED]>]
> Ahhh.. fair 'nough then. Basically, I was daydreaming about things
> like activedirectory (*spit*) and fancied abstracting something like
> a package manager onto a filesystem.
One thing to think about would be some sort of integration between a
package manager and a *file manager app* (GUI or otherwise). This is
probably much more reasonable. This would be similar to what Windoze
NT Explorer does in some cases. For example, if you `explore'
%SYSTEMROOT%\FONTS, instead of the filenames actually in the directory
you see font names. `Open' spawns a font viewer, and `move', `copy'
and `delete' just Do The Right Thing. I assume this is all carried out
via COM.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Kernel version 2.3.9+
Date: 15 Jul 1999 21:54:18 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[garypark <[EMAIL PROTECTED]>]
> Personally, I think I made it clear that I don't approve of the way
> you were treated for what I think was a correctly addressed
> question. This is the correct news group. They have no right and I
> doubt they have the power to stop you from such a question.
"The power to stop you": no. Obviously not. Any fool can say anything
on a newsgroup and there's basically *nothing* anyone else can do about
it. (We could send forged cancel messages, but that's Not Nice.)
However, your moral high ground sounds prety snooty because you're
ignoring the fact that long-standing (and I do mean long-standing)
rules of netiquette were breached. *Very* briefly, the relevant rules
could be summed up:
* NEVER post to a newsgroup without acclimating yourself to the
group. Read the group FAQ, if there be one. Read a few days'
worth of posts, to get a feel for what is actually talked about,
what issues are old and tired, what viewpoints are prevalent.
* NEVER waste other people's time and bandwidth (some people pay by
the kilobyte) with a question you could have answered for yourself
with reasonable diligence. That means look in the news archives
(www.deja.com is the best-known) for others having asked your
question in the past. Scan recent posts (it's amazing how many
morons post questions that have been answered two days before).
Again, read FAQs if you can find them. Check other resources (in
the present case, things like www.kernelnotes.org). These
resources should be easy to find if you acclimate yourself to the
group as described above.
I realize many people don't know these rules as well as everyone
should, because many Internet providers do a really lousy job of
preparing their customers for what they are selling them.
But this is no excuse, really. net.boors are more than likely to be
real-life boors too, since most of netiquette is readily extrapolated
from normal societal politeness and common sense. Consider other forms
of communication: would you enter a room and start yammering without so
much as listening for a moment to find out what other people are in the
middle of talking about?
> Remeber for any news group: The boyz in the hood may jump you and
> thump you at any time for any reason. For reasons of their own, for
> no reason at all. Just for the fun of it. At least cyber thumping
> sdon't leave bruises.
In this newsgroup, in my experience, you usually only get thumped for
*good* reason. Some of the regulars are more polite than others, but
everyone who follows the netiquette I've outlined above (and some other
rules, but those are a good start) generally get along just fine here.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 02:25:08 GMT
Ulrich Drepper ([EMAIL PROTECTED]) wrote:
: This is no bug in gcc, it's a bug in your program.
Please explain why you think it is consistent that
/*
'
*/
is preprocessed without an error, whereas
#if 0
'
#endif
gives an error. The native Irix system here, 'cc foo.c'
will work in both cases, but 'gcc foo.c' won't.
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer."
--Edsger Dijkstra
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
