Comment by jabot | Hacker News Reader

Comment by jabot | Hacker News Reader

Parent Full thread

> They are "protected", yes, but their mere presence encourages people to use them. There's no reason to use asprintf, but glibc makes it available so some software uses it. That software is now non-portable.

I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"...

On exposing non-portable functions/features:

  - OpenBSD does it (pledge)

  - Freebsd/NetBSD do it (kqueue)

  - ... I'm certain other systems do too

I think _exposing_ non-portable features is ok, as long as you can't use them _accidentally_. Now, _if_ glibc fulfills that, the blame should fall on the (lazy) developer. If on the other hand glibc makes accidental use possible, then that is... bad for portability.

> Maybe in a blog post someday.

I would like to read that. :-)

[edit: formatting...]

>I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"...

Well, implement it yourself then. It's really not hard to live without, though. I don't know about this loop you're talking about but I just do this:

    int len = snprintf(NULL, 0, "fmt", ...);
    char *foo = malloc(len + 1);
    snprintf(foo, len, "fmt", ...);

Easy to wrap that up in your own asprintf function if you would find that useful. And in practice writing a lot of these functions is going to happen anyway when someone ports your non-portable code to another system.

>Well, implement it yourself then.

Yeah, let's reinvent the wheel anytime something is not available on all platforms in the world, wether or not you intent to target them...

If I target GNU systems, why can't I use GNU features ? If people really want to port my code, let them do so.

I did not know that the return value of snprintf is actually the length of the string that would be produced. I assumed I'd just get some error code - which would require re-trying with some larger buffer, thus the "loop".

Thanks for that :-)

Reply on news.ycombinator.com