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

µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

blog.netbsd.org

Post reply on HN
Print view View original

51–60 of 65 posts

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#51

Post by sigjuice »

mnarayan01 wrote: post #50
sigjuice wrote: post #46

Earlier quoted context omitted.

Is there a prominent C code base that does this sort of thing? I’m sorry this is all very questionable advice IMHO. What would be one word in a makefile (onefilelib.c) is a 4-line jumble of preprocessor macros, names starting with __ are reserved, and the suggestion to redefine main and entry points smells like more #ifdef spaghetti.

The #ifndef rigamarole is https://en.wikipedia.org/wiki/Include_guard and at least used to be fairly common. I also used to see the __FOO_BAR_H__ naming convention for these defines all over the place. I'm not sure if __ identifiers being reserved is a (not very) new thing or if it's always been around and people are just now more generally knowledgeable about the fact that they shouldn't be used.

Yes, the include guard is a very widespread technique for header files. My objection is against #include’ing a .c file to support the questionable trend of ‘single file libs’.

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#52

Post by abenedic »

Sir_Cmpwn wrote: post #3

>I've decided to write the whole µUBSan runtime as a single self-contained .c soure-code file, as it makes it easier for it to be reused by every interested party. I don't really get why people do this. Linking is one of the easiest and most broadly supported features of C environments on every platform.

There seems to be several different discussions which are taking place as a response to your comment. It might be good to have a more consolidated reference since different people are attacking different aspects of your argument, so of which are a little unfair.[I am not a native speaker so I may have misunderstood some points or will misrepresent them]

Reasons why people like single file libs:

* Easy for a beginner to use.

* No non-obvious dependencies. (check includes to see them) * Easy to repackage for multiple OS's

* Easy to understand since each reference is in the same file.

* Typically simpler and have fewer features(which can help one focus on the main issues.)

* No need for either static or dynamic linking, although it is basically the same as static linking in some ways.

* Eliminates the need for dependency management.

Reasons against single file libraries:

* No isolation of components. (The interface and implementation are in the same file)

* Adding new feature may make the library too complicated(which can lead to some features being denied)

* A bit harder to maintain. Since the interface and implementation are the same, some users may depend on internal interfaces. Which can inhibit changes needed for performance.

* May encourage bad behaviour, since the user need never learn to link against a third party library. If the culture changes enough there may be many people contributing who are not able to use standard tools in the standard way. (The idea that beginners should learn the culture that is used by the toolmakers.)

Hopefully this is useful for someone, and I hope I did not misrepresent any opinions.[Also huge fan of Drew]

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#53

Post by abenedic »

Sir_Cmpwn wrote: post #27
drb91 wrote: post #24

Earlier quoted context omitted.

And what dependency management or package system would you use to install that library? Distributing the source, especially for self contained libraries, is easily managed with the rest of your source code.

Sure, I'm all for distributing the source. Doesn't mean it needs to be a single file. It should probably have a makefile which spits out an archive file, which you link to in your application.

I would like if when people did this they automatically had it compile the library with -ffunction-sections and -fdata-sections. This would make my life way easier, and if anyone is reading this, please add these flags. Combined with stripping the executable afterwards you can make things way smaller for embedded systems.

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#54

Post by TeMPOraL »

sigjuice wrote: post #51
mnarayan01 wrote: post #50

Earlier quoted context omitted.

The #ifndef rigamarole is https://en.wikipedia.org/wiki/Include_guard and at least used to be fairly common. I also used to see the __FOO_BAR_H__ naming convention for these defines all over the place. I'm not sure if __ identifiers being reserved is a (not very) new thing or if it's always been around and people are just now more generally knowledgeable about the fact that they shouldn't be used.

Yes, the include guard is a very widespread technique for header files. My objection is against #include’ing a .c file to support the questionable trend of ‘single file libs’.

I wasn't suggesting this as a serious method of organizing your project - merely pointing out that this quick hack can be done and is rather straightforward. And I did actually see it once or twice in the wild.

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#55

Post by floatboth »

alexhutcheson wrote: post #39
floatboth wrote: post #38

Earlier quoted context omitted.

> The original Clang/LLVM runtime is written in C++ with features that are not available in libc and in the NetBSD kernel

Yeah, I understand why they would write a clone, but "clean-room" has a specific meaning[1], and it's not clear why you would want or need that extra effort here. Of course, I could just be misunderstanding, and they could be using "clean-room" as a synonym for "from scratch", rather than the meaning I linked to. [1] https://en.wikipedia.org/wiki/Clean_room_design

Oh, right, I didn't even think about that meaning since we're not in the context of proprietary software. I'm 99.99% sure it's just "from scratch" here.

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#56

Post by alexhutcheson »

ajross wrote: post #40
alexhutcheson wrote: post #30

Why was a clean-room approach necessary here? The UIUC License used by UBSan is extremely permissive, so going through extra effort to avoid creating a derivative work doesn't make much sense to me.

It's not. They're just using the term as a synonym for "rewrite". There's no documentation of any actual IP isolation in the linked article. They just want people to know it's new and not based on the existing LLVM or Linux runtimes.

This seems correct. Apologies for the unintentionally pedantic comment.

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#57

Post by slrz »

TeMPOraL wrote: post #22
pebers wrote: post #19

Earlier quoted context omitted.

You need to do more than just #include it - it is implemented in one .c file but that is not a header, so you'd still need to compile that separately and link it in somehow.

Not really. All you need to do is: #ifndef __onefilelib__ #define __onefilelib__ #include "onefilelib.c" #endif (Also potentially defining "main" as something else, if it happens that the "onefilelib.c" has an entry point for some reason.)

This only does what you want if you mush everything together into a single translation unit. Otherwise, you will get duplicate definitions for everything in onefilelib.c.

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#58

Post by liuliu »

alexhutcheson wrote: post #39
floatboth wrote: post #38

Earlier quoted context omitted.

> The original Clang/LLVM runtime is written in C++ with features that are not available in libc and in the NetBSD kernel

Yeah, I understand why they would write a clone, but "clean-room" has a specific meaning[1], and it's not clear why you would want or need that extra effort here. Of course, I could just be misunderstanding, and they could be using "clean-room" as a synonym for "from scratch", rather than the meaning I linked to. [1] https://en.wikipedia.org/wiki/Clean_room_design

My reading is that they didn't look at the Linux implementation (as "clean-room").

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#59

Post by cryptonector »

abenedic wrote: post #49
cryptonector wrote: post #31

Earlier quoted context omitted.

You could have looked at the file size first. What if it had been 500sloc? Would you still have made the same comment? What is the point at which you'd absolutely insist on splitting it up if you were doing a code review? Surely 1.3ksloc is smaller than that. The commentary on splitting this up strikes me as so much bikeshedding.

I think, not to put words in his mouth, that he is objecting to the idea of single file libraries as inherently good or better than a multi-file library. I think the objection is more about future design choices the maintainer will make. If you want to keep it single file, it may be necessary to avoid adding some features which are too complex. Complex features usually necessitate modularization, which is against the…

OK, sure, https://news.ycombinator.com/user?id=Sir_Cmpwn's comment was:

> > I've decided to write the whole µUBSan runtime as a single self-contained .c soure-code file, as it makes it easier for it to be reused by every interested party.

> I don't really get why people do this. Linking is one of the easiest and most broadly supported features of C environments on every platform.

Sure, this is true, and users already have to know how to link, unless they are #include'ing this, but still, a single file is much easier to share/distribute and use, and in any case, splitting up such a small file (by the standards of.. a number of open source projects I looked at, it's small) seems unnecessary.

Re: µUBSan: clean-room reimplementation of the Undefined Behavior Sanitizer runtime

#60

Post by abenedic »

cryptonector wrote: post #59
abenedic wrote: post #49

Earlier quoted context omitted.

I think, not to put words in his mouth, that he is objecting to the idea of single file libraries as inherently good or better than a multi-file library. I think the objection is more about future design choices the maintainer will make. If you want to keep it single file, it may be necessary to avoid adding some features which are too complex. Complex features usually necessitate modularization, which is against the…

OK, sure, https://news.ycombinator.com/user?id=Sir_Cmpwn's comment was: > > I've decided to write the whole µUBSan runtime as a single self-contained .c soure-code file, as it makes it easier for it to be reused by every interested party. > I don't really get why people do this. Linking is one of the easiest and most broadly supported features of C environments on every platform. Sure, this is true, and users already…

I totally agree with you, I personally love single file implementations.

I was just trying to explain what I thought his argument was against them, since I don't think he really explicitly stated it outside of generally speaking of maintenance issues. He just said he would prefer to contribute patches to a project that had multiple files and a makefile based build system.

I was assuming his argument was about the future directions the project could go, which I can see as being a valid criticism. As I said the main issue with a single file implementation is that potential users may end up using parts of the implementation instead of just the public facing interface you would like them to use.

Post reply on HN