Xref: utzoo comp.sources.wanted:15331 alt.sources.wanted:942 comp.lang.c:36260 Path: utzoo!utgpu!cs.utexas.edu!yale!mintaka!bloom-picayune.mit.edu!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.sources.wanted,alt.sources.wanted,comp.lang.c Subject: Re: What is strdup() supposed to do? Does anyone have a copy? Message-ID: Date: 19 Feb 91 06:54:21 GMT References: <1991Feb17.045913.17126@sbcs.sunysb.edu> <1991Feb17.164731.7564@onion.rain.com> <1991Feb18.154159.430@persoft.com> <1991Feb19.004526.16033@onion.rain.com> Sender: news@athena.mit.edu (News system) Followup-To: comp.lang.c Organization: Massachusetts Institute of Technology Lines: 75 In-Reply-To: jeff@onion.rain.com's message of 19 Feb 91 00:45:26 GMT (Note the Followup-To.) In article <1991Feb19.004526.16033@onion.rain.com> jeff@onion.rain.com (Jeff Beadles) writes: In <1991Feb18.154159.430@persoft.com> dag@persoft.com (Daniel Glasser) writes: > [he asks why the temporary char *ret inside strdup is declared static] A creature of habit, I suppose. I've been bitten too often when I return something from a function that isn't static. (int's, for example.) For this case, it really doesn't matter. I would suggest that if you can't tell the difference between a value that is safe to return from a function, and a value that is not, you're better off letting other people post code to the net. I posted a working version of strdup() the same day the question was asked, and yet we have all these people posting inferior versions (That's not my ego speaking, for all of you who are getting ready to pounce on your "F" key for flaming me about saying, "My code is better than yours!" That's just simple fact. The version I posted had no errors; if you think it did, feel free to point them out.). Yes, I know there are lags in news transmission, and it's quite possible that you didn't see my posting before posting yours. I wouldn't be mentioning the duplication at all if it weren't for the fact that your code was wrong. You should not declare variables static when they don't have to be static. Code which declares a variable static when that variable has absolutely no reason whatsover to be static is wrong. It's kinda like the braces around the malloc failure. They're not technically required, but it's not a bad habit. :-) Braces around a one-line "if" block are good programming because they don't affect the compiled code, and because they will save you from problems if you change things later so that there is more than one statement in the body of the "if," and because if the statement is actually a macro that has multiple statements in it, the braces protect you from any dangerous results. On the other hand, declaring a variable static when it doesn't have to be *does* affect the compiler output, by keeping a variable in memory all the time when it doesn't have to be. Furthermore, unless you plan to seriously change the functionality of strdup() at some point in the future, there is no chance that that variable will ever need to be static, so there is no "preventative" excuse to make it static. >Nit #2: You should simplify your expression in the "malloc()", that is, > sizeof(char) * strlen(foo) + sizeof(char) > could be written > sizeof(char) * (strlen(foo) + 1) Untrue. What if sizeof(char) != 1? Yours will break, and mine will work. You're wrong. Both expressions above will result in the proper value, whether sizeof(char) is 1 or not. Your expression takes the number of characters in the string, multiplies it by the size of a character, and adds the size of a character. The other suggested expression takes the number of characters in the string, adds 1 to it, and multiples the result by the size of a character. The fact that these will result in the same value should be obvious. And, incidentally, I agree with the previous poster that the latter expression is clearer than the former. I'm sorry if I'm coming down a bit hard on you. I guess I'm taking out on you all the frustration I've been feeling for the past three days, watching people post wrong or incomplete answers to a solved problem with the solution has already been posted. It's a bit irritating. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710