Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #4545

Re: Malloc Query

Show all headers | View raw

On Mon, May 23, 2011 at 01:04:37AM +0100, Ben Bacarisse wrote:
> Uncle Steve <stevet810@gmail.com> writes:
> 
> > On Sun, May 22, 2011 at 1u1:18:36PM +0100, Ben Bacarisse wrote:
> >> Uncle Steve <stevet810@gmail.com> writes:
> >> 
> >> > On Sun, May 22, 2011 at 02:49:51AM -0700, luser- -droog wrote:
> >> >> 
> >> >> I've been using integer offsets instead of pointers a lot lately and
> >> >> I think you might be better off using the array formula explicitly:
> >> >> 
> >> >>  #define arena_obj_addr(x, n) ((void *) (x->arena + n * x->obj_size))
> >> 
> >> Everyone is taking chances here.  The x and n should be in parentheses
> >> so that the macro expands as expected.  This is one reason why functions
> >> are usually preferred.
> 
> I should also have said especially if the macro does not have an
> ALL_CAPS name flagging it's macrosity.

But as some feel here, macrosity is a vanishing distinction.  I use
all-caps macro names for constant expressions and the like.  If I
think a macro will be more readable in lower-case, I'll do just that.
Shouted macro definitions interrupt the flow of source text when a
human is reading it, and I don't think I need that kind of distraction
in the code as much as some do.
 
> > For a long time I've thought macros were preferable to functions for
> > the reason that a function call has to save registers, stuff it's arguments on the
> > stack, and so on.  Macros should just fold into the program text,
> 
> They should, but the onus is on the programmer to make that reasonable
> (and where there are side effects in the expressions used in the macro
> "call" this may not be possible). 
> 
> > but
> > today inline functions are just as fast as macros.
> 
> Yes, using an inline function is better yet.  You seemed dead against
> them which is why I commented on the macro.  Use a function and the
> issue disappears.

I'm not "dead against" function calls for simple things.  I'm merely
predisposed against them.
 
> >  It has become a
> > matter of preference.  gcc even has the ability to use register
> > calling conventions for function calls in some circumstances.  The
> > distinction between a macro and a function call is becoming moot.
> 
> I don't see how you can say that.  The speed advantage that used to be
> one of the main reasons to take the risk with macros has gone, but all
> the potential bugs that function-like macros can hide are still there.

Sorry, I should say 'moot' in consideration of the now historic
performance advantage of macros over function calls.  In reality,
function calls /are/ slower than macro instances but the compiler
masks this when it inlines a function by omitting function preamble
and jinking the basic blocks of code to flow together as if they were
part of the immediate text.  

> >> <snip>
> >> > #define ARENA_TYPE	struct foo
> >
> >> > struct arena_s {
> >> >    size_t        arena_size;
> >> >    int           free_list;
> >> >    size_t        free;
> >> >    ARENA_TYPE *  arena;
> >> > };
> >> >
> >> > And your access macro becomes:
> >> >
> >> > #define arena_obj_addr(x, n)   &x->arena[n]
> >> 
> >> Here the [n] is OK, but why risk it with x?  The (x) costs nothing and,
> >> I think, saves time reading the macro since the reader does no have to
> >> start worrying about what might be passed.
> >
> > No worries here.  I've edited for brevity in posting, but I always
> > protect macro arguments from side-effects these days.  It doesn't look
> > as clean and concise, which is why I omitted those statements from
> > example code.  No biggie.
> 
> OK.  I'll try to remember to assume any errors in future code were added
> for brevity and I'll save time by not commenting on it.

Please do.  I find it's the cut-and-paste-modify step that introduces
errors into program code more so than writing it in the first place.
 
> > In this newsgroup is it really preferable to see 
> >
> > #define arena_object_addr(x, n) ({	\
> >    struct arena_s X = x;		\
> >    int N = n;				\
> >    *X->arena[N]; })			\
> >
> > for every dumb example that is posted?
> 
> The correct version of the macro is simpler than the one you seem to
> think you'd write to make it safe.  Why would you write the above (it's
> wrong, so it's obviously not what you really use) instead of
> 
>  *(x)->arena[n]

That's only correct if the macro is a simple one-liner.  If (x) is
used more than once and has side-effects, such as in (x++), you're
toast.
 
> ?  Also, why would you use a non-standard feature when it's not needed?  There
> might be a reason to use ({...}) when a macro parameter is used more
> than once that's not the case here.  I suppose if you know you'll never
> use another compiler, tying code to language extensions is not a problem.

I'm a creature of habit, I guess.  Note that while I didn't learn C
under gcc, it's about the only compiler I've used in the last
seventeen years.  Consequently, avoiding its extensions is not an
automatic process.  I'm making an effort to avoid non-portable code,
but it is slow going.
 
> >  Possibly not if people can be
> > reminded that all code posted in comp.lang.c is generally intended as
> > an example.
> 
> One of the bug-bears of Usenet is "oh that's not the real code".  This
> translates to "you've just wasted your time".  I'd vote for real code
> (at the last code that's gone though a compiler) every time.

I look at the majority of the example code posted in Usenet messages
as being contrived for the purposes of demonstration.  When I was a
total noob, comp.sources.unix and a few others were places where real
code was made available to Usenet readers.  So called real code is no
longer posted to newsgroups.  I'm not ecstatic that my contrived
examples are not perfect, but the alternative is to post my 'real
code' and annoy people who would prefer the exemplar pared down to the
bare minimum.

The arena allocator I've been on about is instantiated as a .h file
and is over 500 lines of code at this time.  It carries with it all
the 'baggage' of my development environment and would make the
discussion of its data structures and algorithm very awkward.  A
reasonable compromise would be to ensure that posted code compiles
and works as expected, but even than that won't correct for all
possible errors:  note that I buggered up the for() loop in the
arena_creat() function without triggering the error during testing.

I'll endeavor to post better code in subsequent messages, but it is
not always practical to test quick one-off constructs completely when
so many things compete for my (and your) time.  I suppose I might
sound more intelligent and authoritative if my messages never
contained errors, but then I might never post at all if that were a
basic prerequisite for Usenet participation.  Somewhere there is a
happy medium that will satisfy everyone here.  I'll look more closely
for it. :)



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-17 19:39 +0000
  Re: Malloc Query blp@cs.stanford.edu (Ben Pfaff) - 2011-05-17 12:55 -0700
    Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 12:05 +0100
      Re: Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-18 17:11 +0000
        Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:42 +0100
        Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:10 -0400
      Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 19:34 +0100
        Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 17:10 -0400
          Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 00:26 +0100
            Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 21:25 -0400
              Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-18 21:38 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:11 -0400
                Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-19 22:55 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:14 -0400
              Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 03:22 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:20 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 23:51 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 20:01 -0400
                Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-22 02:49 -0700
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:46 -0400
                Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 12:37 -0500
                Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 13:02 -0500
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 14:12 -0400
                Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-23 03:06 -0500
                Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:42 -0700
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:10 -0400
                Re: Malloc Query Keith Thompson <kst-u@mib.org> - 2011-05-23 09:06 -0700
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-22 23:18 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 19:18 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 11:22 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 01:57 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 19:24 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 14:20 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 07:41 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 16:24 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:20 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 18:05 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:37 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:34 -0400
                Re: Malloc Query "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:48 -0700
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 12:56 +1200
                Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:19 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-24 11:32 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 01:04 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 02:36 -0400
                Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:39 -0700
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 14:44 +0100
                Re: Malloc Query Seebs <usenet-nospam@seebs.net> - 2011-05-23 15:16 +0000
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:41 -0400
                Re: Malloc Query David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 18:34 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 02:36 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:26 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 23:32 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 21:17 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-21 14:30 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 11:13 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 08:50 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 20:03 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 13:23 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:01 -0400
                Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-26 08:12 +0200
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-26 19:16 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:03 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:16 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 17:55 -0400
                Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-27 05:47 +0200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:02 -0400
        Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:31 +0100
          Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 23:37 +0100
            Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 01:50 +0100
              Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 02:50 +0100
                Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 12:14 +0100
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 15:10 +0100
                Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 15:48 +0100
      Re: Malloc Query cri@tiac.net (Richard Harter) - 2011-05-18 19:31 +0000
      Re: Malloc Query Ike Naar <ike@iceland.freeshell.org> - 2011-05-18 21:43 +0000
        Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:58 +0100
  Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-17 14:01 -0600
  Re: Malloc Query Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-17 13:21 -0700
  Re: Malloc Query BGB <cr88192@hotmail.com> - 2011-05-17 14:08 -0700
    Re: Malloc Query Michael Press <rubrum@pacbell.net> - 2011-05-17 19:49 -0700
  Re: Malloc Query Lauri Alanko <la@iki.fi> - 2011-05-18 00:50 +0000
  Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-17 21:21 -0400
    Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-18 19:31 +0200
    Re: Malloc Query Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-18 21:36 +0000
      Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:26 -0400
    Re: Malloc Query Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 02:07 -0700
      Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-19 21:13 +1200
  Re: Malloc Query Nobody <nobody@nowhere.com> - 2011-05-18 07:08 +0100
  Re: Malloc Query David Resnick <lndresnick@gmail.com> - 2011-05-19 07:51 -0700
    Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-19 09:12 -0600

csiph-web