Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: blmblm@myrealbox.com Newsgroups: comp.programming.threads Subject: Re: Is pthread_create( id, 0, f, &something_on_my_stack ); safe? Date: 25 Nov 2011 17:49:13 GMT Organization: None Lines: 39 Message-ID: <9ja2ooFmj4U2@mid.individual.net> References: <4EC9C581.405E@2ndquadrant.com> <4ecad9c6$0$6961$e4fe514c@news2.news.xs4all.nl> X-Trace: individual.net Y1E1gTciun4VrHK74X/oHQaYjmzSQ8w6ykF9JoIX0p9XDlRoIx X-Orig-Path: not-for-mail Cancel-Lock: sha1:0EwLun/S44i3wgg+w6AnkOImy9w= X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:689 In article <4ecad9c6$0$6961$e4fe514c@news2.news.xs4all.nl>, Casper H.S. Dik wrote: > Johann 'Myrkraverk' Oskarsson writes: > > >David Schwartz writes: > > >> On Nov 20, 11:56 pm, Johann 'Myrkraverk' Oskarsson > >> wrote: > >> > >>> Unfortunately, the numbers are retrieved in a loop. To be extra > >>> ex- plicit, file descriptors from accept(), pipe() and friends. I > >>> can't see any way that does not involve either 1) memory > >>> allocation/freeing or 2) synchronization. Both seem unnecessary > >>> code bloat for such a simple task. > >> > >> Here are the choices you have rejected: > > >I did not reject them. Both apply code overhead (as in, I write more > >code) I have to maintain. The more code I can get rid of the better. > > > If it's only one fd, cast it to a pointer and use the pointer as an > integer; there is really no reason to interpret the pointer as a > pointer, right? > There was a discussion of this topic in comp.lang.c recently: http://groups.google.com/group/comp.lang.c/browse_thread/thread/9ce104bbf47d3fbc/c96cd19501ef372b?hl=en&q=#c96cd19501ef372b I'm not sure it reached consensus, but the arguments against this "use the pointer parameter to pass an integer" approach seemed to boil down to "not guaranteed to work on all platforms" and "likely to confuse other readers of the code". To me the latter alone is a good reason to avoid it, but -- . -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.