Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Memory Management, Part 1: C

educatedguesswork.org

Post reply on HN
Print view View original

91–95 of 95 posts

Re: Understanding Memory Management, Part 1: C

#91

Post by dundarious »

tptacek wrote: post #85
dundarious wrote: post #83

Earlier quoted context omitted.

After using this malloc-auto-abort() style for many many years, I've come to believe that if only for the better error handling properties , manual memory management should primarily be done via explicit up front arena allocation using OS API's like mmap/VirtualAlloc, then a bump allocator within the arena. It helps in the vast amount of cases where sensible memory bounds are known or can be inferred, and it means th…

I feel like the prospect of using arenas and pools is further evidence that malloc and realloc should abort on failure, because you're right: if you're using an arena, you've not only taken application-layer control over allocation, but you've also implicitly segregated out a range of allocations for which you presumably have a strategy for exhaustion. The problem with malloc is that it's effectively the system alloc…

Yes, fundamentally my point is that it's pretty much always useful to separate OS allocation from application-level "allocation" (more like consumption of allocated memory than true allocation), and, that application-level "allocation" should always auto-abort() or at least provide a trivially easy way to auto-abort().

So I agree, given malloc and friends are a combination of OS and application-level allocators, they should auto-abort(). I don't focus on malloc and friends though, because I'm not a fan of using the Rube Goldberg machine of "general purpose" allocators in most non-trivial situations. They're complicated hierarchies of size-based pools, and free lists, and locks, and on and on.

Re: Understanding Memory Management, Part 1: C

#92

Post by sylware »

keyle wrote: post #59
the-smug-c-one wrote: post #52

Earlier quoted context omitted.

Because you're probably writing a much larger program so some ifdefs aren't a big deal :-).

This is a silly argument because at the end of the day, once you make your code portable, you've now duplicated 99% of malloc and free, and you've left a mess for the team or next guy to maintain on top of everything else. You've successfully lowered the abstraction floor which is already pretty low in C.

what?? The whole point is to create independence, then create "real-life" alternatives. I don't understand your point.

Re: Understanding Memory Management, Part 1: C

#93

Post by ekr____ »

AdieuToLogic wrote: post #62

The example strdup implementation: char *strdup(const char *str) { size_t len = strlen(str); char *retval = malloc(len); if (!retval) { return NULL; } strcpy(retval, str); return retval; } Has a very common defect. The malloc call does not reserve enough space for the NUL byte required for successful use of strcpy, thus introducing heap corruption. Also, assuming a NULL pointer is bitwise equal to 0 is not portable.

Aargh. You're totally right about the off by one error. Thanks for catching it.

I don't believe you're right about the comparison to zero, however, as the comment below indicates.

Re: Understanding Memory Management, Part 1: C

#94

Post by writebetterc »

commandlinefan wrote: post #88
writebetterc wrote: post #54

This post caused me to create an account. This C code is not good. Writing C is absolutely harder than Python, but you're making it so much harder than it has to be. Your program is buggy as heck, has very finicky cleanup code, and so on. Here's a much easier way to write the program: 1. Dump whole file into buffer as one string 2. Find newlines in buffer, replace with NULs. This also let's you find each line and sav…

> Dump whole file into buffer as one string ... unless the file is too big to fit into memory?

Memory will always be the limiting factor here. A strong adversary can ensure that you must know the whole list in order to sort it.

You can always mmap the file instead and let the OS page in and out parts of the file, however :-).

Re: Understanding Memory Management, Part 1: C

#95

Post by honzaik »

i am no C programmer, but doesnt the first pseudocode make no sense (and others after since they reuse it)?

  address = X
  length = *X
  address = address + 1
  while length > 0 {
    address = address + 1
    print *address
  }
1) length is never updated so while is infinite loop (if length is not 0)

2) the first character is never output since at address 0 (assuming X=0 at the start) is the value length but then the pointer is incremented twice so the first print *address prints the character at address 2?

if I am mistaken I'd be happy if someone explained why it makes sense

Post reply on HN