sizeof

[Richard Tobin]

Re: sizeof

In article <44992F03.9DC16 311@yahoo.com>,
CBFalconer <cbfalconer@mai neline.net> wrote:
[color=blue]
>Anytime you have concurrent processes contending for resources you
>can have deadlocks. This is not concerned with the C language in
>the least.[/color]

However it explains why there may well be no real systems that satisfy
your theoretically true assertion:
[color=blue]
>The point is purely that optimistic filling of malloc
>requests is, or can be, conforming.[/color]

-- Richard

[Richard Tobin]

Re: sizeof

In article <449943E2.4CEDD AB1@spamcop.net >,
Kenneth Brody <kenbrody@spamc op.net> wrote:
[color=blue][color=green][color=darkred]
>> >> > Can the compiler do the equivalent of malloc/free to handle it?)[/color][/color][/color]
[color=blue][color=green][color=darkred]
>> >> Sure.[/color][/color][/color]
[color=blue]
>Well, it would require a reentrant version of malloc/free[/color]

Fortunately these are widely available.

-- Richard

[tedu]

Re: sizeof

Richard Tobin wrote:[color=blue]
> In article <449943E2.4CEDD AB1@spamcop.net >,
> Kenneth Brody <kenbrody@spamc op.net> wrote:
>[color=green][color=darkred]
> >> >> > Can the compiler do the equivalent of malloc/free to handle it?)[/color][/color]
>[color=green][color=darkred]
> >> >> Sure.[/color][/color]
>[color=green]
> >Well, it would require a reentrant version of malloc/free[/color]
>
> Fortunately these are widely available.[/color]

such as? all the implementations i'm familiar with (which may be a
limited set) have some degree of support for threads, but are certainly
not safe to call from within a signal handler.

[CBFalconer]

Re: sizeof

tedu wrote:[color=blue]
> Richard Tobin wrote:[color=green]
>> Kenneth Brody <kenbrody@spamc op.net> wrote:
>>[/color][/color]
.... snip ...[color=blue][color=green]
>>[color=darkred]
>>>Well, it would require a reentrant version of malloc/free[/color]
>>
>> Fortunately these are widely available.[/color]
>
> such as? all the implementations i'm familiar with (which may be
> a limited set) have some degree of support for threads, but are
> certainly not safe to call from within a signal handler.[/color]

Since malloc, by its very nature, is allocating a limited system
resource, namely memory, it must have protected access to various
variables. This means it cannot be truly re-entrant. However, by
use of suitable concurrency constructs it can be made thread safe.

--
"I don't know where bin Laden is. I have no idea and really
don't care. It's not that important." - G.W. Bush, 2002-03-13
"No, we've had no evidence that Saddam Hussein was involved
with September the 11th." - George Walker Bush 2003-09-17

[Richard Tobin]

Re: sizeof

In article <1150915616.399 297.102690@u72g 2000cwu.googleg roups.com>,
tedu <tu@zeitbombe.o rg> wrote:
[color=blue][color=green][color=darkred]
>> >Well, it would require a reentrant version of malloc/free[/color][/color][/color]
[color=blue][color=green]
>> Fortunately these are widely available.[/color][/color]
[color=blue]
>such as? all the implementations i'm familiar with (which may be a
>limited set) have some degree of support for threads, but are certainly
>not safe to call from within a signal handler.[/color]

I had read that the Solaris malloc was re-entrant, but I can't find
any such statement in Sun's own documentation.

-- Richard

[$hiv.....]

Re: sizeof


Frederick Gotham wrote:[color=blue]
> Xicheng Jia posted:
>[color=green]
> > Can any function do it that way! :-)[/color]
>
>
> A macro function perhaps:
>
>
> #define SizeOf(Type) \
> ( \
> (const char*)128 - \
> \
> (const char*)( (const Type*)128 - 1 ) \
> )
>
>
> --
>
> Frederick Gotham[/color]



it will not compile if we give like this, any Solutions for this ??
SizeOf( 4 )

[Andrew Poelstra]

Re: sizeof

On 2006-06-22, $hiv..... <shivakumar@hua wei.com> wrote:[color=blue]
>
> Frederick Gotham wrote:[color=green]
>> Xicheng Jia posted:
>>[color=darkred]
>> > Can any function do it that way! :-)[/color]
>>
>>
>> A macro function perhaps:
>>
>>
>> #define SizeOf(Type) \
>> ( \
>> (const char*)128 - \
>> \
>> (const char*)( (const Type*)128 - 1 ) \
>> )
>>
>>
>> --
>>
>> Frederick Gotham[/color]
>
>
>
> it will not compile if we give like this, any Solutions for this ??
> SizeOf( 4 )
>[/color]

Just use regular sizeof().

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Frederick Gotham]

Re: sizeof

$hiv..... posted:

[color=blue][color=green]
>> #define SizeOf(Type) \
>> ( \
>> (const char*)128 - \
>> \
>> (const char*)( (const Type*)128 - 1 ) \
>> )[/color][/color]
[color=blue]
>
>
>
> it will not compile if we give like this, any Solutions for this ??
> SizeOf( 4 )[/color]

#define SizeOf( L-value ) \
( \
(const char*)(&L-value + 1) \
- (const char*)(&L-value) \
)

I'm getting bored of this one... any ideas for another riddle?

[Richard G. Riley]

Re: sizeof


Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Kenneth Brody <kenbrody@spamc op.net> writes:
> [...][color=green]
>> (BTW, does the Standard say where variable-length arrays are stored?[/color]
>
> No more than it says where anything is stored. VLAs are like any
> other auto objects; they're created at the point of declaration, and
> cease to exist at the end of their scope.
>[color=green]
>> Can the compiler do the equivalent of malloc/free to handle it?)[/color]
>
> Sure.
>[color=green]
>> I've seen systems which can "allocate" memory without actually using
>> any memory until something is written to it. As long as you have at
>> least 103 bits of address space, one could "allocate" that much memory
>> on such a system, as long as you didn't try to write to all of it.[/color]
>
> There's some debate about whether such systems are conforming.[/color]

OT : interestingly enough Linux malloc works like this. It was a
surprise to me.

from the man page :

By default, Linux follows an optimistic memory allocation
strategy. This means that when malloc() returns non-NULL there
is no guarantee that the memory really is available. This is a
really bad bug.

[ozbear]

Re: sizeof

On Wed, 21 Jun 2006 16:29:36 -0400, CBFalconer <cbfalconer@yah oo.com>
wrote:
[color=blue]
>tedu wrote:[color=green]
>> Richard Tobin wrote:[color=darkred]
>>> Kenneth Brody <kenbrody@spamc op.net> wrote:
>>>[/color][/color]
>... snip ...[color=green][color=darkred]
>>>
>>>>Well, it would require a reentrant version of malloc/free
>>>
>>> Fortunately these are widely available.[/color]
>>
>> such as? all the implementations i'm familiar with (which may be
>> a limited set) have some degree of support for threads, but are
>> certainly not safe to call from within a signal handler.[/color]
>
>Since malloc, by its very nature, is allocating a limited system
>resource, namely memory, it must have protected access to various
>variables. This means it cannot be truly re-entrant. However, by
>use of suitable concurrency constructs it can be made thread safe.
>[/color]

Nonsense. A trivial implementation of malloc which just passes an
allocation request on to the underlying O/S and an implementation
of free that does the same to perform the deallocation can
certainly be fully re-entrant.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[CBFalconer]

Re: sizeof

ozbear wrote:[color=blue]
> CBFalconer <cbfalconer@yah oo.com> wrote:[color=green]
>> tedu wrote:[color=darkred]
>>> Richard Tobin wrote:
>>>> Kenneth Brody <kenbrody@spamc op.net> wrote:
>>>>[/color]
>>... snip ...[color=darkred]
>>>>
>>>>> Well, it would require a reentrant version of malloc/free
>>>>
>>>> Fortunately these are widely available.
>>>
>>> such as? all the implementations i'm familiar with (which may be
>>> a limited set) have some degree of support for threads, but are
>>> certainly not safe to call from within a signal handler.[/color]
>>
>> Since malloc, by its very nature, is allocating a limited system
>> resource, namely memory, it must have protected access to various
>> variables. This means it cannot be truly re-entrant. However, by
>> use of suitable concurrency constructs it can be made thread safe.[/color]
>
> Nonsense. A trivial implementation of malloc which just passes an
> allocation request on to the underlying O/S and an implementation
> of free that does the same to perform the deallocation can
> certainly be fully re-entrant.[/color]

Where did you find an OS even mentioned? If you have one, what
makes you think its system calls are re-entrant?

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@mai neline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE maineline address!

[pete]

Re: sizeof

CBFalconer wrote:[color=blue]
>
> ozbear wrote:[color=green]
> > CBFalconer <cbfalconer@yah oo.com> wrote:[color=darkred]
> >> tedu wrote:
> >>> Richard Tobin wrote:
> >>>> Kenneth Brody <kenbrody@spamc op.net> wrote:
> >>>>
> >>... snip ...
> >>>>
> >>>>> Well, it would require a reentrant version of malloc/free
> >>>>
> >>>> Fortunately these are widely available.
> >>>
> >>> such as? all the implementations i'm familiar with (which may be
> >>> a limited set) have some degree of support for threads, but are
> >>> certainly not safe to call from within a signal handler.
> >>
> >> Since malloc, by its very nature, is allocating a limited system
> >> resource, namely memory, it must have protected access to various
> >> variables. This means it cannot be truly re-entrant. However, by
> >> use of suitable concurrency constructs it can be made thread safe.[/color]
> >
> > Nonsense. A trivial implementation of malloc which just passes an
> > allocation request on to the underlying O/S and an implementation
> > of free that does the same to perform the deallocation can
> > certainly be fully re-entrant.[/color]
>
> Where did you find an OS even mentioned? If you have one, what
> makes you think its system calls are re-entrant?[/color]

This is what the standard says about reentrancy:
The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration.

I also recall a somewhat cerebral analysis of the standard,
by Ben Pfaff,
which identified a few standard library functions
as having to be reentrant.
I don't recall malloc as being one of them.

The point I'm getting at,
is that you're slipping towards offtopicancy.

--
pete

[CBFalconer]

Re: sizeof

pete wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> ozbear wrote:[color=darkred]
>>> CBFalconer <cbfalconer@yah oo.com> wrote:
>>>> tedu wrote:
>>>>> Richard Tobin wrote:
>>>>>> Kenneth Brody <kenbrody@spamc op.net> wrote:
>>>>>>
>>>>... snip ...
>>>>>>
>>>>>>> Well, it would require a reentrant version of malloc/free
>>>>>>
>>>>>> Fortunately these are widely available.
>>>>>
>>>>> such as? all the implementations i'm familiar with (which may be
>>>>> a limited set) have some degree of support for threads, but are
>>>>> certainly not safe to call from within a signal handler.
>>>>
>>>> Since malloc, by its very nature, is allocating a limited system
>>>> resource, namely memory, it must have protected access to various
>>>> variables. This means it cannot be truly re-entrant. However, by
>>>> use of suitable concurrency constructs it can be made thread safe.
>>>
>>> Nonsense. A trivial implementation of malloc which just passes an
>>> allocation request on to the underlying O/S and an implementation
>>> of free that does the same to perform the deallocation can
>>> certainly be fully re-entrant.[/color]
>>
>> Where did you find an OS even mentioned? If you have one, what
>> makes you think its system calls are re-entrant?[/color]
>
> This is what the standard says about reentrancy:
> The functions in the standard library are not guaranteed to be
> reentrant and may modify objects with static storage duration.
>
> I also recall a somewhat cerebral analysis of the standard, by Ben
> Pfaff, which identified a few standard library functions as having
> to be reentrant. I don't recall malloc as being one of them.
>
> The point I'm getting at, is that you're slipping towards
> offtopicancy.[/color]

Hardly. I am pointing out why the malloc group cannot be reentrant.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@mai neline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE maineline address!

[Richard Bos]

Re: sizeof

CBFalconer <cbfalconer@yah oo.com> wrote:
[color=blue]
> Richard Bos wrote:[color=green]
> > Kenneth Brody <kenbrody@spamc op.net> wrote:[color=darkred]
> >> Keith Thompson wrote:
> >> > Kenneth Brody <kenbrody@spamc op.net> writes:
> >> [...]
> >>>> I've seen systems which can "allocate" memory without actually
> >>>> using any memory until something is written to it. As long as
> >>>> you have at least 103 bits of address space, one could "allocate"
> >>>> that much memory on such a system, as long as you didn't try to
> >>>> write to all of it.
> >>>
> >>> There's some debate about whether such systems are conforming.
> >>
> >> What would be non-conforming about it? (My guess is that, given
> >> this scenario, it's possible that malloc succeeds [ie: returns a
> >> non-NULL value], but the program fails later when it access this
> >> memory and the O/S discovers "oops, there's really not enough
> >> virtual memory available to allocate".)[/color]
> >
> > Yes. And this is anathema to solid programming and safe computer
> > systems.[/color]
>
> Why should the program fail?[/color]

Don't ask me, ask the people who write such over-clock^tconfid^t
allocating systems, and typically do make one program or another crash
and burn when they run out of over-allocated memory.

Richard

[Richard Tobin]

Re: sizeof

In article <449B3D0E.5B5B4 970@yahoo.com>,
CBFalconer <cbfalconer@mai neline.net> wrote:[color=blue][color=green][color=darkred]
>>> Since malloc, by its very nature, is allocating a limited system
>>> resource, namely memory, it must have protected access to various
>>> variables. This means it cannot be truly re-entrant. However, by
>>> use of suitable concurrency constructs it can be made thread safe.[/color][/color][/color]
[color=blue][color=green]
>> Nonsense. A trivial implementation of malloc which just passes an
>> allocation request on to the underlying O/S and an implementation
>> of free that does the same to perform the deallocation can
>> certainly be fully re-entrant.[/color][/color]
[color=blue]
>Where did you find an OS even mentioned?[/color]

Why does it have to have been mentioned, when providing an example of
how something is possible?
[color=blue]
>If you have one, what
>makes you think its system calls are re-entrant?[/color]

Most operating systems will provide locking such that an implementation
of malloc that just calls the OS for each allocation will appear to be
re-entrant in that you can't make it "go wrong" by calling malloc from
signal handlers. Perhaps you meant to exclude this by adding "truly"
before "re-entrant"?

-- Richard