• (nodebb)

    TRWTF is reinventing the strtok/strtok_r wheel.

  • (nodebb) in reply to Medinoc

    Yop, it's weird. Nothing added there, no shadow copy, no variable length delimiter, it's straight up the same destructive method.

  • (nodebb) in reply to Medinoc

    There is a subtle difference between strtok() and this code - libc-s strtok() skips empty values between tokens. So if your data is foo::bar then strtok() happily finds two values - "foo" and "bar". This code also finds the blank string between them.

  • (nodebb)

    TRWTF is C's looping mechanisms that allow things like Duff's device and this while/while monstrosity.

  • (author) in reply to colejohnson66

    Most languages would allow this while/while thing. Most languages allow you to write while(condition); and don't complain. That's all this is.

  • Anon (unregistered)

    Aside from the double while typo, which will be ignored by the compiler anyway, this seems fine.

  • (nodebb)

    strtok() also only does one iteration of this loop and requires the caller to repeatedly call it, using the heinous implementation of storing global state and having a null pointer input mean to continue processing the same input (hence the need for strtok_r()). This implementation also eliminates using global state (good), but it always fully tokenizes the input and doesn't give the caller the option of only tokenizing it once or a few times (which may be fine for this particular application).

  • Duston (unregistered)

    But but but it's portable!

  • (nodebb) in reply to adamantoise

    strtok() is often used in loops similar to this one.

  • (nodebb) in reply to Anon

    Aside from the double while typo, which will be ignored by the compiler anyway

    It's not guaranteed to be ignored, especially if you've disabled optimisations. It won't generate much codecitation needed, but it won't necessarily generate none at all. (If optimisations are disabled or if the condition of the two while()s involves a function call, it must evaluate the second while()'s condition once, or the presence of the optimiser can be detected.)

    (1) I did work with a compiler once (in 1992) that, in its most "aggressive" optimisation mode, when presented with a while(1) deliberately infinite loop, generated code to load a 1 into a register, then compare it to zero, and only branch back to the beginning of the loop if the 1 didn't match the 0...

  • Duke of New York (unregistered)

    Case fall-through is a deliberate feature of C, not an oversight. When used as intended it avoids needless duplication of code, which is not "monstrous", but beautiful.

  • Alan Scrivener (unregistered)

    So you end up with something like a string array except you can't tell where the end is?

  • This was AI spam that made Remy laugh, so he let it through (unregistered)

    "Interesting topic! String in the colon is a serious issue that requires medical attention. It’s crucial to address such concerns with proper care and professional advice. Thanks for bringing awareness to this topic. Do you have any additional information or resources for those dealing with similar issues?"

  • (nodebb) in reply to Duke of New York

    right up until you have to maintain it

  • (nodebb)

    Among other WTFs, the

    *p++ = 0;

    thing is just nasty and requires you to know far too much about the language.

    *p = 0;
p += 1;

    is harder to type but much much easier to read.

  • Duke of New York (unregistered) in reply to thosrtanner

    Nothing helps with maintaining code as much as having less to maintain.

    Are you really going to claim that C demands knowing more syntax than other industry languages? Really?

  • Naomi (unregistered)

    Fall-through in case statements is fine in principle; it just should be explicit. Imagine a setup where fall-through is triggered by continue, and it's a compile-time error for any code path in a (non-empty) label to reach the start of the next label. You can still abuse it, if you really want to, but I feel like that's on you (as opposed to the current setup, where it's easy to do the wrong thing by accident).

  • Anon (unregistered) in reply to Steve_The_Cynic

    If you explicitly tell the compiler not to ignore it, then it won’t ignore it, but then TRWTF would be releasing unoptimised builds. And I wouldn’t have said the compiler would ignore the additional while condition if it contained code that couldn’t be ignored.

    In practice, every compiler I have immediate access to (back to 1998’s Visual C/C++ 6.0) when presented with this specific code, ignores the additional while clause unless I explicitly /Od to tell it not to.

  • (nodebb) in reply to Anon

    "ignores" is the wrong word. It must not actually ignore it. It's allowed to generate no code if there are no side effects, but it has to inspect it to see if there are actual or potential side-effects. (Or use of volatilevariables...)

  • Anon (unregistered) in reply to Steve_The_Cynic

    I’m happy that my use of “ignore” accurately and succinctly conveyed my meaning. If it didn’t for you, then I’m also happy for you to parse my comments and replace the use of that shorthand with whichever construction of the concept “generates no output” you find appropriate.

  • Mr Bits (unregistered) in reply to Anon
    Comment held for moderation.
  • no (unregistered) in reply to Duke of New York
    Comment held for moderation.
  • (nodebb)

    I'm reminded of how BASIC on e.g. the Commodore 64 turned out to leave the program code in a munged state after a certain int-overflow situation, because it destructively modified a string within the program code (and then crashed out before undoing the damage).

Leave a comment on “String in your Colon”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article