Re: Hey, could someone critique a little app I did?
R. Brock Lynn wrote: How do I effectively use getopt? BUGS This manpage is confusing. Do as in the example written in the manpage. It explains the usage much better than any words (if you ignore the _long parts). If you rather read words, read the info page (getopt is documented in glibc info pages), but I find that reading code is much easier.. Basic idea: You call getopt() to find out the next option on the command line. getopt() returns EOF when there is no more options. Any option argument is returned in char *optarg. The syntax for the options-string sent to getopt() is char A "toggle" (no argument) char: Argument required char::Argument allowed but not required (optarg NULL if no argument) Example: "ab:c::" accepts -a# no argument -b something # requires a argument -c [something]# argument not required --- Henrik Nordström
Re: Hey, could someone critique a little app I did?
holotko wrote: But for testing null pointers, I use `!'. In this context, it seems BAD. I worked in envinronments where NULL is ((void *)-1UL). If you use ! to check for a NULL pointer you make your code not portable. What is the best, all round "most portable" means of testing for a null pointer?? Using `!p' is sufficient. If you use `p != NULL', you need to include stdio.h to ensure that NULL is defined, which is kind of overkill if you're not using anything else from stdio.h. -- Glynn Clements [EMAIL PROTECTED]
Re: Hey, could someone critique a little app I did?
On Thu, 28 May 1998, Pete Ryland wrote: see http://www.eskimo.com/~scs/C-faq/s5.html for info on the NULL pointer. Thanks a lot for the pointer, I found it very interesting. An interesting page is also: http://www.eskimo.com/~scs/C-faq/q5.17.html where there are listed many machines that use NULL as (void *) but where the kernel assure a page fault at a not ZERO virtual address. Andrea[s] Arcangeli
Re: Hey, could someone critique a little app I did?
Andrea Arcangeli wrote: On Mon, 25 May 1998, Glynn Clements wrote: But for testing null pointers, I use `!'. In this context, it seems BAD. I worked in envinronments where NULL is ((void *)-1UL). If you use ! to check for a NULL pointer you make your code not portable. What is the best, all round "most portable" means of testing for a null pointer?? -- email: [EMAIL PROTECTED] Local mailserver landreau.ruffe.edu , remote ns.computer.net Nothing like being lost on a desolate beach, riding on a wave with a mermaid on a hot summer day.
Re: Hey, could someone critique a little app I did?
On Thu, 28 May 1998, Pete Ryland wrote: ok - this is often confused. the c faq has a *big* section on this... NULL should be defined as 0. Ok. 0 cast to a pointer type is defined as an undefined pointer and can be implemented by the compiler as any number (including -1, or something This sound me a little strange. I think that if I use (void *)0 the compiler must use 0 not -1. If ANSI-C declare that a NULL pointer is a (void *)0 is another story. I' d like if somebody could confirm that I am wrong. will give the same results on any system that is ANSI-C. There are no problems with portability, even on systems that have non-zero null pointers. Ok, I understood this and this is not more an issue at least for me. Andrea[s] Arcangeli
Re: Hey, could someone critique a little app I did?
see http://www.eskimo.com/~scs/C-faq/s5.html for info on the NULL pointer. summary of this: 5.1 there is a special value--the ``null pointer''--which is distinguishable from all other pointer values and which is ``guaranteed to compare unequal to a pointer to any object or function.'' 5.2 ``0'' in a pointer context is converted into a null pointer at compile time. 5.3 if(p) is equivalent toif(p != 0) 5.4 the preprocessor macro NULL is #defined (by stdio.h or stddef.h) with the value 0, possibly cast to (void *) 5.5 it is the compiler's responsibility to generate whatever bit pattern the machine uses for that null pointer. Therefore, #defining NULL as 0 on a machine for which internal null pointers are nonzero is as valid as on any other 5.6 there are machines which use different internal representations for pointers to different types of data 5.9 If NULL and 0 are equivalent as null pointer constants, which should I use? ... There is no one right answer. ... NULL should not be used when another kind of 0 is required, ... do not use NULL when the ASCII null character (NUL) is desired. 5.10 NULL is used only as a stylistic convention ... 5.14 The construct ``if(p == 0)'' is easily misread as calling for conversion of p to an integral type, rather than 0 to a pointer type, before the comparison ... I hope this helps clear this one up a bit... Pete (Confused yet? :) On Wed, 27 May 1998, Andrea Arcangeli wrote: On Thu, 28 May 1998, Pete Ryland wrote: ok - this is often confused. the c faq has a *big* section on this... NULL should be defined as 0. Ok. 0 cast to a pointer type is defined as an undefined pointer and can be implemented by the compiler as any number (including -1, or something This sound me a little strange. I think that if I use (void *)0 the compiler must use 0 not -1. If ANSI-C declare that a NULL pointer is a (void *)0 is another story. I' d like if somebody could confirm that I am wrong. will give the same results on any system that is ANSI-C. There are no problems with portability, even on systems that have non-zero null pointers. Ok, I understood this and this is not more an issue at least for me. Andrea[s] Arcangeli Pete Ryland Home phone: +61 2 9697 9262 Mobile: 014 035 802 email: [EMAIL PROTECTED] ICQ UIN: 4256333 WWW: http://www.pdr.ml.org ftp: ftp.pdr.ml.org
Re: Hey, could someone critique a little app I did?
On Mon, 25 May 1998, Pete Ryland wrote: Don't be fooled! Just because it looks smaller in your c source, it doesn't mean it'll be faster. It *should* generate the same code, so the Heheheheh it' s faster to type ;-). This should be the only reason ! is been implemented in C and I take advantage of it. only reason to use one way over another is code readability. IMHO, I think that Glynn's code is more readable, since it helps you realise that the condition will be true if the strings are equal. Similarly for checking of error conditions or null pointers, I think that a compare with NOTE NOTE NOTE a lot of people think that NULL is is (void *) 0. This is false. NULL is a page not allocated in the TLB. We can' t use ! for NULL pointers since we must always use == NULL or != NULL. I didn' t want to say that. zero makes c code much more readable. (of course this is just my 2c which ain't worth much since the smallest unit of currency here is 5c :) Can you explain why you think it is "nicer", please? I like more ! that == 0, looks me more pretty, nothing more, but this is very personal... Andrea[s] Arcangeli
Re: Hey, could someone critique a little app I did?
On Mon, 25 May 1998, Glynn Clements wrote: But for testing null pointers, I use `!'. In this context, it seems BAD. I worked in envinronments where NULL is ((void *)-1UL). If you use ! to check for a NULL pointer you make your code not portable. Andrea[s] Arcangeli
Re: Hey, could someone critique a little app I did?
Andrea Arcangeli wrote: But for testing null pointers, I use `!'. In this context, it seems BAD. I worked in envinronments where NULL is ((void *)-1UL). That's _really bad_. ANSI C requires stdio.h to define NULL as being equivalent to zero. If you use ! to check for a NULL pointer you make your code not portable. Using ! to check for a NULL pointer is entirely portable. -- Glynn Clements [EMAIL PROTECTED]
Re: Hey, could someone critique a little app I did?
Pete Ryland wrote: On Sat, 23 May 1998, Glynn Clements wrote: Personally, I avoid using `!strcmp(...)'; I find `strcmp(...) == 0' to be more intuitive. __Personally__ I like the opposite ;-). I always use ! when I can. It' s faster and nicer. Don't be fooled! Just because it looks smaller in your c source, it doesn't mean it'll be faster. It *should* generate the same code, so the only reason to use one way over another is code readability. IMHO, I think that Glynn's code is more readable, since it helps you realise that the condition will be true if the strings are equal. Similarly for checking of error conditions or null pointers, I think that a compare with zero makes c code much more readable. (of course this is just my 2c which ain't worth much since the smallest unit of currency here is 5c :) When checking for error (i.e. non-zero) returns from library functions, I use `... != 0' (or `... == -1' if there are non-zero return codes which don't indicate an error). But for testing null pointers, I use `!'. In this context, it seems reasonable (to me) to treat the value as a boolean, i.e. NULL == false, non-NULL == true. -- Glynn Clements [EMAIL PROTECTED]
Re: Hey, could someone critique a little app I did?
On Sun, 24 May 1998, Andrea Arcangeli wrote: On Sat, 23 May 1998, Glynn Clements wrote: Personally, I avoid using `!strcmp(...)'; I find `strcmp(...) == 0' to be more intuitive. __Personally__ I like the opposite ;-). I always use ! when I can. It' s faster and nicer. Don't be fooled! Just because it looks smaller in your c source, it doesn't mean it'll be faster. It *should* generate the same code, so the only reason to use one way over another is code readability. IMHO, I think that Glynn's code is more readable, since it helps you realise that the condition will be true if the strings are equal. Similarly for checking of error conditions or null pointers, I think that a compare with zero makes c code much more readable. (of course this is just my 2c which ain't worth much since the smallest unit of currency here is 5c :) Can you explain why you think it is "nicer", please? Andrea[s] Arcangeli Pete Pete Ryland Home phone: +61 2 9697 9262 Mobile: 014 035 802 email: [EMAIL PROTECTED] ICQ UIN: 4256333 WWW: http://www.pdr.ml.org ftp: ftp.pdr.ml.org
Re: Hey, could someone critique a little app I did?
On Wed, 20 May 1998, R. Brock Lynn wrote: It is supposed to generate random integers in a certain range specified by two endpoints inclusive. i.e.: randomit 10 100 will send to stdout a random long int between 10 and 100. should work for negative numbers too. My code is included. Please give me some comments! There is one little problem that I have run into before srand ( time ( 0 ) ) ; initializes the random number generator with the current time - and the time is measured in seconds. This means that if you call randomit two times during one second, you get the same random number. You should, probably, use srand(times(0)); times(0) returns the number of clock ticks since system was brought up, and ``a tick'' seems to be one hundredth of a second. Andreas
