how to find number of bytes freed

[Ian Collins]

How about ``syntax error before "size_t"'' if your (pre-C99) compiler
doesn't recognize the "inline" keyword?

Yes, most pre-C99 compilers probably do support inline as an extension
(and of course any C99 compiler must support it), but just the other
day you told somebody that he *must* place all his declarations before
statements in a block.

And most, if not all, c99 compilers would inline the function whether or
not the "inline" keyword was present.

 

[CBFalconer]

.... snip ...

And most, if not all, c99 compilers would inline the function
whether or not the "inline" keyword was present.

Oh? Is that legal?

 

[Ian Collins]

Ian Collins wrote:
.... snip ...

Oh? Is that legal?

Can you either cite a reference where it's disallowed or a reason why it
shouldn't be legal?

 

[santosh]

Oh? Is that legal?

With the provision of the "as if" rule, it is. The compiler can
*anything* it wants, provided the semantics of the C abstract machine
are respected (in conforming mode of course), and a conforming program
cannot detect such gyrations. Inlining a function in C90 mode is one
such example. If the address of the function is taken or if it is not
declared static, then a complete copy of the function image will also
be introduced into the object file.

 

[Richard]

Oh? Is that legal?

Why shouldn't it be? You keep crying about how there is no stack in the
standards - why on earth shouldn't the compiler inline ALL functions if
it so chose?

 

[CBFalconer]

Can you either cite a reference where it's disallowed or a reason
why it shouldn't be legal?

Rather hard to take a pointer to an inlined function.

 

[Chris M. Thomasson]

True! I usually pick the alignment that matches the machine.

This is generally the lowest multiple of the alignment of long long
greater or equal to the alignment of long double.

FWIW, here is how I "attempt" to detect "smallest" maximum alignment;
welcome to hack world!:

http://groups.google.com/group/comp.lang.c/msg/be7e0d0e97c5e1d9

http://groups.google.com/group/comp.lang.c/browse_frm/thread/6fc4da438e08028b

The offsetof macro-function works perfectly within this particular
approach...


Any thoughts? Can I improve the technique?

;^/

 

[vippstar]

FWIW, here is how I "attempt" to detect "smallest" maximum alignment;
welcome to hack world!:

http://groups.google.com/group/comp.lang.c/msg/be7e0d0e97c5e1d9

That code doesn't work.

from that post:

unsigned char* rawbuf[(SUPERBLOCK_SIZE * 2) - 1];

(Where SUPERBLOCKSIZE is 4096 * 8)
It exceeds environmental limits, thus all compilers can refuse to
compile it.

<snip>

 

[Chris M. Thomasson]

FWIW, here is how I "attempt" to detect "smallest" maximum alignment;
welcome to hack world!:

http://groups.google.com/group/comp.lang.c/msg/be7e0d0e97c5e1d9

That code doesn't work.

from that post:

unsigned char* rawbuf[(SUPERBLOCK_SIZE * 2) - 1];

(Where SUPERBLOCKSIZE is 4096 * 8)
It exceeds environmental limits, thus all compilers can refuse to
compile it.

DOH! Yes. Okay, well, if you can "temporarily" overlook that retarded error
in the "example" application, I was wondering if you can give me any clever
suggestions on how to improve the alignment hack code itself: Basically, all
the code that exists above the following line:

#define L2CACHE_SIZE 128


BTW, thanks for taking the time to look at the hackish freak code and inform
me of the nasty error!

I really do appreciate it.

 

[Bartc]

Rather hard to take a pointer to an inlined function.

I don't see this being impossible.

You simply keep your non-inlined version around, as well as all the inlined
versions.

 

[Keith Thompson]

Rather hard to take a pointer to an inlined function.

Functions aren't inlined. Function calls are inlined. Inlining a
call doesn't prevent taking the address of the function (as long as a
non-inlined version of the function is kept).

 

[CBFalconer]

.... snip ...


Functions aren't inlined. Function calls are inlined. Inlining
a call doesn't prevent taking the address of the function (as
long as a non-inlined version of the function is kept).

That makes no sense to me. If you inline the following:

inline int sq(int a) {return a * a;}

you do not expect to waste any time assigning registers, creating a
stack marker, executing a call, etc. All you want to do is execute
that action in line.

 

[Keith Thompson]

That makes no sense to me. If you inline the following:

inline int sq(int a) {return a * a;}

you do not expect to waste any time assigning registers, creating a
stack marker, executing a call, etc. All you want to do is execute
that action in line.

Of course, that's the purpose of inlining. But it doesn't preclude
taking the function's address.

Let's ignore the "inline" keyword for the moment, and just consider
inlining as an optimization that might be performed by a pure C90
compiler. Given a function like the one you've defined:

int sq(int a) { return a * a; }

one *call* might be inlined:

int x = whatever;
int y = sq(x); /* sq(x) expanded to x * x */

while another call might be implemented as an ordinary function call.
So inlining is an attribute of a given function, call, not necessarily
of a function.

And it's still perfectly legal to take the address of the "sq"
function, and to use that address later in an indirect call. Such an
indirect call can't easily be inlined, which means that a function
body must be provided (unless the compiler can prove it's not
necessary).

The C99 inline specifier is an suggestion to the compiler to inline
calls to that function. Note that the standard doesn't forbid taking
the address of a function declared with the inline specifier. (If it
did, calls would be impossible, since a simple function call
implicitly takes the address of the function.)

If you declare (in C99):

inline int sq(int a) {return a * a;}

then you're suggesting that calls to sq should be as fast as possible
(see C99 6.7.4 for the exact wording), but you're *not* giving up the
possibility of computing and storing the address of sq.

 

[Richard Bos]

[ Please don't quote .sigs. ]

i am writing a simple application where i want to keep track of number
of bytes my process is using currently or peak memory used by my
process so far.

Why?

If it's to report to your users, don't. They don't care, until the
program crashes because it's ran out of memory, in which case _all_ of
your program is using "too much" memory, not one specific point of it.
Under normal circumstances, this is irrelevant, overly technical
information for normal users.

If it's for your own curiosity, or for debugging, consider using
something like ValGrind, or similar suites, which have been created
specifically to do this and lots more, and give you all the information
you could ever need.

Richard

 

[Richard Bos]

So what colour is 'sky blue'?

#87CEEB, of course...

Richard

 

[David Thompson]

How about ``syntax error before "size_t"'' if your (pre-C99) compiler
doesn't recognize the "inline" keyword?

Yes, most pre-C99 compilers probably do support inline as an extension
(and of course any C99 compiler must support it), but just the other
day you told somebody that he *must* place all his declarations before
statements in a block.

You can usually C89ify (C99) 'inline's with -Dinline= or equivalent.
There is no such trivial fix for declaration-after-statement.
(You can introduce nested blocks, but then you're not actually using
declaration-after-statement after all.)

- formerly david.thompson1 || achar(64) || worldnet.att.net