Re: style question,itoa

Syren Baran <sbaran@xxxxxxxxxxxxxxx> writes:
Robert Latest schrieb:
Syren Baran wrote:
David Schwartz schrieb:
The caller has to 'free' 'retval' when it's done.
Its intended that way.
It might be more
sensible to have the caller pass in a buffer. This will allow the
caller to use a buffer on its stack if that makes the most sense for
it.
Dont intend to change that. I´m comfortable with that.
That's puzzling.

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.

It is decidedly not 'your personal style' to write code with lots of
technically useless malloc and free calls, this is common for
'OOP'-programmers not usually working in memory-limited environment or
on performance, 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.

[*] 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.

Since the program i´ll use it cant eat up memory at an alarming rate i
prefer manual intervention (being able to tell the program not to
accecpt further connections and deny further functions calls that can
allocate memory).

Since the OS used to run your program manages the available RAM, no
matter how hard you try to ignore that, there is no way to determine a
priori when memory allocations would fail.

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.
.

Relevant Pages

  • Re: C 99 compiler access
    ... > nm> reliably allocating some piece of memory. ... We're not talking about implementing malloc in portable C - it's part of the ... concern is that library implementations are not implementing the required ... using malloc to allocate the buffer memory. ...
    (comp.lang.c)
  • Re: Problem in printing string, created in another function.
    ... This makes me feel that since I assign retval memory using automatic ... the caller will need to free the memory after it's ... The caller MUST completely finish using the buffer you formatted the ... string into before the next time the formatting routine is called, ...
    (comp.lang.c)
  • Re: Benchmark: STLs list vs. hand-coded one
    ... if you bother to check the pointer from malloc or use newand throw ... buffer to 640MBytes. ... To support your efficient memory management you limit symbol size to ... Yes you could require the compiler to jump ...
    (comp.arch.embedded)
  • Re: NTFS - Kernel memory leak in driver for kernel 2.4.28?
    ... I should say that the malloc() succeeds, but the 16mb I need for the ... buffer are not available. ... memory tied up in the inode and dentry cache. ... kernel attempts to use for the dentry/inode cache, or make it much, ...
    (Linux-Kernel)
  • Re: xmalloc string functions
    ... caller that fact like I do when malloc() fails to delever me the ... amount of memory I ask it for. ... The caller will check the error condition it receives and will react ... then you can safely abortwhen fopenfails. ...
    (comp.lang.c)
Quantcast