ark@alice.UUCP (Andrew Koenig) (01/30/90)
In article <22169@mimsy.umd.edu>, chris@mimsy.umd.edu (Chris Torek) writes: > putc *is* *documented* as not being careful about its second parameter. > If you do not like this, too bad: Every vendor has a right to use this > parameter several times in the macro expansion of putc(). Mistake or > not, we are stuck with it. Has anyone out there actually written a program that depends for its correct operation on side effects of the second argument of putc? I can see it for the first argument, but the second? -- --Andrew Koenig ark@europa.att.com
evil@arcturus.UUCP (Wade Guthrie) (02/07/90)
chris@mimsy.umd.edu (Chris Torek) writes: > putc *is* *documented* as not being careful about its second parameter. ark@alice.UUCP (Andrew Koenig) writes: >Has anyone out there actually written a program that depends >for its correct operation on side effects of the second >argument of putc? Sorry, but what are the side effects of the second argument of putc? Wade Guthrie evil@arcturus.UUCP Rockwell International Anaheim, CA (Rockwell doesn't necessarily believe / stand by what I'm saying; how could they when *I* don't even know what I'm talking about???)
ark@alice.UUCP (Andrew Koenig) (02/07/90)
In article <7172@arcturus>, evil@arcturus.UUCP (Wade Guthrie) writes: > > chris@mimsy.umd.edu (Chris Torek) writes: > > putc *is* *documented* as not being careful about its second parameter. > > ark@alice.UUCP (Andrew Koenig) writes: > >Has anyone out there actually written a program that depends > >for its correct operation on side effects of the second > >argument of putc? > > Sorry, but what are the side effects of the second argument of putc? Putc takes two arguments: a charcter to write and a FILE* that represents where to write it. The following has an undefined effect: putc(c,*fp++); This one, though, is well-defined: putc(*cp++,f); So my question is: are there any people out there who have ever written programs in which they wanted to take advantage of the second argument of putc needing to be evaluated exactly once? -- --Andrew Koenig ark@europa.att.com
brnstnd@stealth.acf.nyu.edu (02/08/90)
In article <22169@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > In article <25929@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu writes: > > extern FILE *_mAcVaR_putc_f; > > #define safeputc(c,f) ( (_mAcVaR_putc_f = f), putc(c,_mAcVaR_putc_f) ) > >safeputc, like fputc, uses non-local variables, so neither one can be > >used twice at once safely (e.g., in a signal handler). ... > > But, unlike fputc, safeputc is not safe under the following condition: Unfair. The stdio documentation doesn't mention any caveat for fputc, and you're explaining a situation where this problem doesn't happen? As I claimed, safeputc has the same effect as fputc, unless the stream is used in a signal handler. > a. You ensure that malloc blocks signals. How? Without cooperation from the signal handlers you can't hold signals and release them later. > b. You have a signal handler that opens a file, uses `safeputc', > then closes the file. > c. Your main program uses `safeputc'. Okay. To solve this ``problem,'' safeputc must use a local variable. Expressions can't (in standard C) contain blocks, so without inline functions this is impossible. > putc *is* *documented* as not being careful about its second parameter. It's wonderful that this mistake is documented. It's still a mistake. ---Dan
bill@twwells.com (T. William Wells) (02/10/90)
In article <670@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
: It's wonderful that this mistake is documented. It's still a mistake.
I have this little meter; it says "don't connect to over 10,000V"
on it.
"It's wonderful that this mistake is documented. It's still a mistake."
What horseshit!
Tools are designed for human purposes. Sometimes those purposes
conflict, or can't be simultaneously accomplished by a single
tool. (hah!) In that case, we make more than one tool and note the
limitations of each.
In the case of putc/fputc, there are two purposes: efficiency on
the one hand and all the benefits of a function on the other.
If you can't stand the limitations of the more efficient tool
DON'T USE IT.
But if you tell me not to, I'll just say (deep breath, expunge the
four letter words): you are not in any position to dictate to me
my choices for programming. *I* know what I'm doing and you are,
by your suggestion, making yourself look like an ignorant lout.
Now go away while I continue to use putc, safely, just like I
have for the past seven years.
---
Bill { uunet | novavax | ankh } !twwells!bill
bill@twwells.comwoody@rpp386.cactus.org (Woodrow Baker) (02/11/90)
In article <1990Feb9.214044.26382@twwells.com>, bill@twwells.com (T. William Wells) writes: > In article <670@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: > : It's wonderful that this mistake is documented. It's still a mistake. > > I have this little meter; it says "don't connect to over 10,000V" > on it. > > "It's wonderful that this mistake is documented. It's still a mistake." > > What horseshit! > > > If you can't stand the limitations of the more efficient tool > DON'T USE IT. > > my choices for programming. *I* know what I'm doing and you are, > by your suggestion, making yourself look like an ignorant lout. And you, are making yourself look like an arrogant lout. > Now go away while I continue to use putc, safely, just like I > have for the past seven years. > Jumpin' willies, this one has SHARK teeth...(pun intended) Do you have sandpaper for hide? Give the guy a break!
dan@charyb.COM (Dan Mick) (02/12/90)
In article <17912@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: |In article <1990Feb9.214044.26382@twwells.com>, bill@twwells.com (T. William Wells) writes: |> |> If you can't stand the limitations of the more efficient tool |> DON'T USE IT. |> |> my choices for programming. *I* know what I'm doing and you are, |> by your suggestion, making yourself look like an ignorant lout. | |And you, are making yourself look like an arrogant lout. | |> Now go away while I continue to use putc, safely, just like I |> have for the past seven years. |> |Jumpin' willies, this one has SHARK teeth...(pun intended) |Do you have sandpaper for hide? Give the guy a break! Oh, bullshit. This tempest-in-teapot about not being able to use putc with a second argument with side effects is *stupid*, and Bill was calling it stupid. "The guy" has had about six breaks, as he hasn't been flamed for the first six times he's posted this idiotic whine, and Bill finally lost his temper (about a millisecond before I lost mine). Listen to the argument, and don't respond to a flame simply to be a cotton- wool sweetie-pie, and don't *bother* telling folks to calm down, ESPECIALLY not in public!