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

41–50 of 65 posts

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

#41

Post by microcolonel »

Sir_Cmpwn wrote: post #15
microcolonel wrote: post #13

Earlier quoted context omitted.

> 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? >unl…

> It's far less maintainable...

How so? What form of maintenance does it prevent or hurt?

> ...and goes against the grain of how people expect libraries to behave.

You could dynamically link it if you wanted, it's just that there is little reason to. This approach is inclusive: it enables all three major ways people use libraries.

Honestly, I don't see what the problem is. You're entitled to prefer dynamic linking or static linking, but how does it hurt you that it can also be used another way?

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

#42

Post by Sir_Cmpwn »

microcolonel wrote: post #41
Sir_Cmpwn wrote: post #15

Earlier quoted context omitted.

>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? >unl…

> It's far less maintainable... How so? What form of maintenance does it prevent or hurt? > ...and goes against the grain of how people expect libraries to behave. You could dynamically link it if you wanted, it's just that there is little reason to. This approach is inclusive: it enables all three major ways people use libraries. Honestly, I don't see what the problem is. You're entitled to prefer dynamic linking or…

I'm not arguing about dynamic versus static linking. In fact, I think dynamic linking is pretty bad. I'm just arguing against distributing libraries all in one big C file. You can statically link against an archive built from several sources.

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

#43

Post by microcolonel »

Sir_Cmpwn wrote: post #42
microcolonel wrote: post #41

Earlier quoted context omitted.

> It's far less maintainable... How so? What form of maintenance does it prevent or hurt? > ...and goes against the grain of how people expect libraries to behave. You could dynamically link it if you wanted, it's just that there is little reason to. This approach is inclusive: it enables all three major ways people use libraries. Honestly, I don't see what the problem is. You're entitled to prefer dynamic linking or…

I'm not arguing about dynamic versus static linking. In fact, I think dynamic linking is pretty bad. I'm just arguing against distributing libraries all in one big C file. You can statically link against an archive built from several sources.

But why does it bother you so much? Clearly this is a feature for somebody else, and it's not an issue for you.

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

#44

Post by Sir_Cmpwn »

microcolonel wrote: post #43
Sir_Cmpwn wrote: post #42

Earlier quoted context omitted.

I'm not arguing about dynamic versus static linking. In fact, I think dynamic linking is pretty bad. I'm just arguing against distributing libraries all in one big C file. You can statically link against an archive built from several sources.

But why does it bother you so much? Clearly this is a feature for somebody else, and it's not an issue for you.

As I said elsewhere:

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

And I think I'm squarely in the target audience for this tool anyway. What makes you think it's a feature for someone else?

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

#45

Post by [deleted] »

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

[deleted]

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

#46

Post by sigjuice »

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

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.

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

#47

Post by abenedic »

sigjuice wrote: post #46
TeMPOraL wrote: post #22

Earlier quoted context omitted.

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

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.

I am not sure of a prominent code base that does this exactly, but some people do similar things with "amalagmated builds". Like https://www.sqlite.org/amalgamation.html

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

#48

Post by microcolonel »

Sir_Cmpwn wrote: post #44
microcolonel wrote: post #43

Earlier quoted context omitted.

But why does it bother you so much? Clearly this is a feature for somebody else, and it's not an issue for you.

As I said elsewhere: >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. And I think I'm squarely in the target audience for this tool anyway. What makes you think it's a feature for someone else?

> What makes you think it's a feature for someone else.

The fact that they mention it specifically and proudly on the front page indicates to me that the author, and the NetBSD maintainers who accepted it, consider it good that it is a single, largely self-contained source file. It is only ~1300 source lines, so I don't see why it should necessarily be split out. Something tells me the original authors and the ongoing maintainers of this file have a better idea what value this choice represents than you do (since you haven't said anything particularly compelling in favour of splitting this into several files and objects).

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

#49

Post by abenedic »

cryptonector wrote: post #31
Sir_Cmpwn wrote: post #23

Earlier quoted context omitted.

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.

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 idea of the single file library. Modularization in c and c++ is very poor and based on having multiple files, some of which represent the interface and others that represent the implementation. I at least partly think this is his objection.

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

#50

Post by mnarayan01 »

sigjuice wrote: post #46
TeMPOraL wrote: post #22

Earlier quoted context omitted.

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

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