5 ms·

Thanks for the reply. > GNU software is also often very bloated and overengineered, and often found in critical places like glibc. My memory is rusty - aren't

by jabot 10y ago

Thanks for the reply. > GNU software is also often very bloated and overengineered, and often found in critical places like glibc. My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient? > Their coding styles are highly questionable and I disagree with a lot of their design decisions. On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example?

Sir_Cmpwn 10y ago
>My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient? 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. >On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example? Maybe in a blog post someday.
- jabot 10y ago
  > 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...]
  - Sir_Cmpwn 10y ago
    >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.
    - palunon 10y ago
      >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.
    - jabot 10y ago
      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 :-)

by jabot 10y ago

Sir_Cmpwn 10y ago

>My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient? 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. >On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example? Maybe in a blog post someday.

jabot 10y ago
> 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...]
- Sir_Cmpwn 10y ago
  >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.
  - palunon 10y ago
    >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.
  - jabot 10y ago
    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 :-)