On Wed, Dec 20, 2000 at 11:03:48AM +1030, Greg Lehey wrote:
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote:
On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote:
/* Case 1 */ /* Case 2 */
if (data) vs.
On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote:
/* Case 1 */ /* Case 2 */
if (data) vs. free(data)
free(data);
Actually from an optimization standpoint, #1 can be worse (ie, harder on
the processor).
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote:
On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote:
/* Case 1 */ /* Case 2 */
if (data) vs. free(data)
free(data);
Actually from an
In message [EMAIL PROTECTED], Greg Lehey writes:
In which processors is a function call anywhere near as cheap as a
conditional local branch?
Doesn't PPC have some cases where a leaf function is basically free?
-s
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote:
On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote:
/* Case 1 */ /* Case 2 */
if (data) vs. free(data)
free(data);
Actually
Guys, on intel a simple conditional is going to be a whole lot
expensive then a subroutine call no matter what, even if the
conditional misses. Subroutine calls are very fast on a P6, but
if they push anything on the stack at all beyond the return address they
are not going
:Guys, on intel a simple conditional is going to be a whole lot
:expensive then a subroutine call no matter what, even if the
I'm really batting 0 today on grammer. I of course meant... "whole
lot LESS expensive". :-)
-Matt
To
On Tue, Dec 19, 2000 at 06:36:06PM -0600, Peter Seebach wrote:
In message [EMAIL PROTECTED], Greg Lehey writes:
In which processors is a function call anywhere near as cheap as a
conditional local branch?
Doesn't PPC have some cases where a leaf function is basically free?
Maybe, but
On Tue, Dec 19, 2000 at 04:01:52PM -0800, David O'Brien wrote:
On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote:
/* Case 1 */ /* Case 2 */
if (data) vs. free(data)
free(data);
Actually from an
On Sun, Dec 17, 2000 at 10:01:58PM -0700, Warner Losh wrote:
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes:
: I hate to give up a line for
:
: if (data)
: free(data);
:
: but neither do I care for ``if (data) free(data);''. I guess if I
: were writing
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes:
: None taken. It is however a simple and safe optimization, with no
: apparent downsides. It has the same attraction as using bit shifts
: instead of multiplication/division, or saving the value from a function
: call that will be needed
:: None taken. It is however a simple and safe optimization, with no
:: apparent downsides. It has the same attraction as using bit shifts
:: instead of multiplication/division, or saving the value from a function
:: call that will be needed again later, even if you know the function call
:: is
"Jacques A. Vidrine" wrote:
I doubt that you could measure any difference between
if (foo) free(foo);
and free(foo);
Nevertheless, I tend to write it that way at times -- maybe because it
seems so natural to me to ask `do I need to free this thing?' -- and
that gets translated
On Mon, Dec 18, 2000 at 11:40:43AM -0700, Warner Losh wrote:
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes:
: None taken. It is however a simple and safe optimization, with no
: apparent downsides. It has the same attraction as using bit shifts
: instead of
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes:
: Ever notice that you tend to send more email when you should be studying
: for a final?
That's why Style(9) wars break out this time of year. :-)
: /* Case 1 */ /* Case 2 */
: if (data)
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
/* Case 1 */ /* Case 2 */
if (data) vs. free(data)
free(data);
I don't see that Case 1 obfuscates anything. In some cases I find it
clearer: Case 1 implies that
[This typo came from NetBSD, so in this particular source I have no
intention of changing the style.]
What do folks think about
1)if (data)
free(data);
versus
2)free(data);
versus
3)#define xfree(x) if ((x) != NULL) free(x);
xfree(data);
--
On Sun, 17 Dec 2000, Chris Costello wrote:
On Sunday, December 17, 2000, Jacques A. Vidrine wrote:
What do folks think about
1)if (data)
free(data);
versus
2)free(data);
versus
3)#define xfree(x) if ((x) != NULL) free(x);
On Sun, Dec 17, 2000 at 03:17:35PM -0600, Chris Costello wrote:
2. The C standard dictates that free() does nothing when it
gets a NULL argument.
Well, it dictates that free(NULL) is safe -- it doesn't dictate that
it ``does nothing''. Which brings me to my next comment:
The other
On Sun, Dec 17, 2000 at 03:36:56PM -0600, Chris Costello wrote:
On Sunday, December 17, 2000, Jacques A. Vidrine wrote:
It would be silly to optimize for freeing NULL pointers.
You mean as seen in:
[snip ifree(), which checks for a NULL pointer, first thing]
called by free():
On Sun, Dec 17, 2000 at 04:04:42PM -0600, Chris Costello wrote:
On Sunday, December 17, 2000, Jacques A. Vidrine wrote:
I may have missed your point ... or maybe you are just agreeing with
what I wrote. For this particular implementation of free, you get the
following for `free(foo)'
"Jacques A. Vidrine" [EMAIL PROTECTED] writes:
What do folks think about
1)if (data)
free(data);
versus
2)free(data);
versus
3)#define xfree(x) if ((x) != NULL) free(x);
xfree(data);
(2), unless you can show that you actually win
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes:
: What do folks think about
:
: 1)if (data)
: free(data);
:
: versus
:
: 2)free(data);
:
: versus
:
: 3)#define xfree(x) if ((x) != NULL) free(x);
: xfree(data);
Number 2. ANSI-C (aka c89)
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes:
: I hate to give up a line for
:
: if (data)
: free(data);
:
: but neither do I care for ``if (data) free(data);''. I guess if I
: were writing several statements like that in a single file, I would
: consider the
In message [EMAIL PROTECTED], Warner Losh writes:
Number 2. ANSI-C (aka c89) requires that free(NULL) work. We
shouldn't go out of our way to pander to those machines where it
doesn't.
The reason why this is so is that it is legal for
realloc(ptr, 0):
to return either a NULL pointer
25 matches
Mail list logo