User implementable standard library functions

[Francine.Neary]

One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementation yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

[Flash Gordon]

Fr************@ googlemail.com wrote, On 21/08/07 23:50:

One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementation yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

free, fopen, fclose (you can implement getc using fgetc or the other war
around ;-)), signal, remove, rename, abort, offsetof (OK, so it's a
macro) to name just a few. I'm assuming ignoring implementations that
always fail just as you did.
--
Flash Gordon

[pete]

Fr************@ googlemail.com wrote:

>
One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementation yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

I don't know, but I have a toy C library here:

http://www.mindspring.com/~pfilandr/C/library/

--
pete

[santosh]

Fr************@ googlemail.com wrote:

One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementation yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

From the top of my head:

free, fopen, fclose, freopen, fread, fwrite, fgetc, exit, signal, raise, the
is* character test functions, perror, sterror, locale functions,
setjmp/longjmp, fflush, remove, tmpfile, abort, system, the va_* macros,
time functions.

[pete]

santosh wrote:

>
Fr************@ googlemail.com wrote:

One interesting thing to come out of the recent
"Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work
if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementation yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

From the top of my head:

free, fopen, fclose, freopen, fread, fwrite,
fgetc, exit, signal, raise, the
is* character test functions,

isdigit can be implemented.
It is not locale dependent.

perror, sterror, locale functions,
setjmp/longjmp, fflush, remove, tmpfile, abort, system,
the va_* macros, time functions.

--
pete

[Richard Heathfield]

pete said:

santosh wrote:

>>
Fr************@ googlemail.com wrote:

<snip>

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

From the top of my head:

free, fopen, fclose, freopen, fread, fwrite,
fgetc, exit, signal, raise, the
is* character test functions,

isdigit can be implemented.
It is not locale dependent.

The same applies to isxdigit, and (without looking it up) probably
isspace - and perhaps one or two others in the same vein.

>perror, sterror, locale functions,
setjmp/longjmp, fflush, remove, tmpfile, abort, system,
the va_* macros, time functions.

I suspect that strftime can be implemented portably.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[cr88192]

<Fr************ @googlemail.com wrote in message
news:11******** **************@ x35g2000prf.goo glegroups.com.. .

One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

well, yes we can, if we grab the original memory from malloc that is...
of course, then for example, I detect linux, and go over to using mmap
instead (for some things, this is needed...).

this is often what I do in my allocators at least...

this often works well for specialized allocators and for garbage collectors.
likewise for wrapping other functionality (such as stdio and posix calls) in
the name of yet more features (a VFS system and being able to mount zipfiles
as part of the directory tree...).

maybe not the same, oh well...

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementation yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

there are lots.

of course, I am not exactly staying in standards land either for that
matter...

I have my own runtime C compiler hack-job linking against statically
compiled parts of the app, and then I go off and implement some blatently
non-standard compiler extensions (geometric vectors and quaternions as
built-in types, among other things...).

works, does what I want, if albeit one has to choose their targets carefully
(currently working on mingw and windows on x86, and, errm...). well, apart
from a few things (not completed yet), my compiler-core should be almost
workable on linux x86-64...

ok, x86 windows is my main target...

[Kenneth Brody]

cr88192 wrote:

>
<Fr************ @googlemail.com wrote in message
news:11******** **************@ x35g2000prf.goo glegroups.com.. .

One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

well, yes we can, if we grab the original memory from malloc that is...
of course, then for example, I detect linux, and go over to using mmap
instead (for some things, this is needed...).

How do you portably guarantee proper alignment?

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Francine.Neary]

On Aug 22, 10:16 am, santosh <santosh....@gm ail.comwrote:

Francine.Ne...@ googlemail.com wrote:

One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementation yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

From the top of my head:

free, fopen, fclose, freopen, fread, fwrite, fgetc, exit, signal, raise, the
is* character test functions, perror, sterror, locale functions,

You mean strerror.

setjmp/longjmp, fflush, remove, tmpfile, abort, system, the va_* macros,
time functions.

[Harald van =?UTF-8?B?RMSzaw==?=]

santosh wrote:

Fr************@ googlemail.com wrote:

>One interesting thing to come out of the recent "Alignment" thread is
that it is impossible to write a portable replacement for malloc in
"user space" (not sure what the right term is - I mean an ordinary
programmer, not an implementor) - even a naive method using a large
array isn't guaranteed to work if there's no way of having a variable
of strictest alignment. Oh, for the sake of the pedants, let's
discount
void *my_malloc(size _t size) { return 0; }
:)

Of course, for most standard library functions, say something like
strlen, it's perfectly possible to provide a completely equivalent
implementati on yourself.

So as an academic exercise, which other standard library functions
share the same property as malloc, that the ordinary programmer is
powerless to write an equivalent function without dipping into non-
Standard implementation details?

From the top of my head:

free, fopen, fclose, freopen, fread, fwrite, fgetc, exit, signal, raise,
the is* character test functions, perror, sterror, locale functions,
setjmp/longjmp, fflush, remove, tmpfile, abort, system, the va_* macros,
time functions.

fread/fwrite can be implemented portably by calling to fgetc/fputc, or
fgetc/fputc can be implemented portably by calling fread/fwrite; whichever
you choose, you can cross one pair off of your list. (You included fgetc
but not fputc; I'm assuming that was an oversight.)

In addition to the functions you listed, most of the floating point math
functions are notable in that they can be implemented portably, but cannot
be implemented portably in a way that's likely to actually be useful.