4 ms·

But once you get down to the unit data values inside any of those aggregates, you're still dealing with either characters, ints, floats, strings, arrays, and th

But once you get down to the unit data values inside any of those aggregates, you're still dealing with either characters, ints, floats, strings, arrays, and they each have their own individual access patterns and, more importantly, modification functions. You can't add a number to a string, only to another number. If you are dealing with a float, you better be careful how you check it for equality. If it's pure binary, what kind of byte is it? Ascii, unicode code point, unsigned byte, signed multi-byte int, ... whatever. There's no escaping the details, friend. And your saying "everything is a word" for assembler is just plain wrong.

enriquto 2y ago
> And your saying "everything is a word" for assembler is just plain wrong. I also love x87 registers, but they are becoming rarer these days.
- MrMcCall 2y ago
  Your profile says "just another C hacker". I learned C from reading K&R in the late 80s. Every C compiler I've worked with could output the code as assembler, so C is really a thin layer of abstraction that wraps assembler. Having programmed in pure assembler before, I understand the benefits of C's abstractions, which began with its minimal, but helpful, type system. Should I not be taking you seriously? We are not just talking with each other but sharing our expertise with those who may be reading. Sometimes I forget that other people can just be unpleasant on purpose. I find no other explanation for your response.
  - enriquto 2y ago
    Sorry man, I was just trying to spew some harmless banter.
    - MrMcCall 2y ago
      Apology accepted. No worries. It's just that my post rate is severely limited, even to reply to people replying to me. I'm on some kind of naughty list in "the algorithm", which is something beyond dang's control, by what I gather from his reproachments to me. That's why I've got to minimize my number of replies. And 'harmless banter' doesn't communicate in pure text, friend. Peace be with you.
erikerikson 2y ago
> You can't add a number to a string Haven't written JavaScript?
- MrMcCall 2y ago
  I don't care if it "can" be done, the results will be garbage unless you are very, very careful. And Javascript is garbage no matter how many people use it successfully, as I have done professionally.
- SAI_Peregrinus 2y ago
  Or C. It just turns into pointer math. Godbolt example here[1], just make sure the `int` is an offset within the bounds of the char* and it's well-defined. [1] https://godbolt.org/z/YWKK1P7zj https://godbolt.org/z/YWKK1P7zj
SAI_Peregrinus 2y ago
> You can't add a number to a string, only to another number. Works in C, as long as the integer keeps the resulting pointer within the bounds of the allocation. See a trivial example[1]. [1] https://godbolt.org/z/YWKK1P7zj https://godbolt.org/z/YWKK1P7zj
- MrMcCall 2y ago
  Ok, sure. But I doubt that's a good practice. In fact, I can't possibly imagine it not being a horrible idea. So, I ask: what size and signedness of int? 1, 2, 4, 8? What if the string is of length 3, 2, 1, 0? Why bother with all those corner cases. Everything has a memory layout and appropriate semantics of representation and modification. Pushing those definitions is a recipe for problems. I like to keep it simple, keeping the semantics simple in how I code specific kinds of transforms. The less kinds of techniques you use, the less kinds of patterns you have to develop, test, and ensure consistent application of across a codebase. Especially down in C land, which is effectively assembler. Gone are the days of Carmac having to save bytes in Doom, unless you're doing embedded work, in which case that's all the more reason to be very careful how you handle those bytes.
  - SAI_Peregrinus 2y ago
    > But I doubt that's a good practice That's entirely how "string" indexing works in C. Strings in C are just pointers to `char` with some valid allocation size. As long as the integer used for the pointer offset results in a pointer into the allocation after the addition, it's valid to dereference the result. Remember, `array[index]` is syntactic sugar for `(array + index)` in C. Lots of the C stdlib string functions use this, e.g. `char strchr(const char* str, int character)` has a naive implementation as a simple loop comparing `char`s[1]. Glibc does it one `unsigned long int` at a time, as an optimization, with some extra work at the start going one `char` at a time to ensure alignment. > So, I ask: what size and signedness of int? 1, 2, 4, 8? Doesn't matter, as long as the result of the addition points to within the pointer's allocation. Otherwise you get UB as usual. > What if the string is of length 3, 2, 1, 0? Doesn't matter, as long as the result of the addition points to within the pointer's allocation. Otherwise you get UB as usual. For a 0-length string (pointer to '\0\'), the only valid value to add is 0. > The less kinds of techniques you use, the less kinds of patterns you have to develop, test, and ensure consistent application of across a codebase. 100% agreed. The less C you use for string handling the better. C strings are fundamentally fragile. [1] https://godbolt.org/z/4T835cdKb https://godbolt.org/z/4T835cdKb

enriquto 2y ago

> And your saying "everything is a word" for assembler is just plain wrong. I also love x87 registers, but they are becoming rarer these days.

MrMcCall 2y ago
Your profile says "just another C hacker". I learned C from reading K&R in the late 80s. Every C compiler I've worked with could output the code as assembler, so C is really a thin layer of abstraction that wraps assembler. Having programmed in pure assembler before, I understand the benefits of C's abstractions, which began with its minimal, but helpful, type system. Should I not be taking you seriously? We are not just talking with each other but sharing our expertise with those who may be reading. Sometimes I forget that other people can just be unpleasant on purpose. I find no other explanation for your response.
- enriquto 2y ago
  Sorry man, I was just trying to spew some harmless banter.
  - MrMcCall 2y ago
    Apology accepted. No worries. It's just that my post rate is severely limited, even to reply to people replying to me. I'm on some kind of naughty list in "the algorithm", which is something beyond dang's control, by what I gather from his reproachments to me. That's why I've got to minimize my number of replies. And 'harmless banter' doesn't communicate in pure text, friend. Peace be with you.

erikerikson 2y ago

> You can't add a number to a string Haven't written JavaScript?

MrMcCall 2y ago
I don't care if it "can" be done, the results will be garbage unless you are very, very careful. And Javascript is garbage no matter how many people use it successfully, as I have done professionally.
SAI_Peregrinus 2y ago
Or C. It just turns into pointer math. Godbolt example here[1], just make sure the `int` is an offset within the bounds of the char* and it's well-defined. [1] https://godbolt.org/z/YWKK1P7zj https://godbolt.org/z/YWKK1P7zj

SAI_Peregrinus 2y ago

> You can't add a number to a string, only to another number. Works in C, as long as the integer keeps the resulting pointer within the bounds of the allocation. See a trivial example[1]. [1] https://godbolt.org/z/YWKK1P7zj https://godbolt.org/z/YWKK1P7zj

MrMcCall 2y ago
Ok, sure. But I doubt that's a good practice. In fact, I can't possibly imagine it not being a horrible idea. So, I ask: what size and signedness of int? 1, 2, 4, 8? What if the string is of length 3, 2, 1, 0? Why bother with all those corner cases. Everything has a memory layout and appropriate semantics of representation and modification. Pushing those definitions is a recipe for problems. I like to keep it simple, keeping the semantics simple in how I code specific kinds of transforms. The less kinds of techniques you use, the less kinds of patterns you have to develop, test, and ensure consistent application of across a codebase. Especially down in C land, which is effectively assembler. Gone are the days of Carmac having to save bytes in Doom, unless you're doing embedded work, in which case that's all the more reason to be very careful how you handle those bytes.
- SAI_Peregrinus 2y ago
  > But I doubt that's a good practice That's entirely how "string" indexing works in C. Strings in C are just pointers to `char` with some valid allocation size. As long as the integer used for the pointer offset results in a pointer into the allocation after the addition, it's valid to dereference the result. Remember, `array[index]` is syntactic sugar for `(array + index)` in C. Lots of the C stdlib string functions use this, e.g. `char strchr(const char* str, int character)` has a naive implementation as a simple loop comparing `char`s[1]. Glibc does it one `unsigned long int` at a time, as an optimization, with some extra work at the start going one `char` at a time to ensure alignment. > So, I ask: what size and signedness of int? 1, 2, 4, 8? Doesn't matter, as long as the result of the addition points to within the pointer's allocation. Otherwise you get UB as usual. > What if the string is of length 3, 2, 1, 0? Doesn't matter, as long as the result of the addition points to within the pointer's allocation. Otherwise you get UB as usual. For a 0-length string (pointer to '\0\'), the only valid value to add is 0. > The less kinds of techniques you use, the less kinds of patterns you have to develop, test, and ensure consistent application of across a codebase. 100% agreed. The less C you use for string handling the better. C strings are fundamentally fragile. [1] https://godbolt.org/z/4T835cdKb https://godbolt.org/z/4T835cdKb