• (disco)

    Yes, it really does open and close the file handle for every xwrite call. This means that it opens and closes it 3 times PER TAG when writing out the XML.

    ClueBat™ is insufficient for this scenario; more… drastic measures are required…

  • (disco) in reply to RaceProUK

    something like this?

    [image]
  • (disco) in reply to accalia

    I'm so disappointed, I read that as Megatron Hammer at first.

  • (disco) in reply to accalia

    Or one of these: [image]

  • (disco)

    Remind me how many write operations are supported by the SSD, please ?

    And how many sectors it has still free ?

    With the naughty flush, it is is honored, there is to be such number of rewritten sectors so that the drive will be dead sooner than expected.

  • (disco) in reply to thegoryone

    no, that's a megatron blaster

    [image]
  • (disco)

    Yo Dawg, I heard you liked writes, so I put a write in your write...

  • (disco)

    No, this is clearly a case of brillance because as everyone knows, RAM is slower than hard drives

    Filed Under: :trolleybus:

  • (disco) in reply to RaceProUK
    RaceProUK:
    more… drastic measures are required…

    Not… the clue cactus?

  • (disco)

    TRWTF is the use of the word 'parser'

    Parsers parse XML they don't write it.

    #pedantic.

  • (disco)

    I can soooooo relate to this. I fixed some code that did something like this writing CSV files: two opens per field, one for the data, one for the delimiter. It didn't close or explicitly flush, though, except at the end of the row.

  • (disco)

    // xml_t is - essentially - a linked list of xml nodes.

    At first, I was wondering WTF this comment meant. What does "essentially" mean? It's either a linked list or it isn't. Then I looked at the code some more. Apparently, an xml_t can only have one child node. If a node has a second child node, it's represented by pSibling. For more than two child nodes, each one is the pSibling of the previous child node.

    Searching Google for "xml_t" has this article as the third result, so I'm assuming that it's a homemade class/struct. It seems kinda screwy to me, but then again, I prefer languages with built-in list types.

  • (disco)

    Interestingly, though, despite all that nonsense, the code appears to work... horribly inefficiently, but it generates real XML as far as I can tell. One actual bug that stands out is that it passes bNew in the recursive call to xmlwrite_file instead of 0 which could potentially mean it overwrites all the data it's written so far and starts a new file... but that only comes up if the root node has a next-sibling, which should never happen in a real XML document.

    Only other thing is that the nodevalue isn't escaped (unless the escaping logic is in the FillNodeValue function, which isn't given), which would be my first guess as to what's causing the problem. My second guess would be a bug somewhere in FillNodeAttribs (or possibly FillNodeName/FillNodeValue), which we don't see here.

    Of course, whether or not it's worth tracking down the actual bug rather than dusting off and nuking it from orbit is a different question...

  • (disco) in reply to Dragnslcr
    Dragnslcr:
    Searching Google for "xml_t" has this article as the third result, so I'm assuming that it's a homemade class/struct.

    invalid XML was being output by a homegrown XML parser

    Good buttumption. .

  • (disco) in reply to RFoxmich
    RFoxmich:
    TRWTF is the use of the word 'parser'

    Parsers parse XML they don't write it.

    #pedantic.

    I'm "anonymous" in the submission. Yeah, you're right about the parser terminology but this thing was ALSO a parser though. It did everything you could need to do with xml... just very, very poorly.

    For reference, the bug I tracked down was that when removing nodes from the xml struct, it didn't actually remove them, it moved pointers around. While this sort of worked, it ended up causing issues when writing out because the nodes still existed and still could be accessed under certain conditions.

    Oh and this thing likes to write out XML that looks like this:

    <node><10></node>

    which of course isn't valid XML sigh

  • (disco) in reply to Jerome_Grimbert
    Jerome_Grimbert:
    Remind me how many write operations are supported by the SSD, please ?

    And how many sectors it has still free ?

    With the naughty flush, it is is honored, there is to be such number of rewritten sectors so that the drive will be dead sooner than expected.

    I'd wager that these writes will probably get cached and coalesced by the OS. You'll still pay the performance cost of a bazillion syscalls, but I don't think it's going to be a bazillion real I/O operations on the disk.

    The flush itself does nothing, since the fclose() would have done the flushing anyways. On other hand, had the incompetent developer known about fsync(2), then we could be sure that each individual write operation would be hitting the disk and waiting for that to complete (assuming, of course, that the disk controller isn't lying to the OS that the writes have hit durable storage instead of its on-board cache, as some disk controllers are wont to do).

  • (disco)

    TRWTF is PH... oh wait! It's C!

    See? You can do stupid shit in any language.

    Now, I'm going to play devils advocate here, but maybe, just maybe, whoever wrote this didn't intended this behavior. I mean, this guy clearly knew what he was doing, he has some recursion, some malloc, some fflush and the thing works with some quirks, but hey, it's C, it probably doesn't even have unit tests.

  • (disco)

    You had me at "homegrown Xml parser". In C, no less!

  • (disco)

    http://www.huffingtonpost.com/2012/07/16/jonah-falcon-largest-penis-frisked-by-tsa_n_1675767.html

Leave a comment on “Open And Shut”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article