3 ms·

I don't understand what you mean. Why can't we just debate the question without speculating about motivations of the people raising/answering the question?

marcodiego 5y ago
I think I misread and misjudged you. I'm sincerely sorry for that. Maybe it is a sensible subject for me or I've been living with people asking rhetorical redundant questions as a passive agressive form for disqualifying others. I read your question as: "I can't see any reason this performance is needed, maybe it is really incompetence or pedantism from GNU developers." But I think it is prejudice on my part. Sorry. EDIT: grammar.
- akkartik 5y ago
  Thank you! And yes, I admit you were partly right. Questions often have some component of rhetorical quality. It's not always yes/no on whether it's a rhetorical question or not. But either way, I find (based on experience teaching) that the best way to answer a question is just by treating it as genuine. Past a point if I decide someone's acting in bad faith I just disengage. Anyways, back to the original question, I do believe that a lot of programmers (I don't buy OP's separation between GNU and non-GNU) over-engineer things without regard to the costs created by over-engineered code. My default assumption is that that's happening in yes. If it's happening in such a small program where it's so obvious, the same tendencies are likely to be at work in more complex programs like cat and awk and cc. Happy to debate that :)
  - marcodiego 5y ago
    Debating that... I think https://news.ycombinator.com/item?id=14543640 https://news.ycombinator.com/item?id=14543640 is more plausible.
    - akkartik 5y ago
      Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. That whole thread makes me sad. Another, more subtle way IP is ruining the world. But that's neither here nor there on this debate. Just to flesh out my current thinking a bit more: * I'd really like a study to understand how much complexity old GNU tools have gained in the past 2 decades. Because that would not be due to copyright concerns. But I'm not sure I have the necessary skills. (I'd like this study for non-GNU as well, but I assume copyright is not a concern there so the study doesn't have to set crisp time bounds.) * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others.
      - marcodiego 5y ago
        > Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. You are welcome! Considering the karma I got from that answer, I don't think I'm the only one who misread you. If you want a piece of advice: starting a question like that with "Genuinely curious: ..." is my strategy to prevent this kind of misunderstanding. > * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others. As Drew DeVault's says, it was his code which was broken. I know glic code is complex, but it is battle tested, mature and highly robust. I'd bet there are good reasons for that complexity. If I was really curious as to why, I'd try asking devs directly to avoid making them look bad by making public statements about it. Now, I looked in scdoc code. The solution was to cast the parameters to "unsigned char". Considering the code uint32_t ch; isalnum(ch); compiles without warning (even with -Wall -Wextra) on my machine, I'd consider this a potential vulnerability for programs using this function. I can't see why glibc developers don't turn isalnum into a macro that automatically casts its parameter (when its address is not taken). I'll consider asking them this weekend. EDIT: possible nice finding: https://news.ycombinator.com/item?id=24597461 https://news.ycombinator.com/item?id=24597461 EDIT2: part of the reason: "unsigned char" can't hold EOF.

marcodiego 5y ago

I think I misread and misjudged you. I'm sincerely sorry for that. Maybe it is a sensible subject for me or I've been living with people asking rhetorical redundant questions as a passive agressive form for disqualifying others. I read your question as: "I can't see any reason this performance is needed, maybe it is really incompetence or pedantism from GNU developers." But I think it is prejudice on my part. Sorry. EDIT: grammar.

akkartik 5y ago
Thank you! And yes, I admit you were partly right. Questions often have some component of rhetorical quality. It's not always yes/no on whether it's a rhetorical question or not. But either way, I find (based on experience teaching) that the best way to answer a question is just by treating it as genuine. Past a point if I decide someone's acting in bad faith I just disengage. Anyways, back to the original question, I do believe that a lot of programmers (I don't buy OP's separation between GNU and non-GNU) over-engineer things without regard to the costs created by over-engineered code. My default assumption is that that's happening in yes. If it's happening in such a small program where it's so obvious, the same tendencies are likely to be at work in more complex programs like cat and awk and cc. Happy to debate that :)
- marcodiego 5y ago
  Debating that... I think https://news.ycombinator.com/item?id=14543640 https://news.ycombinator.com/item?id=14543640 is more plausible.
  - akkartik 5y ago
    Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. That whole thread makes me sad. Another, more subtle way IP is ruining the world. But that's neither here nor there on this debate. Just to flesh out my current thinking a bit more: * I'd really like a study to understand how much complexity old GNU tools have gained in the past 2 decades. Because that would not be due to copyright concerns. But I'm not sure I have the necessary skills. (I'd like this study for non-GNU as well, but I assume copyright is not a concern there so the study doesn't have to set crisp time bounds.) * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others.
    - marcodiego 5y ago
      > Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. You are welcome! Considering the karma I got from that answer, I don't think I'm the only one who misread you. If you want a piece of advice: starting a question like that with "Genuinely curious: ..." is my strategy to prevent this kind of misunderstanding. > * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others. As Drew DeVault's says, it was his code which was broken. I know glic code is complex, but it is battle tested, mature and highly robust. I'd bet there are good reasons for that complexity. If I was really curious as to why, I'd try asking devs directly to avoid making them look bad by making public statements about it. Now, I looked in scdoc code. The solution was to cast the parameters to "unsigned char". Considering the code uint32_t ch; isalnum(ch); compiles without warning (even with -Wall -Wextra) on my machine, I'd consider this a potential vulnerability for programs using this function. I can't see why glibc developers don't turn isalnum into a macro that automatically casts its parameter (when its address is not taken). I'll consider asking them this weekend. EDIT: possible nice finding: https://news.ycombinator.com/item?id=24597461 https://news.ycombinator.com/item?id=24597461 EDIT2: part of the reason: "unsigned char" can't hold EOF.