{"items": [{"author": "Bil", "source_link": "https://www.facebook.com/jefftk/posts/770652449192?comment_id=770669924172", "anchor": "fb-770669924172", "service": "fb", "text": "2016 and we're still at this?? :-(", "timestamp": "1455228795"}, {"author": "Jeff Kaufman", "source_link": "https://www.facebook.com/jefftk/posts/770652449192?comment_id=770669924172&reply_comment_id=770672838332", "anchor": "fb-770669924172_770672838332", "service": "fb", "text": "→ That dirname is very old is pretty much why it's in such sad shape. It was standardized after there were multiple competing implementations.", "timestamp": "1455230885"}, {"author": "Bil", "source_link": "https://www.facebook.com/jefftk/posts/770652449192?comment_id=770669924172&reply_comment_id=770678447092", "anchor": "fb-770669924172_770678447092", "service": "fb", "text": "→ Yup. We solved this problem 20 years ago. (At least.) You should be upset that you're dealing with it again. You should be screaming at the people responsible and pushing them to actually show some responsibility. Historical mistakes do not validate our continuing them. Blah, blah, blah... software quality... blah, blah... reliability... Gas Pedals in cars all work the same... blah, blah... BE ANGRY!", "timestamp": "1455233685"}, {"author": "Daniel", "source_link": "https://www.facebook.com/jefftk/posts/770652449192?comment_id=770701356182", "anchor": "fb-770701356182", "service": "fb", "text": "Returning a reference to a static buffer??? That code can't actually be running in serious OSes, please tell me you just made that up to nerd snipe your programmer friends.", "timestamp": "1455245447"}, {"author": "Jeff Kaufman", "source_link": "https://www.facebook.com/jefftk/posts/770652449192?comment_id=770701356182&reply_comment_id=770929144692", "anchor": "fb-770701356182_770929144692", "service": "fb", "text": "→ The glibc dirname, used just about everywhere, returns a pointer to a static buffer. So yes, running in serious OSs.
The list of other non threadsafe functions is a fun place to look for functions that do crazy things, and many of them are not a good idea to use in modern code: http://pubs.opengroup.org/.../functions/V2_chap02.html...
For example strtok not only modifies it's input to add NULL separators, it stores state in a static pointer so it knows where to resume if you call it again. So users of strtok in parsing loops have to make sure they don't call anything that calls strtok under the hood!
Or getlogin, which may or may not use a static buffer of LOGIN_NAME_MAX for its return value.", "timestamp": "1455277639"}, {"author": "Daniel", "source_link": "https://plus.google.com/104241554778763268733", "anchor": "gp-1455927609773", "service": "gp", "text": "That is interesting, and I will now avoid dirname if I code in C. I wish the standard library avoided writing const-unsafe (or otherwise nonconforming) code; I know it\u2019s sometimes unavoidable, but that glibc implementation is not one of those times. This is undefined behavior, which for my test program turns into a segfault when I try to actually modify the data (because it\u2019s mapped read-only).\n
\n
\nAlso, in the nearly-conforming function you wrote, you declare\u00a0last_slash as a char*, but then have\u00a0path[last_slash] = '\\0' instead of *last_slash = '\\0'. I know at the end you say you haven\u2019t tried to compile these, but that still bothered me. Is there any chance you could fix it or move that disclaimer to the top of the article?", "timestamp": 1455927609}, {"author": "Jeff Kaufman", "source_link": "https://plus.google.com/103013777355236494008", "anchor": "gp-1455943357996", "service": "gp", "text": "@Daniel\n\u00a0\"Is there any chance you could fix it?\"\n
\n
\nDone! \u00a0Thanks!", "timestamp": 1455943357}]}