Re: style question,itoa

Syren Baran <sbaran@xxxxxxxxxxxxxxx> writes:
Rainer Weikusat schrieb:
Not really. I dont like using arrays on the stack unless
i can know for certain they cant overflow. But thats my personal
style.

In this case, the conversion code wouldn't be using a stack allocated
value but the code calling it. Coincendetally, that would be the code
'knowing' what storage management requirements have to be met while
the called code (of a 'library-type' subroutine) cannot.

Dont pinpoint this down to this one function which has a fixed size
allocation. Other helper functions dont return a fixed size char*,
thus knowing the space available in an array is of no help.

This doesn't address the issue I was writing about.

is decidedly not 'your personal style' to write code with lots of
technically useless malloc and free calls,

Good to know someone decided for me which style i am to use ;)

That you call something 'your personal style' which is actually
commonplace in a lot of code just indicates that you haven't seen much
code.

this is common for 'OOP'-programmers not usually working in
memory-limited environment or on performance,

How about OOP-programmers working in a memory limited environment
with limited performance? Want links to J2ME games i wrote?

Obviously, every computer can be regarded as memory-limited because it
has only a limited amount of memory. So, yes, you are alway working in
a memory-limited environment and should never assume that it is just
going to be there. There are just occasions when this assumption will
bite back harder and more often, eg if 'memory-limited' means (as I
intended it to be understood) 'failures caused by OOM conditions
actually happen frequently' and must (insofar possible) be restricted
to non-critical and (ideally) not user-visible components. Eg, a flash
write killed halfway through because of ressource shortage will result
in a unusable device, followed by an angry phonecall by some customer
and the need to provide a replacement unit.

Conventional theory in this respect would be that this doesn't really
matter if it is only a few customers and while I have to accept this
because it is economically sensible, I strongly object to the idea
that this is how it should be.

safety or security criticial code. The only real
accomplishments by doing so are slowing the code down without a gain,
inserting additional points of 'random'[*] failures and enabling
certain types of (malloc-implementation-based) exploits.

Care to elaborate about the later? I do like learning about potential
problems and how to avoid them.

Try googling for malloc-based overrun exploits.

[*] Supposed to mean 'failing because of not easily
observable, dynamically changing external circumstances'.

But you still need to add code that checks for malloc()s retun value.
Theoreticly, yes.
.
No, practically, yes. malloc can and does fail and invocation of a
library-type subroutine should certainly not lead to
program-termination-by-SIGSEV at random. Instead, the caller should
have the ablity to deal with the failure.

ENOMEM is hardly a random failure. Long before that happens i would
expect the system to send a message like "running low on swap
space".

It is hardly a random failure as long as there is exactly one program
running on some computer which allocates memory. But this is never
true for anything UNIX(*)-like, except insofar that 'every' programmer
only cares for one program at any given time, namely, the one he is
working on, and maintains a state of blissful ignorance wrt the
universe around it, aka "isn't there a system call to determine how
much memory is hic et nunc available to me [alone]"?

A possible implementation would be

unsigned sys_personal_reserve_storage(uid_t unused)
{
return 0;
}

[...]

Aside from that even a nun-NULL return value from malloc does not
garantee that memory is available on Linux (see man 3 malloc).
But a NULL return values 'guarantees' that memory is not available.
Ok, but what is your suggestion?

As I have written: The code calling some utility routine is in the
position to do something sensible about ENOMEM, even is this would
only be 'print a message an exit' (another option would be 'schedule a
retry using data structures pre-reserved for this operation'). But to
be able to do so, it must know about the failure first, instead of
just calling the subroutine-of-no-return and being slaughtered for
giddiness. The subroutine itself, except if it is only used in a
specific context, cannot know what to do in case of an error it cannot
recover from on its own.

Wrap every malloc like
if (!malloc(..)){
fprintf(stderr,"Out of memory!\n");
exit(1);
}
?
Checking every single malloc in a bigger application for possible
solutions to ENOMEM's is hardly feasible.

How big would the application still be, provided all superflouus
malloc calls would be removed?

Failure isn't necessarily an option.
.

Relevant Pages

  • Re: xmalloc string functions
    ... If these were the only choices (crashing applications or a frozen ... trying to malloc some rediculously large amount of memory - e.g. in the ... because their malloc wrapper decided to exit. ... Exiting on malloc failure makes sense for a utility like sort. ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... than a NULL return from malloc(). ... pointer value to null at the point I want to trigger the failure. ... I've also had VMWare report out-of-resource at times when the only resource that was tight was memory, and again it gave me the chance to recover the situation which saved me significant work because I had two VMs running and the state between them was important and took time setting up. ... allocations without reference to other circumstances (number of ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... malloc() failures will do as a nice stress test, ... pointer, or an allocation failure - you know, the very thing we're ... Why not follow a policy of try and allocate ... memory, if it fails take some application specific recovery action? ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... than a NULL return from malloc(). ... pointer value to null at the point I want to trigger the failure. ... There are about five bazillion allocations, ... Memory is quite a different kind of resource. ...
    (comp.lang.c)
  • Thank You -- Thomas J. Gritzan
    ... Thomas -- Your suggestion to malloc() out a block of memory was the ... Below are some details of my memory issues ... ... As a work around solution I guessed a ram disk would solve the ... persistence will frustrate the off topic police and give them a target ...
    (comp.lang.c)