Linux-Development-Sys Digest #115, Volume #8 Thu, 31 Aug 00 01:13:15 EDT
Contents:
Re: purify and memory managers (Kaz Kylheku)
where is archive URL for this news group? ([EMAIL PROTECTED])
Re: Programming socket in the cycle ("Phillip Soltan")
Re: Cross-compiler for powerpc-motorola-vxworks ("Phillip Soltan")
Re: Linux, XML, and assalting Windows ("paul snow")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: purify and memory managers
Reply-To: [EMAIL PROTECTED]
Date: Thu, 31 Aug 2000 01:51:54 GMT
On 30 Aug 2000 20:13:43 -0400, Paul D. Smith <[EMAIL PROTECTED]> wrote:
>%% [EMAIL PROTECTED] (Kaz Kylheku) writes:
>
> kk> There is a bounds checking patch for GCC, which instrument the
> kk> intermediate code rather than the object code.
>
>Yes, that is also cool, but my understanding is that it only works with
>arrays. Perhaps I'm atypical, but I use pointers to allocated memory
>_MUCH_ more than I use arrays.
No, bounds checking gcc deals with both dynamic and automatic objects. The
limitation is, that the protection is on the level of objects rather than
sub-objects. For instance, it won't detect a pointer that is displaced from one
structure member to the next. It's possible that a correct program could
do something like that; e.g. using the offsetof() macro to figure out
displacements, it could navigate a pointer around a struct.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED]
Subject: where is archive URL for this news group?
Date: Thu, 31 Aug 2000 02:24:01 GMT
Does anyone know the website hosting the archive of this newsgroup?
Thanks
Ming
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Phillip Soltan" <[EMAIL PROTECTED]>
Subject: Re: Programming socket in the cycle
Date: Thu, 31 Aug 2000 04:30:51 GMT
Since you close the socket on the client side *inside* the for(;;) loop it
isn't suprising that you only get one cycle.
"Pliev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Hello All!
> I have a problem. I am sorry, my questions is fool, but I am beginner in
> Unix :((
> I have created two simple programs, for testing TCP/IP connecting -
server
> and client.
> This examples I am attaching to this message.
> This examples is working correctly, but one cycle of transfers only.
> I want, that the transfer implemented permanently, in a cycle.
> But the server invokes "accept" and does "send" in reply to a call
> "connect"
> on the party of the client only.But function "connect" not working in
cycle.
> It calling one time only. In outcome a transfer take place one time
only.
> How I can to solve this problem?
> Help me, if you can...
>
>
> Examlpes:
>
>
file://Server---------------------------------------------------------------
> ------
> #include <stdio.h>
> #include <stdlib.h>
> #include <math.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <netdb.h>
> #include <unistd.h>
> #include <sys/time.h>
> #include <signal.h>
> #include <arpa/inet.h>
> #include <string.h>
> #include <pthread.h>
>
>
> #define PORTNUM 1500
>
>
> struct servent *sp;
> struct hostent *hp;
> int skt,ns;
> struct sockaddr_in server,client;
> int pid;
> char buf[80];
>
> char transes[180]="The testing message for VK. 273-99-44";
>
> pthread_t idTrasmit;
>
>
> void *Trasmit(void *arg)
> {
>
> int addrlen;
>
> bzero(&client,sizeof(client));
> addrlen=sizeof(client);
>
>
>
> if ((ns=accept(skt, (struct sockaddr *)&client,(socklen_t
*)&addrlen))==-1)
> {
> perror("Accept fail");
> exit(1);
> }
>
>
> fprintf(stderr,"Client = %s\n",inet_ntoa(client.sin_addr));
>
>
> int nbytes;
> int fout;
> close(skt);
>
> send(ns,transes,sizeof(transes),0);
> printf("Message sended\n");
>
> close(ns);
>
>
>
> } file://end transmit
>
>
> main(int argc, char *argv[])
> {
>
> int nport;
> nport=PORTNUM;
> nport=htons((u_short)nport);
>
>
> printf("The programm Testing Server TCP/IP for Vk\n");
> printf("Copyleft C Dr.Pliev 23.08.2000\n");
>
>
> if ((skt=socket(AF_INET, SOCK_STREAM, 0))==-1)
> {
> perror("Error creating socket");
> exit(1);
> }
>
> printf("Socket created, ID=%d\n",skt);
>
> bzero(&server, sizeof (server));
> server.sin_family=AF_INET;
> server.sin_addr.s_addr=INADDR_ANY;
> server.sin_port=nport;
>
> if (bind(skt,(struct sockaddr *)&server,sizeof(server))==-1)
> {
> perror("Error of bind");
> exit(1);
> }
> printf("Bind OK\n");
> printf("Server ready:%s\n",inet_ntoa(server.sin_addr));
>
> if (listen(skt,5)==-1)
> {
> perror("Error call listen");
> exit(1);
> }
> printf("Listen OK\n");
>
>
>
> pthread_create (&idTrasmit, NULL,Trasmit, NULL);
>
> for(;;);
>
>
> return 0;
> }
>
> // Client ---------------------------------------------------
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <math.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <netdb.h>
> #include <unistd.h>
> #include <sys/time.h>
> #include <signal.h>
> #include <arpa/inet.h>
> #include <string.h>
>
> #define PORTNUM 1500
>
>
> main(int argc, char *argv[])
> {
>
> int skt;
> int pid;
> int i,j;
>
> char transes[180];
>
> struct sockaddr_in server;
> struct hostent *hp;
>
>
> double num;
> int dec, sign, ndig =0;
>
> char *str;
>
> printf("The programm Client TCP/IP for Vk\n");
> printf("Copyleft C Dr.Pliev 23.08.2000\n");
>
>
> if((hp=gethostbyname(argv[1]))==0)
> {
> perror("gethostbyname error");
> exit(1);
> }
>
> bzero(&server, sizeof (server));
> bcopy(hp->h_addr,&server.sin_addr,hp->h_length);
> server.sin_family=hp->h_addrtype;
> server.sin_port=htons(PORTNUM);
>
> if ((skt=socket(AF_INET, SOCK_STREAM, 0))==-1)
> {
> perror("Error creating socket");
> exit(1);
> }
>
> printf("Socket created, ID=%d\n",skt);
>
> fprintf(stderr,"Address Client = %s\n",inet_ntoa(server.sin_addr));
>
> if (connect(skt,(struct sockaddr *)&server,sizeof(server))==-1)
> {
> perror("Connect errror");
> exit(1);
> }
>
>
>
> for(;;)
> {
>
> if(recv(skt,&transes,sizeof(transes),0)>0)
> {
> printf("%s\n",transes);
> num=(double)transes[7];
> str = fcvt(num, ndig, &dec, &sign);
> printf(" %s\n",str);
> }
>
>
> close (skt);
>
> }
>
>
> }
>
>
>
>
------------------------------
From: "Phillip Soltan" <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc.help
Subject: Re: Cross-compiler for powerpc-motorola-vxworks
Date: Thu, 31 Aug 2000 04:36:03 GMT
"powerpc-eabi" is the only PowerPC cross-compiler that I have been able to
build with GCC 2.95.2
Phil Soltan
"Vincent Hamrick" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Sheesh, no information whatsoever - I should know better than that.
> binutils was 2.9.1 and gcc was 2.8.1. The error when trying to configure
> gcc was "unsupported combination" (powerpc-motorola-vxworks). I need to
> try 2.95.2, but my general question was supposed to be "has anyone gotten
> this combination to work?", followed by a "how did you do it?"
>
> Thanks again,
> -V
>
>
> Vincent Hamrick wrote:
>
> > I was able to build the bintools (2.8.1?) for powerpc-motorola-vxworks
> > but was unable to build gcc (2.9.1?) for the same. Unsure of the
> > versions since I did this at work. Anyone have any info on how to build
> > this?
> >
> > Thanks in advance,
> > -V
>
------------------------------
From: "paul snow" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.misc
Subject: Re: Linux, XML, and assalting Windows
Date: Thu, 31 Aug 2000 04:54:42 GMT
Let me try this once more. What I asked was if you could see any gain from
separating and maintaing the abstract requirements of software components
from the scripts that render and maintain a particular configuration of
those components across a set of machines.
Would automatic generation of cfengine scripts help? If so, what
information would be needed to generate them? Is that information available
to the developer? How hard would it be to specify?
Bottom line: Can the information needed to drive application delivery be
separated from the process of delivering it?
You are the one with real cfengine experience. Perhaps cfengine scripts can
really only be written by programmers, though I would really doubt this is
the case. The scripting syntax is really simple and to the point.
Paul Snow
[EMAIL PROTECTED]
Christopher Browne <[EMAIL PROTECTED]> wrote in message
news:fvhr5.34905$[EMAIL PROTECTED]...
> Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED] would
say:
> >In article <pb_q5.545915$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >> Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED]
> >> would say:
> >> >Sure you could use xml, as long as your install program can write it.
> >> >It would equivalent to the registry in WinX or the assorted /etc
> >files
> >> >(and more) in *x. But these mechanisms work (ugly as they may be in
> >> >their own unique ways). Why are you trying to fix the part of
> >software
> >> >installation & configuration that isn't broken?
> >>
> >> Indeed.
> >>
> >> What the world could use is some Better Tools for managing /etc files.
> >>
> >> For that purpose, I find I very much like cfengine
> >> <http://www.iu.hioslo.no/cfengine/>,
> >> which provides a rule-oriented system with operators for setting up
> >> directory links, modifying text-based config files (which is _very_
> >> nice for modifying things like /etc/hosts, /etc/fstab, and such),
> >> copying files into place, and Lots Of Other Stuff.
> >>
> >> There would be _some_ merit to creating an XML or SGML DTD to describe
> >> cfengine rules, thereby allowing cfengine configuration files to be
> >> managed using the fabled "generic XML editing tools," and validated
> >> before being dropped into place to give at least some _limited_
> >> guarantees of good behaviour.
> >>
> >> That would essentially amount to things like:
> >>
> >> <filestatusrules>
> >> <filestatusrule>
> >> <filename> /etc/printcap </filename>
> >> <mode> 644 </mode>
> >> <owner> root </owner>
> >> <action> fixplain </action>
> >> </filestatusrule>
> >> <!-- replacing "/etc/printcap m=644 o=root action=fixplain" -->
> >> <filestatusrule>
> >> <filename> /usr/sbin/sendmail </filename>
> >> <mode> 755 </mode>
> >> <owner> root </owner>
> >> <action> fixplain </action>
> >> </filestatusrule>
> >> <!-- replacing "/usr/sbin/sendmail m=755 o=root action=fixplain" -
> >->
> >> </filestatusrules>
> >> <editfiles>
> >> <editfile>
> >> <filename>/etc/apt/sources.list </filename>
> >> <appendifnosuchline> deb file:/brownes/knuth/debianstuff unstable
> >main
> >> </appendifnosuchline>
> >> <appendifnosuchline> deb http://alpha.onshore.com/debian local/
> >> </appendifnosuchline>
> >> <appendifnosuchline> deb http://hops.harvestroad.com.au/ debian/
> >> </appendifnosuchline>
> >> </editfile>
> >> <editfile>
> >> <filename> /etc/hosts </filename>
> >> <appendifnosuchline> 192.168.1.5 knuth.brownes.org knuth
> >cache
> >> </appendifnosuchline>
> >> <appendifnosuchline> 192.168.1.1 dantzig.brownes.org dantzig
> >> </appendifnosuchline>
> >> <appendifnosuchline> 192.168.1.7 godel.brownes.org godel
> >> </appendifnosuchline>
> >> </editfile>
> >> </editfiles>
> >>
> >> Mind you, the existing cfengine syntax _works_, which means that it
> >> would be likely to take some convincing to "force" anyone to move over
> >> to using an XML parser for this.
> >
> >The cfengine does indeed cover much of the ground we need to cover.
> >And you have made a very insightful observation in that XML could be
> >used to describe in general what a software component requires. But I
> >do not think the right approach would be to simply write cfengine
> >syntax rules directly into the XML. Instead, why not render the XML
> >into cfengine rules?
>
> Of course, what _really_ begs the question is why XML ever comes up in
> the first place.
>
> It sounds like what you're trying to do is to design something that
> cfengine would be perfectly suited for.
>
> Issues that come up in system configuration include:
> - Dealing with resource locking;
> - Describing and setting permissions;
> - Describing what links should exist, whether those be symbolic links
> or references in files (e.g. - having a host identified in
> /etc/hosts)
>
> The primary merit of XML is that (despite being considerably _more_
> difficult to parse than S-expressions) it is _somewhat_ less difficult
> to parse than SGML, and resembles the HTML that only the most
> pointy-haired of technical managers are incapable of coping with.
>
> XML buys you the ability to get a "cheap parser."
>
> It does not solve the other problems involved in building complex
> systems, which begs the question of why XML need get involved in the
> first place.
>
> >What you need to do is simply identify the data structures that will
> >need to be referenced by the cfengine. Then use a translator to
> >produce the cfengine rules. So, in your example, those constructs such
> >as machine names, ip addresses, filenames, etc. that may vary from
> >system to system should instead be referenced by a XML variable.
>
> Those constructs are intended to be the _invariants_; the whole point
> of the exercise is to establish the IP addresses, hostnames and such.
> They are _never_ generic.
>
> What could vary is where the configuration info may be put, and the
> cfengine language is designed to provide the ability to describe that
> sort of thing.
>
> >These variables represent decision points in how the software
> >component should be rendered, and vary from machine to machine, and
> >network to network.
> >
> >The values for these variables can be collected by prompting the user,
> >or as supplied by a separate XML description.
>
> By the way, I think you're rather confused about the nature of XML.
>
> It isn't a language that can _have_ "variables." It is a static
> language; nothing _can_ vary, so that the notion of "variable" is
> pretty nonsensical. There are entities, consisting of elements, which
> may have attributes. A Lisp-like perspective would view this as
> involving a set of "static bindings."
>
> >The question is, why use XML if I can just write the cfengine rules
> >myself?
>
> A good question indeed.
>
> >We have (in the cfengine) the need for the same kind of separation.
> >The use of cfengine requires a large scripting base which can define
> >the installation and health of a collection of systems on a network.
> >The generation of these scripts is the hardest part of the cfengine
> >approach. I am not a big user of cfengine, but I am unaware of any
> >standard for distributing applications that allows them to simply "drop
> >into" cfengine scripts.
>
> There are no common conventions for this, probably primarily because
> people haven't seriously thought to use it in this way.
>
> It would be a cool idea [for someone else to implement :-)] to build a
> packaging tool that would use cfengine as the installation tool rather
> than the random groupings of shell scripts that are often used with
> RPM and DPKG. I think this would be _reasonably_ practical, and that
> a reasonable design would include several scripts:
>
> a) One cfengine script to move files into place. This would run only
> once, and be fairly "hard coded."
>
> b) One, possibly written in something else, to ask the user and/or
> system any information that needs to be asked. For a web server,
> for instance, this might involve asking what port to accept
> requests on, as well as any proxies to pass requests to.
>
> This script would then 'fill in blanks' to generate other scripts.
>
> If you ever want to redesign configuration, you'd rerun this
> script.
>
> c) A cfengine script would then be set up to "fix up" the config
> files based on the parameters provided by b).
>
> This might involve filling in the HTTP port number, or fixing up
> permissions on files/directories, or indicating log rotation
> policies, or other such stuff.
>
> This script might be re-run as needed to clean up configuration; it
> would be a reasonably good move to rerun this on a regular
> [daily/weekly?] basis.
>
> >Do you think it would help if software were defined in XML abstractions
> >that could be combined and rendered into cfengine scripts in an
> >automated way? Or is there something about cfengine scripts that would
> >make this too difficult. In your XML example, the only problem I see
> >is that you hard coded IP addresses, machine names, directories, and
> >file names, some of which may need to vary if the description were to
> >be generalized. Some of the operations are pretty platform dependent,
> >but that I think is okay.
>
> I hard coded the IP addresses entirely intentionally; that was the
> whole _point_ of the exercise.
>
> As for "defining the software in XML abstractions," that either
> doesn't make sense, if we speak in any sort of "complete" sense, or
> represents something only _marginally_ useful.
>
> In the approach suggested above, there would be a whole "horde" of
> cfengine scripts of the various sorts.
>
> There would be _some_ value in the "second variety" being presented in
> a form that would make it easy to rewrite them into a more efficiently
> processed form.
>
> Thus, if we had the following sequence of "periodically-run" scripts:
> /etc/cfengine/packages/daily/apache
> /etc/cfengine/packages/daily/squid
> /etc/cfengine/packages/daily/zsh
> /etc/cfengine/packages/daily/ftpd
> /etc/cfengine/packages/daily/ftp
> /etc/cfengine/packages/daily/inetd
> /etc/cfengine/packages/daily/cfengine
> ...
>
> There are two approaches:
> a) Have cfengine run through them all individually, or
> b) [Somehow, magically] join them together to generate "master.daily",
> and have cfengine run once on One Big Script.
>
> If the "daily" things were represented in XML, or S-expressions, or
> some other "readily-walkable-tree," it would be straightforward to
> walk through them all and assemble that One Big Script in a somewhat
> optimized order.
>
> On the other hand, it could be just as easy, and require no
> fundamentally new code, to have the main file do:
>
> import:
> Hr00:
> /etc/cfengine/daily.master
>
> And (daily?) rebuild daily.master via:
> "echo 'import:' > /etc/cfengine/daily.master'
> "cd /etc/cfengine; ls packages/daily >> /etc/cfengine/daily.master"
>
> XML doesn't forcibly enter into this _at all_.
> --
> (concatenate 'string "aa454" "@" "freenet.carleton.ca")
> <http://www.hex.net/~cbbrowne/lsf.html>
> "DTDs are not common knowledge because programming students are not
> taught markup. A markup language is not a programming language."
> -- Peter Flynn <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
