Skip to content

Comment on Cello – High Level Cparent

Comments

Not only that, but last I looked into this library's code there was a lot of undefined behavior

Neither GCC's nor Clang's sanitisers pick up any undefined behaviour - and it's been like that for at least the last few years I've looked at it.

As to ignoring errors, and ignoring alignment, I don't think I've ever seen anything like that in the project. I have seen several pull requests delayed so that they will.

Overall, for what it's doing, this is one of the cleaner codebases I've dealt with.

    #define alloc_stack(T) ((struct T*)header_init( \
      (char[sizeof(struct Header) + sizeof(struct T)]){0}, T, AllocStack))
You can't take char[sizeof(foo)] on the stack and cast it to a foo*. malloc implementations for example are cafeul to align the buffer they give you. Windows, for example, aligns on 8 bytes. Probably popular alloca implementations do this too. For example, googling for "alloca alignment" finds some documentation: "... returns a void pointer to the allocated space, which is guaranteed to be suitably aligned for storage of any type of object". I have seen things break in the real world when these expectations are violated. The cello tree does this in a more few places since I last looked, eg. skimming it again I see the same pattern in the Windows stack trace code. It will probably work there but it's a coincidence, and not guaranteed by the standard AFAIK.

It looks like they got rid of some undefined things I saw when I looked in 2015. eg. they used to think you can do arithmetic on void pointers, which I think even gcc -Wall would flag for you. [Edit: Trying it out it seems I am wrong, on gcc and clang you need -pedantic to get that warning.]

I'm really surprised that you both came up with opposing results... What tests were done indicating undefined behavior?

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.