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

21–30 of 65 posts

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

#21

Post by cryptonector »

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.

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 my side. What matters is being able to find things quickly. Still, one huge file means I can asterisk on a symbol in vim to quickly find all references to it without having to switch to cscope -- that's not nothing.

Also, https://github.com/NetBSD/src/blob/trunk/common/lib/libc/mis... is just not that big... only 1639 lines, 1310 sloc. Compare to, let's say, OpenSSL, where 29 C source files have more lines than ubsan.c, with several being more than twice the size. Maybe you think OpenSSL is not a fair example because there's lots of tables and what not? Even if you look at files outside crypto/, you'll find lots of big ones. Just for fun I looked at a variety of other open source projects: Heimdal, MIT Kerberos, glibc, PostgreSQL -- you'll be shocked when you look at their file sizes, even when you elide files that are obviously mostly-data.

Source file size is not that interesting. The contents is. When a set of sources is small enough, organizing it into multiple files is not necessarily a win. 1.3kloc doesn't seem like that big a file.

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

#22

Post by TeMPOraL »

pebers wrote: post #19
vultour wrote: post #6

Earlier quoted context omitted.

As someone with a very casual knowledge of C, I am thankful when people do this. All you need to do is #include "x" and it just works, having to configure the compiler and linking can be painful. Experienced developers might see it as a disadvatage for some reason, but it is a godsend for beginners.

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

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

#23

Post by Sir_Cmpwn »

cryptonector wrote: post #21
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.

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

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

#24

Post by drb91 »

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.

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.

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

#25

Post by drb91 »

Sir_Cmpwn wrote: post #7
vultour wrote: post #6

Earlier quoted context omitted.

As someone with a very casual knowledge of C, I am thankful when people do this. All you need to do is #include "x" and it just works, having to configure the compiler and linking can be painful. Experienced developers might see it as a disadvatage for some reason, but it is a godsend for beginners.

I think it just trains beginners on how to do things wrong. The basics of linking two pieces of code together aren't terribly complicated and are essential C knowledge.

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?

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

#26

Post by zzzcpan »

Sir_Cmpwn wrote: post #11
zzzcpan wrote: post #9

Earlier quoted context omitted.

> Linking is one of the easiest and most broadly supported features of C environments on every platform. No, it's absolutely not easier. And the more you deviate from amd64 linux and gcc, the harder it gets.

I've worked pretty damn far away from amd64 linux and gcc, and I can assure you that it's really not that hard.

I've seen plenty of times how libraries compile just fine on less popular platforms and environments but then cause crashes at start or not link at all and how much time it wastes dealing with this. I thought these problems were widely known, that's why anyone who cares about porting tries to make self-contained single-sourced libraries.

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

#27

Post by Sir_Cmpwn »

drb91 wrote: post #24
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.

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.

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

#28

Post by Sir_Cmpwn »

drb91 wrote: post #25
Sir_Cmpwn wrote: post #7

Earlier quoted context omitted.

I think it just trains beginners on how to do things wrong. The basics of linking two pieces of code together aren't terribly complicated and are essential C knowledge.

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.

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

#29

Post by Sir_Cmpwn »

zzzcpan wrote: post #26
Sir_Cmpwn wrote: post #11

Earlier quoted context omitted.

I've worked pretty damn far away from amd64 linux and gcc, and I can assure you that it's really not that hard.

I've seen plenty of times how libraries compile just fine on less popular platforms and environments but then cause crashes at start or not link at all and how much time it wastes dealing with this. I thought these problems were widely known, that's why anyone who cares about porting tries to make self-contained single-sourced libraries.

I'm not talking about dynamic linking or distributing shared objects or even archives. I'm talking about static linking or simply slinging together .o files.
Post reply on HN