Comment by eqvinox | Hacker News Reader

Comment by eqvinox | Hacker News Reader

Parent Full thread

> Is it? Could you elaborate/provide links to examples of this?

https://github.com/FRRouting/frr/tree/master/lib/printf

Disclaimer: my work.

Customised to support %pHX, %pI4, %pFX, etc. - docs at https://docs.frrouting.org/projects/dev-guide/en/latest/logg... for what these do.

> What customization would it support?

I don't understand your question. It's reasonably readable and understandable source code. You edit the source code. That's the customisation?

> Say, compared to these options: https://github.com/eyalroz/printf?tab=readme-ov-file#cmake-o...

First, it is customary etiquette to indicate when linking your own code/work.

Second, that is not a POSIX compatible printf, it lacks support for '%n$' (which is used primarily for localisation). Arguably can make sense to omit for tiny embedded platforms - but then why is there FP support?

Third, cmake and build options really seem to be overkill for something like this. Copy the code into the target project, edit it. If you use your own printf, you probably need a bunch of other custom stuff anyway.

Fourth, the output callback is a reasonable idea, but somewhat self-contradictory. You're bringing in your own printf. Just adapt it to your own I/O backend, like libc has FILE*.

> You edit the source code. That's the customisation?

I meant, customization where you don't have to write the customized code yourself, just choose some build options, or at most set preprocessor variables.

> First, it is customary etiquette to indicate when linking your own code/work.

You're right, although I was only linking to the table of CMake options. And it's only partially my code, since I'm the maintainer rather than the original author

> You're bringing in your own printf. Just adapt it to your own I/O backend, like libc has FILE.

One can always do that, but - with the output callback - you can bring in an already-compiled object, which is sometimes convenient.

> If you use your own printf, you probably need a bunch of other custom stuff anyway.

My personal use case (and the reason I adopted the library) was printf deficiencies in CUDA GPU kernels. And - I really needed nothing other than printf functions. Other people just use sprintf to format output of their mostly, or wholly, self-contained functions which write output to buffers and such. Different strokes for different folks etc.

But - I will definitely check out the link.

> Second, that is not a POSIX compatible printf, it lacks support for '%n$' (which is used primarily for localisation).*

That is true. But C99 printf and C++ printf do not support that either. ATM, the aim is completing C99 printf support (when I actually work on the library, which is not that often). So, my priority would be FP denormals and binary FP (with "%a"), before other things.

> * Arguably can make sense to omit for tiny embedded platforms - but then why is there FP support?*

It's there because people wanted it / needed it; and so far, there's not been any demand for numbered position specification.

> I meant, customization where you don't have to write the customized code yourself, just choose some build options, or at most set preprocessor variables.

Honestly, if you're shying away from customising an 1-2kloc piece of code, you probably shouldn't be using a custom printf().

Case in point: function pointers are either costly or even plain unsupported on GPU architectures. I would speculate that you aren't using the callbacks there?

> Honestly, if you're shying away from customising an 1-2kloc piece of code, you probably shouldn't be using a custom printf().

Well, it was good enough for the arduino SDK to adopt: https://github.com/embeddedartistry/arduino-printf

> * function pointers are either costly or even plain unsupported on GPU architectures.*

When you printf() from a GPU kernel, your performance is shot anyway, so performance is not a consideration. And - function pointers work, as long as they all get resolved before runtime, and you don't try to cross CPU <-> GPU boundaries.

> > Honestly, if you're shying away from customising an 1-2kloc piece of code, you probably shouldn't be using a custom printf().

> Well, it was good enough for the arduino SDK to adopt: https://github.com/embeddedartistry/arduino-printf

Well, they didn't shy away from customizing it quite a bit ;)

To be clear I was trying to say it doesn't make too much sense to try to package this as an independent "easy to use" "library" with a handful of build options. Not that it's somehow not "good enough".

Put another way: a situation where you need/want a custom printf is probably a situation where a package like this doesn't exactly help you anyway and you'll need to muck with it regardless. But the code can be used. Which is exactly what the repo you linked did.

Reply on news.ycombinator.com