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

31–40 of 65 posts

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

#31

Post by cryptonector »

Sir_Cmpwn wrote: post #23
cryptonector wrote: post #21

Earlier quoted context omitted.

You're not going to like how PuTTY is written then either. The entire initial portion of the SSHv2 protocol, from version string exchange to the end of user authentication, is coded as one huge (10Kloc) C function that uses a macro-driven Duff's device to implement co-routine behavior (it's all async I/O under the covers). To me, one huge file or many small ones doesn't matter all that much because I have cscope on m…

1639 lines of code actually isn't bad at all. I think that's less of a selling point and more happenstance, though. I certainly wouldn't want to reject changes which split it up in the future as it gets more unweildy on the basis of "but being in one file is a feature!".

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.

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

#32

Post by com2kid »

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.

> Linking is one of the easiest and most broadly supported features of C environments on every platform.

And build systems are one of the most varied features of C environments.

I've seen large projects (e.g. OpenSSL) take weeks of effort to integrate into build systems. Suffice to say, no one wants to try and merge patches in afterwords.

Nevermind the number of source trees I've seen with copies of some old version of OpenSSL source, ugh.

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

#33

Post by [deleted] »

Sir_Cmpwn wrote: post #28
drb91 wrote: post #25

Earlier quoted context omitted.

Linking is only one step in package management. Besides, in this scenario, it may not be viewed as a library a user should manage. The only benefit I can think of from linking is getting security patches without recompiling. That might easily not be a priority. Why is that a problem?

I'm not talking about package management.

[deleted]

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

#34

Post by [deleted] »

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.

[deleted]

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

#35

Post by drb91 »

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.

Ok, I’m in agreement there.

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

#36

Post by johnm1019 »

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.

Speculating:

- The author wanted the personal challenge for the task

- The author wanted the code licensed under a BSD 2-clause and felt the existing license didn't fit her/his ideals.

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

#37

Post by abenedic »

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

You should really be careful about c preprocessor macros when you do things like this with .c files. You should always undefine any macros defined in a file which are not properly namespaced(as much as C allows for pseudo namespacing).

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

#38

Post by floatboth »

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.

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

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

#39

Post by alexhutcheson »

floatboth wrote: post #38
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.

> 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

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

#40

Post by ajross »

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.
Post reply on HN