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

11–20 of 65 posts

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

#11

Post by Sir_Cmpwn »

zzzcpan wrote: post #9
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. 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.

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

#12

Post by microcolonel »

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.

This way there are no barriers to entry, such as a long list of objects to link. You just include one object and you're golden. If you don't mind linking longer lists of objects, great, you can have a list of length 1 instead.

What harm is it to you that it's a single source file and a single object?

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

#13

Post by microcolonel »

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.

> I think it just trains beginners on how to do things wrong.

What gives you the impression that this is the "wrong" way to do this? How many beginners are going to be looking to μUBSan for guidance on how to structure their generic library? And it's not like linking isn't involved, you still end up linking the one object that is created from that source file (unless you #include it, which would also probably work).

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

#14

Post by Sir_Cmpwn »

microcolonel wrote: post #12
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.

This way there are no barriers to entry, such as a long list of objects to link. You just include one object and you're golden. If you don't mind linking longer lists of objects, great, you can have a list of length 1 instead. What harm is it to you that it's a single source file and a single object?

>What harm is it to you that it's a single source file and a single object?

I don't consider open source projects a black box, I evaluate every project under the lens of someone who expects to someday have to work with the code myself and send patches upstream.

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

#15

Post by Sir_Cmpwn »

microcolonel wrote: post #13
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.

> I think it just trains beginners on how to do things wrong. What gives you the impression that this is the "wrong" way to do this? How many beginners are going to be looking to μUBSan for guidance on how to structure their generic library? And it's not like linking isn't involved, you still end up linking the one object that is created from that source file (unless you #include it, which would also probably work).

>What gives you the impression that this is the "wrong" way to do this?

It's far less maintainable and goes against the grain of how people expect libraries to behave.

>How many beginners are going to be looking to μUBSan for guidance on how to structure their generic library?

Any beginner who uses it. You make a good point, though, this isn't exactly a beginner-tier tool so why is it being distributed like one?

>unless you #include it, which would also probably work

I think that's what they're expecting you to do. And if you're linking anyway, what does it matter if it's one object or several? Or more realistically, a single archive (built from many objects which are themselves built from many source files)?

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

#16

Post by MaulingMonkey »

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.

> The basics of linking two pieces of code together aren't terribly complicated

The basics aren't complicated, but doing it correctly requires more than the basics IME.

Each platform does it slightly differently, and I support multiple platforms. I've repeatedly seen static libs linked into multiple dynamic libs and cause all kinds of trouble because there's multiple copies of global data, of which only one was probably initialized correctly. I have seen multiple different stdlibs successfully linked into the same program, causing ABI mismatches that compiled, linked, and "usually" ran at runtime - but had some nasty crashes to be debugged, because std::vector was an entirely different type at the call site vs the callee's implementation. Version mismatches of other SDKs are also common. I've had all kinds of weird constraints on what compilation and link flags I could use based on what static libs I've linked (e.g. being unable to link with exception handling enabled because one of my dependencies was built with it disabled)

Additionally you don't have libs for all my platforms (or sometimes any of them), so I have to build from source anyways, so I have to write build rules for your lib because the defaults probably don't work, and because build rules are never documented I have to mostly reverse engineer intent to do so - possibly without a viable build in the first place if your only working libs are for platforms I don't use.

Or if I'm lucky enough that reusing your build rules is viable, I have to try and sync various flags between my projects written in one build system and your projects written in yet another build system, and prevent these from getting out of sync for the remainder of the lifetime of the project. I likely have to jump through all kinds of stupid hoops like installing the exact right version of python and installing undocumented but required packages just to run the configuration scripts that drive the build.

...or for single-source libs, I can probably just drop a single file into one of my existing projects and have everything work. Okay, so some of that was just because they actually cared about minimizing how painful it is to integrate their library at all, but having a single .c file helped too.

I'd only write a single .c library for the simplest of libraries - or as an automatically generated file - but it can help.

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

#17

Post by abenedic »

Sir_Cmpwn wrote: post #10
abenedic wrote: post #8

Earlier quoted context omitted.

It makes it easier to relink against a different standard library like musl. Or for cross compilation. The fewer files to deal with the fewer places I have to look for issues in porting.

I mean, you're already going to have to recompile stuff for either of those cases. Once you're compiling things, compiling several files isn't much harder.

Right, it is almost always possible to do anything. In practice I would rather have to change the includes on one file to get it to compile with musl rather than change the includes on 10+ files each with a different change. It is a matter of degree not kind of difficulty. But in general I always will prefer the issues that arise from a single file implementation rather than the issues from many files.[Sorry if this is phrased poorly, I am not a native speaker.]

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

#18

Post by pebers »

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.

It's not the reason the author gives, but one advantage is that you don't need LTO for some optimisations. Sqlite has a single-file distribution for that reason. On the downside, it is quite slow to compile and not readily parallelisable - but that probably is less of a concern here.

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

#19

Post by pebers »

vultour wrote: post #6
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.

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.

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

#20

Post by mnarayan01 »

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.

If you include it (possibly indirectly) in a file which you compile, then no, you do not need to compile it separately.
Post reply on HN