From chris_berry-list-oclug-devel at jm-associates.com Fri Sep 2 14:24:28 2005 From: chris_berry-list-oclug-devel at jm-associates.com (Chris Berry) Date: Fri, 02 Sep 2005 14:24:28 -0700 Subject: [OCLUG-devel] Single Element Structures In-Reply-To: References: Message-ID: <4318C30C.1000601@jm-associates.com> Just off the top of my head, you may want to do some research into linked lists, however I'm not so great at them myself so that's about as much help as I can offer. Chris Berry chris_berry at jm-associates.com Information Advisory Manager JM Associates ?If you have a strong enough why you can bear almost any how.? --Nietzsche Doug Jolley wrote: > Hi -- > > I am a real newbie to C and in way over my head on a project that I'd really > like to get to work. I'm thinking that the thing to do may be to try to get > some help at the next OCLUG meeting; but, in the meantime I'm going to try > to muddle along as best I can. > > To continue my muddling, I have encountered the following type definition: > > typedef struct { > node* head; > } llist; > > My question is: Why would anyone go to the trouble of defining a structure > with only one element in it? I thought the essence of structures was that > they contained a collection of dissimilar data elements. I'm sure the guy > that did this had a very good reason and I realize that I'm asking a > question without giving a lot of context; so, from what I've given there may > be no answer. Anyway, if an answer may be deduced from what I've given, I'd > love to hear it. Thanks for any input. > > ... doug > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OCLUG-devel mailing list -- OCLUG-devel at oclug.org > http://mailman.oclug.org/mailman/listinfo/oclug-devel From x at xman.org Fri Sep 2 15:05:32 2005 From: x at xman.org (Christopher Smith) Date: Fri, 02 Sep 2005 15:05:32 -0700 Subject: [OCLUG-devel] Single Element Structures In-Reply-To: References: Message-ID: <4318CCAC.5050100@xman.org> Doug Jolley wrote: > Hi -- > > I am a real newbie to C and in way over my head on a project that I'd > really like to get to work. I'm thinking that the thing to do may be to > try to get some help at the next OCLUG meeting; but, in the meantime I'm > going to try to muddle along as best I can. > > To continue my muddling, I have encountered the following type definition: > > typedef struct { > node* head; > } llist; > > My question is: Why would anyone go to the trouble of defining a > structure with only one element in it? I thought the essence of > structures was that they contained a collection of dissimilar data > elements. I'm sure the guy that did this had a very good reason and I > realize that I'm asking a question without giving a lot of context; so, > from what I've given there may be no answer. Anyway, if an answer may > be deduced from what I've given, I'd love to hear it. Thanks for any input. So, basically I can think of two good reasons why one might want to do this: 1) By defining it as a struct you leave open the option of adding more fields later without majorly impacting code that uses the llist type. 2) It prevents random pointers from being coerced into to llist's. So, if you have a function defined like this: void safe_traverse_list(llist alist); instead of this: void traverse_list(node* alist); The compiler catches things it otherwise would miss: void* random_pointer; traverse_list(random_pointer); /* compiler is happy with it */ safe_traverse_list(random_pointer); /* compiler complains */ --Chris From cbsmith at gmail.com Fri Sep 2 15:17:10 2005 From: cbsmith at gmail.com (Chris Smith) Date: Fri, 2 Sep 2005 15:17:10 -0700 Subject: [OCLUG-devel] Re: [OCLUG] how to read an input line ? In-Reply-To: <4314FE8D.2030807@sbcglobal.net> References: <4314FE8D.2030807@sbcglobal.net> Message-ID: <9ae343f5050902151711eedfc0@mail.gmail.com> Following up to oclug-devel On 8/30/05, Joshua Robinson wrote: > Hi, > > What can I use instead of gets( buf ) to read a input line ( in C and > C++ ) ? You should basically *never* use gets(), as it's an unsafe call. fgets() is a better way to go, and is basically a more general version of gets(). There is also the scanf family of functions, but a lot of those tend to be almost as unsafe as gets(). -- Chris From james at colannino.org Fri Sep 2 15:18:15 2005 From: james at colannino.org (James Colannino) Date: Fri, 02 Sep 2005 15:18:15 -0700 Subject: [OCLUG-devel] comparing strings Message-ID: <4318CFA7.5030601@colannino.org> Hey everyone. I have a quick question. Let's say that I have a single string for reference with the following contents: "stringone\nstringtwo\nstringthree\n" What I want to do is compare the contents of one string with each "element" in the above string (each string I want to check against is separated by \n's.) So first I would compare a string to "stringone," then compare it to "stringtwo," etc. What's a good way for me to do this in C? James From strombrg at dcs.nac.uci.edu Fri Sep 2 15:23:10 2005 From: strombrg at dcs.nac.uci.edu (Dan Stromberg) Date: Fri, 02 Sep 2005 15:23:10 -0700 Subject: [OCLUG-devel] Single Element Structures In-Reply-To: References: Message-ID: <1125699790.3000.91.camel@seki.nac.uci.edu> You've hit on one of my favorite topics. Apologies if this is too long-winded. :) The purpose of a struct that people usually discuss is simply grouping heterogeneous types into a single collection, which may then be referred to collectively. Another, and at least as important, function of a struct, which isn't usually discussed in the context of procedural languages like C or Pascal, but is a central topic in Object Based languages like Ada, or Object Oriented languages like C++ or Smalltalk or Python, is to create abstract data types (ADT's). C can do ADT's pretty well really, except for the information hiding part (which it has in common with Python, in a sense), and also C doesn't do inheritance well (C++, Smalltalk and Python do - this being the primary distinction between a mere "Object Based" language like Ada, and these "Object Oriented" languages). The point of an ADT is to, for example, have a single API for a kind of data and the operations performed on that data, but implementing the data representation and operations in different ways, but with different tradeoffs - hence insulating the dependent code from being heavily impacted when the data representation needs to change. One of the classic examples of why you might want an ADT, is implementing a stack. A stack is where you put items in at one end of a "list" (in the generic sense, not the Computer Science sense), and pull items back out from the same end, just like with a pile of plates at Soup Plantation. :) Two common data representations that might be used internally by a stack ADT (abstract data type) would be an array, or a linked list. The array implementation of a stack is nice because it's fast, and because it has low memory requirements when the stack is full, but it'll tend to lead to messiness if the array fills up (which C can get around with realloc, but a language like Pascal (the Niklaus Wirth definition - Borland likely extended for this) doesn't have much in the way of an equivalent). The linked list implementation of a stack is nice because it has no fixed limit on how large the stack can grow (other than available memory, at least on non-segmented architectures), but it'll tend to be a little bit slower, and it'll use more memory than an array implementation when the two stack implementations hold a number of elements near the capacity of the array implementation. If you implement both of these with identical API's, then you can very quickly and easily change your programs from using the plusses and minuses of one implementation (array) to the other (linked list - or vice versa). As a further example of an abstract type, say you have a program that uses a singly-linked list (linked only forward, but not back again), and suddenly you find that the changing needs of the program require you to be able to quickly start at the end of the list, and work backward. You could easily approach this with a recursive algorithm (if you aren't worried about the CPU and memory requirements), but often a slight change in data representation is better. In such a case, you have pretty much three choices: 1) If you were using a library of C functions that implements both singly-linked lists, as well as doubly-linked lists (forward and back), and the doubly-linked list API is already a superset of the singly-linked list API, then you can just switch to the doubly-linked list implementation, and all of your existing code that required only a singly-linked list should continue functioning just fine (so long as they do not violate the ADT definition by reaching inside the struct's inappropriately), so you can dive right into adding the new functionality, rather rearranging the old singly-linked code first. 2) If you are implementing your own linked list functions (seldom a good idea anymore, but a lot of CS students are required to do it, since it's a good example of ADT's/Objects), and you've carefully abstracted your singly-linked list implementation, then you can just add another ADT (possibly via inheritance in a fully object oriented language like C++ or Smalltalk or Python, but not C or Ada) that does doubly linked lists, and other than the (perhaps partially) new ADT and the new code for doubly-linked lists, your existing code doesn't need to be modified much, if at all. 3) If you weren't abstracting your code well, then you could easily end up doing a near-complete rewrite due to what may actually be a relatively small change in the program's requirements. So by having this typedef/struct with a single element, if there is a well defined set of functions that can look inside the typedef/struct (and only they are allowed to do it - IE the inspection/changing of the struct isn't scattered throughout your program) that opens the door to easy changes - like switching to a doubly-linked list, or adding a field that keeps a count of the members in the list, or even switching to an entirely different kind of data structure behind the scenes, while the rest of your code happily takes an afternoon nap. :) Put another way, if you have poorly abstracted code, when you need to change a data representation, you can easily get a sort of "ripple effect", where changes in the code start in one small place, and kind of "ripple outward" into ever further parts of the code. But if things are well abstracted, than most of the time (some would argue all of the time), the "ripples of change" stop at the ADT boundaries, which can be quite a time-saver. There's another reason I would sometimes use a struct with a single element, which is far less significant than what's described above, and some would argue it's a Very Bad Thing, so please take it with a grain of salt. That is, sometimes when I am working in C code that requires callbacks, and there are parameters passed to the callback functions that must accept a "void *", in order to be able to pass a variety of types (a union just wouldn't be flexible enough sometimes), I'll sometimes avoid the poor type checking attendant with casting a variable to void * and back, by just using globals to keep decent type checking (or similarly for static variables in a global context, IE variables that are global only to a particular .c file). But globals are evil, right?! I try to alleviate the evils of using global variables, believing they're sometimes better than screwing around with the type system, by using a struct that contains all the global variables, and hopefully there's a small number of items in that struct - in fact, hopefully only one. That way, any time I want to use a global variable named "foo", I instead refer to "global.foo", making it a hair less confusing when another programmer works on my code, or I revisit my own code years later. :) HTH! On Mon, 2005-08-29 at 14:17 -0400, Doug Jolley wrote: > Hi -- > > I am a real newbie to C and in way over my head on a project that I'd > really like to get to work. I'm thinking that the thing to do may be > to try to get some help at the next OCLUG meeting; but, in the > meantime I'm going to try to muddle along as best I can. > > To continue my muddling, I have encountered the following type > definition: > > typedef struct { > node* head; > } llist; > > My question is: Why would anyone go to the trouble of defining a > structure with only one element in it? I thought the essence of > structures was that they contained a collection of dissimilar data > elements. I'm sure the guy that did this had a very good reason and I > realize that I'm asking a question without giving a lot of context; > so, from what I've given there may be no answer. Anyway, if an answer > may be deduced from what I've given, I'd love to hear it. Thanks for > any input. > > ... doug > _______________________________________________ > OCLUG-devel mailing list -- OCLUG-devel at oclug.org > http://mailman.oclug.org/mailman/listinfo/oclug-devel From x at xman.org Fri Sep 2 15:25:40 2005 From: x at xman.org (Christopher Smith) Date: Fri, 02 Sep 2005 15:25:40 -0700 Subject: [OCLUG-devel] comparing strings In-Reply-To: <4318CFA7.5030601@colannino.org> References: <4318CFA7.5030601@colannino.org> Message-ID: <4318D164.2060905@xman.org> James Colannino wrote: > Hey everyone. I have a quick question. Let's say that I have a single > string for reference with the following contents: > > "stringone\nstringtwo\nstringthree\n" > > What I want to do is compare the contents of one string with each > "element" in the above string (each string I want to check against is > separated by \n's.) So first I would compare a string to "stringone," > then compare it to "stringtwo," etc. What's a good way for me to do > this in C? Assuming the string you are searching with doesn't have any carriage returns in it, why not just use strstr()? It'll return the first place in the larger string that has a match, and you assume all preceding ones aren't a match. You can then invoke it starting at the next address after the one returned by strstr(). Repeat until NULL. --Chris From x at xman.org Fri Sep 2 15:44:58 2005 From: x at xman.org (Christopher Smith) Date: Fri, 02 Sep 2005 15:44:58 -0700 Subject: [OCLUG-devel] Single Element Structures In-Reply-To: <1125699790.3000.91.camel@seki.nac.uci.edu> References: <1125699790.3000.91.camel@seki.nac.uci.edu> Message-ID: <4318D5EA.60602@xman.org> Dan Stromberg wrote: > C can do ADT's pretty well really, except for the information hiding part. How so? I mean: struct foo { int (*method1)(); void (*method2)(int); void* data; }; may not be the prettiest thing, but it works quite well to hide the underlying data structures. > Two common data representations that might be used internally by a stack > ADT (abstract data type) would be an array, or a linked list. Yeah, but then you'd want to define it slightly differently from the example described: struct ll_stack; struct array_stack; #ifdef USE_LINKED_LIST typedef ll_stack stack; #else typedef array_stack stack; #endif That way you can have both the array and linked list functions compiling successfully simultaneously (because they will use array_stack or ll_stack as their parameter types, not stack), and the stack-using code will just automagically link to the right one. > That way, any time I want to use a global variable > named "foo", I instead refer to "global.foo", making it a hair less > confusing when another programmer works on my code, or I revisit my own > code years later. :) Wouldn't it be simpler and just as good a hint to name the variable "global_foo"? --Chris From james at colannino.org Fri Sep 2 16:40:58 2005 From: james at colannino.org (James Colannino) Date: Fri, 02 Sep 2005 16:40:58 -0700 Subject: [OCLUG-devel] comparing strings In-Reply-To: <4318D164.2060905@xman.org> References: <4318CFA7.5030601@colannino.org> <4318D164.2060905@xman.org> Message-ID: <4318E30A.3010601@colannino.org> Christopher Smith wrote: >Assuming the string you are searching with doesn't have any carriage >returns in it, why not just use strstr()? It'll return the first place >in the larger string that has a match, and you assume all preceding ones >aren't a match. You can then invoke it starting at the next address >after the one returned by strstr(). Repeat until NULL. > > That should work pefectly. Thanks. James From strombrg at dcs.nac.uci.edu Fri Sep 2 18:18:09 2005 From: strombrg at dcs.nac.uci.edu (Dan Stromberg) Date: Fri, 02 Sep 2005 18:18:09 -0700 Subject: [OCLUG-devel] Single Element Structures In-Reply-To: <4318D5EA.60602@xman.org> References: <4318D5EA.60602@xman.org> Message-ID: <1125710289.3000.105.camel@seki.nac.uci.edu> On Fri, 2005-09-02 at 15:44 -0700, Christopher Smith wrote: > Dan Stromberg wrote: > > C can do ADT's pretty well really, except for the information hiding part. > > How so? I mean: > > struct foo { > int (*method1)(); > void (*method2)(int); > void* data; > }; > > may not be the prettiest thing, but it works quite well to hide the > underlying data structures. Yeah, it hides it all right. It's of course -possible- to do this sort of thing, even in assembly language, even in machine language, even on a Turing Machine. Most to all efforts in this direction end up reinventing OO/OB languages' object models in a somewhat less convenient way, but it's very possible - as a large example, consider GTK+, which has a pretty OO/OB model, but is implemented in C, and then mapped to a bunch of OO/OB languages from there... Other than the poor type checking, it's really not too gruesome. > > Two common data representations that might be used internally by a stack > > ADT (abstract data type) would be an array, or a linked list. > > Yeah, but then you'd want to define it slightly differently from the > example described: > > struct ll_stack; > struct array_stack; > #ifdef USE_LINKED_LIST > typedef ll_stack stack; > #else > typedef array_stack stack; > #endif Um, yeah. typedef, #define, a magic #include, linking a different .o, -Dfoo=bar, whatever. > That way you can have both the array and linked list functions compiling > successfully simultaneously (because they will use array_stack or > ll_stack as their parameter types, not stack), and the stack-using code > will just automagically link to the right one. Nod. Been there, done that, worth discussing anyway. > > That way, any time I want to use a global variable > > named "foo", I instead refer to "global.foo", making it a hair less > > confusing when another programmer works on my code, or I revisit my own > > code years later. :) > > Wouldn't it be simpler and just as good a hint to name the variable > "global_foo"? You know, I started out doing it with a global_ prefix... I just migrated to the struct later. Seems a little more aesthetic to me, but C is very much a language that allows many styles. From ddjolley at gmail.com Mon Sep 5 13:24:11 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Mon, 5 Sep 2005 16:24:11 -0400 Subject: [OCLUG-devel] Re: Single Element Structures In-Reply-To: References: Message-ID: Thanks to all who responded to my inquiry in this thread. I'm not quite sure what happened. I seemed to get no replies and actually the archive showed no message additions to the list whatsoever. I thought the list had dried up and I was really bummed. Anyway, it looks like it's alive and well now and I'm real happy about that. Thanks again for the input. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050905/fc876ad3/attachment.html From x at xman.org Tue Sep 6 17:33:48 2005 From: x at xman.org (Christopher Smith) Date: Tue, 06 Sep 2005 17:33:48 -0700 Subject: [OCLUG-devel] Interesting little g++ bug Message-ID: <431E356C.5020507@xman.org> Ran in to this funny bug today: #include using namespace std; int main() { cout << dec << -1 << endl; cout << hex << -1 << endl; return 0; } So, what's the output? Well, you'd think it'd be: -1 -1 But instead it's: -1 ffffff Why? Because while the facet handling the formatting of integers uses modular arithmetic and checks to see if it should print out a positive/negative sign when working with decimal formatting, when doing octal or hex formatting it uses bitwise arithmetic and doesn't check for whether it should print any sign. It does this despite the fact that its template arguments clearly allow it to determine whether it is dealing with signed or unsigned integers. Interestingly, while the code for iostreams doesn't actually use the printf() code, it does mimic the behavior (printf() only handles hex formatting for unsigned integers). --Chris From ddjolley at gmail.com Thu Sep 8 10:59:54 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Thu, 8 Sep 2005 13:59:54 -0400 Subject: [OCLUG-devel] Initializing Strings Message-ID: I have a textbook on C that says that in the case of this declaration: char string1[40] = "Doug"; a terminating null character is automatically added by the compiler. That doesn't seem to be the case; and, I would hope that it's not. I see the above being a simple declaration of an array of characters which may not be a string. OTOH, I would be quite happy if the compiler automatically appended a null character in this case: char string2[] = "Doug"; I think the shorthand syntax above should be applied strictly to strings and therefore the automatic addition of the terminating null character would be appropriate. Anyway, my question is, in the first case, is my textbook wrong and there is no automatically supplied null character? As I said, that appears to be the case and I hope that it is -- or, am I missing something? Thanks for any input. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050908/cdf31710/attachment.html From michael.elkins at gmail.com Thu Sep 8 11:16:19 2005 From: michael.elkins at gmail.com (Michael Elkins) Date: Thu, 8 Sep 2005 11:16:19 -0700 Subject: [OCLUG-devel] Initializing Strings In-Reply-To: References: Message-ID: <404f0322050908111621a68d08@mail.gmail.com> On 9/8/05, Doug Jolley wrote: > Anyway, my question is, in the first case, is my textbook wrong and there > is no automatically supplied null character? As I said, that appears to be > the case and I hope that it is -- or, am I missing something? >From what I remember, the textbook is correct. gcc seems to add the null character. You are initializing from a string. If you want an array of character, you can do this: char string2[40] = {'D','o','u','g'}; Although, I seem to remember that in some cases the rest of the array gets filled (or was that struct assignment?). Michael From ddjolley at gmail.com Thu Sep 8 14:17:11 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Thu, 8 Sep 2005 17:17:11 -0400 Subject: [OCLUG-devel] Initializing Strings In-Reply-To: <404f0322050908111621a68d08@mail.gmail.com> References: <404f0322050908111621a68d08@mail.gmail.com> Message-ID: Thanks for the input, Michael. Your analysis seems to be right on target. My misunderstanding of this could have caused me a lot of trouble. Fortunately, I was saved by the fact that it seems that sprintf also automatically appends a terminating null character. In fact, it appears that sprintf fills any unassigned trailing character bytes with terminating null characters. So, it all worked out for me despite my ignorance. Thanks for the help. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050908/857df0d2/attachment.html From ddjolley at gmail.com Sun Sep 11 15:26:02 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Sun, 11 Sep 2005 18:26:02 -0400 Subject: [OCLUG-devel] Runtime Libraries Message-ID: I need to do some user authentication for use on web pages and what Apache provides isn't going to do it. (Basically, I need to authenticate a user for access to a directory and then deliver a cgi web page that is dependent on who the user is. Unfortunately it's not a variation on some central theme depending on who the user is. It's a totally different page.) So, I was looking at the crypt library function. Looks pretty straight forward to me. I didn't think that I was going to have any trouble. Then, all of the sudden, I realized that crypt is a runtime library. I've never written anything that used a runtime library. So, basically my question is: Am I going to be able to handle this or am I in way over my head? Is there some way I can statically link this so that it becomes something more familiar? Thanks for any input. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050911/b83d8656/attachment.html From james at colannino.org Sun Sep 11 15:54:38 2005 From: james at colannino.org (James Colannino) Date: Sun, 11 Sep 2005 15:54:38 -0700 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: References: Message-ID: <4324B5AE.1040603@colannino.org> Doug Jolley wrote: > So, I was looking at the crypt library function. Looks pretty > straight forward to me. I didn't think that I was going to have any > trouble. Then, all of the sudden, I realized that crypt is a runtime > library. I've never written anything that used a runtime library. > So, basically my question is: Am I going to be able to handle this or > am I in way over my head? Is there some way I can statically link > this so that it becomes something more familiar? > > Thanks for any input. Doug, I might have my terminology mixed up, but I think that when you compile something even as simple as hello world, at least on Linux (and I'm sure most other *NIX variants), you're using a runtime library (glibc on Linux.) All you need to do is include the header file for crypt and use the functions it provides and the compiler will take care of dynamically linking the executable for you. If you really want to statically link it though, there's an option you can pass to gcc that will do so (I'm not sure what that is though. I'm sure someone else can help with that :) James From james at colannino.org Sun Sep 11 15:56:09 2005 From: james at colannino.org (James Colannino) Date: Sun, 11 Sep 2005 15:56:09 -0700 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: References: Message-ID: <4324B609.2050800@colannino.org> I should also mention though that depending on the library, you may have to pass an extra option to gcc. For example, I've done some ncurses programming and when you compile it you have to append '-lncurses' to your list of options. It may or may not be like that. I wouldn't know enough to know. James From ddjolley at gmail.com Mon Sep 12 17:59:35 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Mon, 12 Sep 2005 20:59:35 -0400 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: <4324B5AE.1040603@colannino.org> References: <4324B5AE.1040603@colannino.org> Message-ID: > > > > > > Doug, I might have my terminology mixed up, but I think that when you > > compile something even as simple as hello world, at least on Linux (and > > I'm sure most other *NIX variants), you're using a runtime library > (glibc on Linux.) Really. James, I'm certainly not saying that you're wrong; but, that would be news to me. > All you need to do is include the header file for > crypt and use the functions it provides and the compiler will take > care > of dynamically linking the executable for you. You have said a couple of things that interest me a lot. First, I've always wondered why it is that I can just include a header file and I seem to get the result that the whole library is included. Are you saying that glibc is automatically included? If so are there other libraries that are also automatically included? Actually, I was beginning to believe that it was the C Standard Library that was automatically included. The other thing is that I don't think that crypt is part of glibc. Does that have any effect on what you're saying? Finally, I tried your suggestion of adding a compiler option -llibcrypt. The result was a compiler complaint that llibcrypt couldn't be found. The fact that the 'l' flag was included in the complaint concerns me (i.e., why it should be looking for llibcrypt instead of just libcrypt baffles me.) I think that if I could somehow improve my understanding of libraries my whole C experience would be ratcheted up a level. Unfortunately, it seems to be a topic that most text book authors seem to want to avoid. (Maybe they don't understand it either. :) ) Anyway, thanks for the input. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050912/7bf4de91/attachment.html From x at xman.org Mon Sep 12 18:12:46 2005 From: x at xman.org (Christopher Smith) Date: Mon, 12 Sep 2005 18:12:46 -0700 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: References: <4324B5AE.1040603@colannino.org> Message-ID: <4326278E.5080003@xman.org> Doug Jolley wrote: > > > > > Doug, I might have my terminology mixed up, but I think that > when you > > compile something even as simple as hello world, at least on > Linux (and > > I'm sure most other *NIX variants), you're using a runtime library > (glibc on Linux.) > > > Really. James, I'm certainly not saying that you're wrong; but, that > would be news to me. Run "ldd" on your binary. Unless you explicitly used "-static" to link statically to your libraries, chances are you'll see that it's using the glibc runtime. > You have said a couple of things that interest me a lot. First, I've > always wondered why it is that I can just include a header file and I > seem to get the result that the whole library is included. It's because the relevant code is included in the glibc, which is automatically included provided you are compiling with gcc. gcc implies you are using C, and C isn't C without the C runtime. If you use ld directly, you need to specify all the libraries you link with. > Are you saying that glibc is automatically included? If so are there > other libraries that are also automatically included? Actually, I was > beginning to believe that it was the C Standard Library that was > automatically included. Yes. glibc is the GNU implementation of the C standard libary (with some extras). > The other thing is that I don't think that crypt is part of glibc. > Does that have any effect on what you're saying? There are two different crypt's. There's the crypt() function call, and libcrypt, which provides a variety of cryptographic functions. > > Finally, I tried your suggestion of adding a compiler option > -llibcrypt. The result was a compiler complaint that llibcrypt > couldn't be found. The fact that the 'l' flag was included in the > complaint concerns me (i.e., why it should be looking for llibcrypt > instead of just libcrypt baffles me.) You want to do "-lcrypt", the "lib" is automatically prepended. --Chris From ddjolley at gmail.com Mon Sep 12 19:34:01 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Mon, 12 Sep 2005 22:34:01 -0400 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: <4326278E.5080003@xman.org> References: <4324B5AE.1040603@colannino.org> <4326278E.5080003@xman.org> Message-ID: > > > You want to do "-lcrypt", the "lib" is automatically prepended. > That certainly seems to do the trick. Thanks a batch. Now, if I could just figure out when it is that I have to do that and when I can get by with just including the header file, I might actually be on my way to understanding this. Thanks again. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050912/4b0ec4b7/attachment.html From x at xman.org Mon Sep 12 20:57:44 2005 From: x at xman.org (Christopher Smith) Date: Mon, 12 Sep 2005 20:57:44 -0700 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: References: <4324B5AE.1040603@colannino.org> <4326278E.5080003@xman.org> Message-ID: <43264E38.4030804@xman.org> Doug Jolley wrote: > > You want to do "-lcrypt", the "lib" is automatically prepended. > > > That certainly seems to do the trick. Thanks a batch. Now, if I > could just figure out when it is that I have to do that and when I can > get by with just including the header file, I might actually be on my > way to understanding this. Thanks again. Unfortunately, this is one area where the Linux man pages are more than a bit deficient. Most commercial Unix's make it clear what headers *and* what libraries are needed for a given function. I never have been able to figure out why the Linux man pages specifically deficient in this area. --Chris From strombrg at dcs.nac.uci.edu Mon Sep 12 21:59:55 2005 From: strombrg at dcs.nac.uci.edu (Dan Stromberg) Date: Mon, 12 Sep 2005 21:59:55 -0700 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: References: <4324B5AE.1040603@colannino.org><4326278E.5080003@xman.org> Message-ID: <1126587595.19885.231.camel@seki.nac.uci.edu> On Mon, 2005-09-12 at 22:34 -0400, Doug Jolley wrote: > > You want to do "-lcrypt", the "lib" is automatically > prepended. > > That certainly seems to do the trick. Thanks a batch. Now, if I > could just figure out when it is that I have to do that and when I can > get by with just including the header file, I might actually be on my > way to understanding this. Thanks again. You might find http://dcs.nac.uci.edu/~strombrg/find-sym.html of some assistance. Or so I hope :) From ddjolley at gmail.com Tue Sep 13 09:31:43 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Tue, 13 Sep 2005 12:31:43 -0400 Subject: [OCLUG-devel] pointer from integer without a cast Message-ID: I've been playing around trying to get crypt to work. I have a little test program that I'm using which I am appending to this message. When I try to compile the test program I get a compiler warning that the assignment makes a pointer from an integer without a cast. I actually think I understand the thrust of what that message is trying to tell me. The problem is that I don't think I'm doing what it's complaining about. My understanding is that the crypt function returns a pointer to charactger. If that's the case; then, I'm assigning a pointer to a pointer and I don't understand the complaint. Any ideas on what I'm missing? Thanks for any input. ... doug - - - - - - - - - - - - - - - - - Test Program - - - - - - - - - - - - - - - #include #include int main() { char *p2epw; p2epw=crypt("blackjack","00"); printf("Encrypted PW: %s\n",p2epw); return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050913/6308c12e/attachment.html From strombrg at dcs.nac.uci.edu Tue Sep 13 10:13:59 2005 From: strombrg at dcs.nac.uci.edu (Dan Stromberg) Date: Tue, 13 Sep 2005 10:13:59 -0700 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: <43264E38.4030804@xman.org> References: <4324B5AE.1040603@colannino.org><4326278E.5080003@xman.org> <43264E38.4030804@xman.org> Message-ID: <1126631639.8228.4.camel@seki.nac.uci.edu> On Mon, 2005-09-12 at 20:57 -0700, Christopher Smith wrote: > Doug Jolley wrote: > > > > You want to do "-lcrypt", the "lib" is automatically prepended. > > > > > > That certainly seems to do the trick. Thanks a batch. Now, if I > > could just figure out when it is that I have to do that and when I can > > get by with just including the header file, I might actually be on my > > way to understanding this. Thanks again. > > Unfortunately, this is one area where the Linux man pages are more than > a bit deficient. Most commercial Unix's make it clear what headers *and* > what libraries are needed for a given function. I never have been able > to figure out why the Linux man pages specifically deficient in this area. Just a guess: Maybe because what symbols are in which libraries can vary a bit from linux to linux? From x at xman.org Tue Sep 13 10:25:53 2005 From: x at xman.org (Christopher Smith) Date: Tue, 13 Sep 2005 10:25:53 -0700 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: <1126631639.8228.4.camel@seki.nac.uci.edu> References: <4324B5AE.1040603@colannino.org> <4326278E.5080003@xman.org> <43264E38.4030804@xman.org> <1126631639.8228.4.camel@seki.nac.uci.edu> Message-ID: <43270BA1.5080501@xman.org> Dan Stromberg wrote: > On Mon, 2005-09-12 at 20:57 -0700, Christopher Smith wrote: >>Unfortunately, this is one area where the Linux man pages are more than >>a bit deficient. Most commercial Unix's make it clear what headers *and* >>what libraries are needed for a given function. I never have been able >>to figure out why the Linux man pages specifically deficient in this area. > > Just a guess: Maybe because what symbols are in which libraries can vary > a bit from linux to linux? Nope. The variance is actually very low, which is why that find symbols site can be useful. I'd argue that with the possible exception of the list of header files, the rest of the man change describes things that vary far more from Linux to Linux than the library containing a symbol. --Chris From ddjolley at gmail.com Tue Sep 13 12:17:29 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Tue, 13 Sep 2005 15:17:29 -0400 Subject: [OCLUG-devel] Runtime Libraries In-Reply-To: <4326278E.5080003@xman.org> References: <4324B5AE.1040603@colannino.org> <4326278E.5080003@xman.org> Message-ID: Thanks to all who helped me get squared away on this issue. I now understand that glibc is an extended version of the standard C library and that it is automatically included. That clears up a lot of issues for me. Thanks for the input. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050913/3e4d21a2/attachment.html From x at xman.org Tue Sep 13 13:17:29 2005 From: x at xman.org (Christopher Smith) Date: Tue, 13 Sep 2005 13:17:29 -0700 Subject: [OCLUG-devel] pointer from integer without a cast In-Reply-To: References: Message-ID: <432733D9.9060905@xman.org> Doug Jolley wrote: > I've been playing around trying to get crypt to work. I have a little > test program that I'm using which I am appending to this message. When > I try to compile the test program I get a compiler warning that the > assignment makes a pointer from an integer without a cast. I actually > think I understand the thrust of what that message is trying to tell > me. The problem is that I don't think I'm doing what it's complaining > about. My understanding is that the crypt function returns a pointer to > charactger. If that's the case; then, I'm assigning a pointer to a > pointer and I don't understand the complaint. Any ideas on what I'm > missing? > > Thanks for any input. > > ... doug > - - - - - - - - - - - - - - - - - Test Program - - - - - - - - - - - - - - - > #include > #include > int main() { > char *p2epw; > p2epw=crypt("blackjack","00"); > printf("Encrypted PW: %s\n",p2epw); > return 0; > } Try this: #define _XOPEN_SOURCE #include #include int main() { char *p2epw; p2epw=crypt("blackjack","00"); printf("Encrypted PW: %s\n",p2epw); return 0; } --Chris P.S.: As a general rule, errors like that should make you think that you don't have the right function prototype included. The trick is figuring out why. From ddjolley at gmail.com Tue Sep 13 14:33:46 2005 From: ddjolley at gmail.com (Doug Jolley) Date: Tue, 13 Sep 2005 17:33:46 -0400 Subject: [OCLUG-devel] pointer from integer without a cast In-Reply-To: <432733D9.9060905@xman.org> References: <432733D9.9060905@xman.org> Message-ID: > > > Try this: > #define _XOPEN_SOURCE It works! You know, I did try that earlier because it was mentioned in the man page. The only difference was that I put my define statement following the includes and you put before. Apparently that makes a big difference! > > > P.S.: As a general rule, errors like that should make you > > think that you don't have the right function prototype > > included. The trick is figuring out why. And by that I suspect that you're saying that somehow I have a function prototype included that's returning an integer so that when I go to assign the returned value to a pointer I get the warning that the assignment makes a pointer from an integer without a cast. You're right, the real challenge is figuring out why. Thanks for the input. Hopefully I'm off and runing now. ... doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://localhost.localdomain/pipermail/oclug-devel/attachments/20050913/791d92a1/attachment.html