«

On 2011-05-12, Keith Thompson <kst-> wrote:
> [snip]
> In some blatantly non-portable manner.
>
> There's probably some way to get the current "break" value as
> a void*. Given that value, you can add to it (by any of several
> methods) and pass the result to brk(). Or you can use sbrk(), which
> takes care of most of the bookkeeping for you. (Or, as the man
> page recommends rather strongly, use malloc() to allocate memory.)
>
If you call sbrk(0) it returns the current location of the
"program break", that is the end of the process's data segment.
Source: sbrk manpage

On 2011-05-13, Columbus sailed the ocean China Blue <> wrote:
> Unless sbrk fails and returns an error.

None of this changes that brk() is not an example of a function which
is defined to, or expected to, take arbitrary integer values converted
to pointers, or indeed, any integer values converted to pointers.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On May 13, 3:36*am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-05-13, Columbus sailed the ocean China Blue <chine.b...@yahoo.com> wrote:
>
> > Unless sbrk fails and returns an error.
>
> None of this changes that brk() is not an example of a function which
> is defined to, or expected to, take arbitrary integer values converted
> to pointers, or indeed, any integer values converted to pointers.

Unfortunately, I can give an example. In the Windows API (it would
have to be Windows), a number of functions that take constant strings
can also take an ATOM. The definition of ATOM is

typedef WORD ATOM;

where WORD is a typedef for unsigned short.

In particular, check the lpClassName parameter to CreateWindowEx.

Martin Shobe

Eric Sosman <> writes:
<snip>
> As for "will be abandoned," I'm not at all sure you're right.
> C *is* loaded with dozens of little inconveniences, yet it is (my
> guess) the third longest-surviving language in general use today,
> behind Fortran and COBOL, languages if anything even more loaded
> with inconveniences than C.

I'd say fourth-oldest because of LISP.

> Language longevity seems not so strongly
> influenced by aesthetics as you appear to suppose.

--
Ben.

On 5/13/2011 5:12 PM, pozz wrote:
> Il 13/05/2011 04:07, Eric Sosman ha scritto:
>>> malloc() and free() are not present in my embedded system. I have to use
>>> only static allocation.
>>
>> malloc() is absent but printf() is present? It's possible,
>> certainly, but seems unlikely if not downright perverse.
>
> Hmmm..., I haven't a big experience in C programming on embedded
> systems, but I worked on some environments. Except some (and not all)
> 8-bit microcontrollers, they had sprintf() but not dynamical allocation
> mechanisms.

I'm not disputing your observation, just remarking that it
seems an odd choice on the implementor's part. The *printf() suite
usually turns out to be a rather large amount of code, even if it's
limited just to sprintf() and doesn't do actual output. The malloc()
package is quite small by comparison, and it seems weird that an
implementor would do all the hard work of providing *printf() but
shy away from the much simpler malloc().

Hmm: One reason to omit malloc() might be that the embedded
system has its own un-malloc()-like memory management API. If so,
perhaps you could use it instead.

>> Anyhow, implementing a quick-and-dirty malloc() work-alike
>> based on a static array shouldn't take anyone more than an hour.
>
> Maybe it is possible (indeed I'm interested to have a look to some
> working implementations), but I think static allocation in embedded
> systems could be sufficient for most of all the work.

Maybe I misread you somewhere along the line, but I thought you
were worried about the lifetime of the data item referenced by the
callback function's pointer argument. If static allocation works for
your scenario, fine. But if you've got a variable and hard-to-predict
number of these callbacks being registered at run-time, you'll very
likely find yourself in need of an allocation whose lifetime is neither
infinite (static) nor tied to a scope (auto).

--
Eric Sosman
d

pozz <> writes:

> Il 12/05/2011 22:05, Shao Miller ha scritto:
>> Well that's too bad. Do you at least have a function which will cause a
>> thread to sleep and provide an opportunity for another thread (such as
>> one that invokes your call-back) to execute?
>>
>> Or is this the type of scenario where you are expected to register
>> call-backs and then yield control back to a higher-level function that
>> is not your own, effectively ending your program until a call-back is
>> invoked?
>
> In my application I have a software with cooperative
> multitasking. Each task is a function that is responsible to exit in a
> short time to give other threads/functions the possibility to run.

Which is, irritatingly, the one time when you would benefit from a nice
way to pass the integers through the void pointers without having to
have global (or very nearly global) variables holding constants hanging
around for them to point back to.

So I think we've exhausted it: either use the integers cast to pointers
and accept that this may well work on a variety of platforms but is
definitely non-portable (and there certainly are/have been platforms it
could well give problems on: those with a segmented architecture for
example) or end up with a global array of constants to point at.

Sad but true.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk