5 ms·

Today. Timestamped almost right with this article. I'm sure it is correlated and not causal, but I'm also pretty sure the root cause for both is the same.

by TodPunk 12y ago

clort 12y ago
I'm not sure what your supposition about the root cause might mean. NetBSD very recently imported these functions (reallocarray and strtonum) to libc after much objection (over several years actually) to their poor APIs, yet finding that they crop up time and again in code used in base (and then multiple copies exist, in out of the way places). So, as a pragmatic solution they are now available from libc if _OPENBSD_SOURCE is defined. Cleaner API functions were proposed, with wrappers which would provide equivalent functionality for the OpenBSD functions. Some difference was noted, and recently fixed in these wrappers. The root cause for the NetBSD changes then, seems to be that these functions keep cropping up, and the job of libc is to provide commonly used functions. I believe the intention is, that the cleaner API is proposed to replace the original OpenBSD ones, which are not properly portable (strtonum for instance, returns hard coded english error strings in ASCII) The root cause for the blog entry by Ted Unangst is probably that he is an OpenBSD developer and was involved in creating these functions, which are now being criticised. These root causes don't seem the same to me.
- darklajid 12y ago
  You seem to have a much better understanding of the situation than I do. The remark about the hard coded error strings was interesting though, so I looked at the implementation [1]. I .. am not sure why that would be considered not portable? Admitted, I'm neither into C nor do I have experience in the field, but .. that seems to be easy to read, contains clear/concise error messages _on top_ of clear error codes. 1) Any consumer can ignore the string and map the error code to a message in Klingon or whatever else, no? 2) The function name is in ASCII/English. So are the parameter names. Most of your C code is probably reading ~somewhat~ like english, and usually is restricted to ASCII? Is it really a problem that this method returns both a well-defined number and a simple string in case of an error? Back to the first line: I .. am certainly clueless here and just watching from the sidelines. But I'm kinda serious about the questions and genuinely curious why you object to that part of the implementation? 1: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/strtonum.c?rev=1.7&content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib...
  - clort 12y ago
    for 1, the consumer is properly the user not the programmer.. and the user cannot ignore the error string in favour of the number if the programmer provided only that. Since the documentation specifies the error strings, for 2, the function can be called (as can any C function) from a source character set other than ASCII, as the compiler should handle that. The name is technically english its true and programmer needs to know some english, perhaps.. but the user does not need to know that if the error code is used, then the error string is superfluous, and C library functions are not in the habit of providing superfluous information. C is pretty low level after all. Here is more reading about the objections the NetBSD folk had with strtonum(3) http://mailing.netbsd.tech.userlevel.narkive.com/mZ37nlai/strtonum-3-from-openbsd
    - darklajid 12y ago
      Still confused. What is a user in your reply? I mean, an end user / my mom isn't going to call strtonum? Some developer does. And said developer can absolutely ignore the string's content? Test for success: errno is 0, errstrp is NULL Handle error: Use errno or errstrp - the latter gives you a bit more information (reports a different error for invalid ranges, too small vs. too large). But if you don't care, errno is fine, no? And we're still talking about the programmer here, as far as I'm concerned. Ted has a description of his intentions here [1]. I guess I'm confused why there's a fuzz about it, because technically this method should be good enough? I do have to shake my head at the "Even if intmax_t probably would have been a better choice, I think we’re sticking with long long just because it frustrates people unwilling to admit it doesn’t make a difference." remark, but .. other than that? Does it .. matter? 1: http://www.tedunangst.com/flak/post/the-design-of-strtonum http://www.tedunangst.com/flak/post/the-design-of-strtonum
      - clort 12y ago
        Yes, the user is the person who runs the program that they didn't write. They don't know that they called strtonum() testing for errno == 0 is not actually useful, since errno is not set except on error (that is by design of errno, it is always an indication of what the last error was, not that there was an error) and errstrp doesn't give the Klingon user you mentioned any information at all, since they can't read English. fafner said it better than I in https://news.ycombinator.com/item?id=9184734 https://news.ycombinator.com/item?id=9184734 and yes it does matter, for a standard libc function, because if you don't take care about setting standards, then your standards will be a mess.
- TodPunk 12y ago
  Eh, I'm no conspiracy theorist nor am I supposing foul play or pithiness or anything. I'm merely noting they're likely influenced by background conversation nobody's really paying attention to but the related folks. Tech is always a small crowd of people doing things in specific areas, and I'm not dumb enough to think they don't talk or read each other's stuff or whatnot. Probably read something on a mailing list or in IRC or something, similar sparks happened, they led down the chain, then we end up here, that sort of thing. It's not bad, just human behavior in small groups. The politics behind it aren't interesting to me, I'm just noting that it's not likely as completely quarantined from each other as they might complain, even if they don't realize such. That's totally cool with me, even if my supposition (again, unfounded even if it is how such things often occur) is completely incorrect in this particular instance. =c)

Today. Timestamped almost right with this article. I'm sure it is correlated and not causal, but I'm also pretty sure the root cause for both is the same.

by TodPunk 12y ago

Today. Timestamped almost right with this article. I'm sure it is correlated and not causal, but I'm also pretty sure the root cause for both is the same.

clort 12y ago

I'm not sure what your supposition about the root cause might mean. NetBSD very recently imported these functions (reallocarray and strtonum) to libc after much objection (over several years actually) to their poor APIs, yet finding that they crop up time and again in code used in base (and then multiple copies exist, in out of the way places). So, as a pragmatic solution they are now available from libc if _OPENBSD_SOURCE is defined. Cleaner API functions were proposed, with wrappers which would provide equivalent functionality for the OpenBSD functions. Some difference was noted, and recently fixed in these wrappers. The root cause for the NetBSD changes then, seems to be that these functions keep cropping up, and the job of libc is to provide commonly used functions. I believe the intention is, that the cleaner API is proposed to replace the original OpenBSD ones, which are not properly portable (strtonum for instance, returns hard coded english error strings in ASCII) The root cause for the blog entry by Ted Unangst is probably that he is an OpenBSD developer and was involved in creating these functions, which are now being criticised. These root causes don't seem the same to me.

darklajid 12y ago
You seem to have a much better understanding of the situation than I do. The remark about the hard coded error strings was interesting though, so I looked at the implementation [1]. I .. am not sure why that would be considered not portable? Admitted, I'm neither into C nor do I have experience in the field, but .. that seems to be easy to read, contains clear/concise error messages _on top_ of clear error codes. 1) Any consumer can ignore the string and map the error code to a message in Klingon or whatever else, no? 2) The function name is in ASCII/English. So are the parameter names. Most of your C code is probably reading ~somewhat~ like english, and usually is restricted to ASCII? Is it really a problem that this method returns both a well-defined number and a simple string in case of an error? Back to the first line: I .. am certainly clueless here and just watching from the sidelines. But I'm kinda serious about the questions and genuinely curious why you object to that part of the implementation? 1: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/strtonum.c?rev=1.7&content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib...
- clort 12y ago
  for 1, the consumer is properly the user not the programmer.. and the user cannot ignore the error string in favour of the number if the programmer provided only that. Since the documentation specifies the error strings, for 2, the function can be called (as can any C function) from a source character set other than ASCII, as the compiler should handle that. The name is technically english its true and programmer needs to know some english, perhaps.. but the user does not need to know that if the error code is used, then the error string is superfluous, and C library functions are not in the habit of providing superfluous information. C is pretty low level after all. Here is more reading about the objections the NetBSD folk had with strtonum(3) http://mailing.netbsd.tech.userlevel.narkive.com/mZ37nlai/strtonum-3-from-openbsd
  - darklajid 12y ago
    Still confused. What is a user in your reply? I mean, an end user / my mom isn't going to call strtonum? Some developer does. And said developer can absolutely ignore the string's content? Test for success: errno is 0, errstrp is NULL Handle error: Use errno or errstrp - the latter gives you a bit more information (reports a different error for invalid ranges, too small vs. too large). But if you don't care, errno is fine, no? And we're still talking about the programmer here, as far as I'm concerned. Ted has a description of his intentions here [1]. I guess I'm confused why there's a fuzz about it, because technically this method should be good enough? I do have to shake my head at the "Even if intmax_t probably would have been a better choice, I think we’re sticking with long long just because it frustrates people unwilling to admit it doesn’t make a difference." remark, but .. other than that? Does it .. matter? 1: http://www.tedunangst.com/flak/post/the-design-of-strtonum http://www.tedunangst.com/flak/post/the-design-of-strtonum
    - clort 12y ago
      Yes, the user is the person who runs the program that they didn't write. They don't know that they called strtonum() testing for errno == 0 is not actually useful, since errno is not set except on error (that is by design of errno, it is always an indication of what the last error was, not that there was an error) and errstrp doesn't give the Klingon user you mentioned any information at all, since they can't read English. fafner said it better than I in https://news.ycombinator.com/item?id=9184734 https://news.ycombinator.com/item?id=9184734 and yes it does matter, for a standard libc function, because if you don't take care about setting standards, then your standards will be a mess.
TodPunk 12y ago
Eh, I'm no conspiracy theorist nor am I supposing foul play or pithiness or anything. I'm merely noting they're likely influenced by background conversation nobody's really paying attention to but the related folks. Tech is always a small crowd of people doing things in specific areas, and I'm not dumb enough to think they don't talk or read each other's stuff or whatnot. Probably read something on a mailing list or in IRC or something, similar sparks happened, they led down the chain, then we end up here, that sort of thing. It's not bad, just human behavior in small groups. The politics behind it aren't interesting to me, I'm just noting that it's not likely as completely quarantined from each other as they might complain, even if they don't realize such. That's totally cool with me, even if my supposition (again, unfounded even if it is how such things often occur) is completely incorrect in this particular instance. =c)