| 01:34.21 | *** join/#stepcode hoiji (671b082c@gateway/web/freenode/ip.103.27.8.44) |
| 01:44.15 | hoiji | mpictor: thanks for your both of your review:) According to the coding conventions of stepcode, where should I put the `define` workround of strtoull? |
| 01:46.11 | hoiji | ^I meant in which file |
| 01:55.20 | *** join/#stepcode cstirk (~Carola@static-67-62-121-234.dsl.cavtel.net) |
| 03:30.29 | *** join/#stepcode hoiji (671b082c@gateway/web/freenode/ip.103.27.8.44) |
| 09:37.05 | *** join/#stepcode hoiji (671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
| 13:02.26 | *** join/#stepcode hoiji (671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
| 13:20.27 | hoiji | mpictor: please ignore my question about convention of placing _strtoui64 |
| 13:37.24 | *** join/#stepcode hoiji (uid27128@gateway/web/irccloud.com/x-reazsudumbjxgwvd) |
| 13:38.19 | *** part/#stepcode hoiji (uid27128@gateway/web/irccloud.com/x-reazsudumbjxgwvd) |
| 14:10.58 | *** join/#stepcode hoiji_ (~hoiji@115.240.49.143) |
| 14:12.20 | *** part/#stepcode hoiji_ (~hoiji@115.240.49.143) |
| 14:29.05 | *** join/#stepcode hoiji (uid27128@gateway/web/irccloud.com/x-reazsudumbjxgwvd) |
| 14:30.58 | *** join/#stepcode hoiji (~hoiji@115.240.49.143) |
| 15:12.09 | *** join/#stepcode cstirk (~Carola@pool-71-163-229-188.washdc.east.verizon.net) |
| 15:16.40 | hoiji | mpictor: where will I find information about the lowest version of g++ and msvc supported by the code |
| 15:18.31 | hoiji | ^sorry that question was meant for everybody |
| 16:18.55 | brlcad | hoiji: there's not been any concerted effort to make stepcode be incredibly backwards-compatible |
| 16:19.28 | brlcad | I'd expect 4.2+ to work most of the time for g++ |
| 16:19.42 | brlcad | msvc, at least 2005 |
| 16:36.19 | hoiji | thanks. Actually I want to use a library function of g++. However this function was added into MSVC only in its 2013 version. Should I go with it? |
| 16:36.44 | brlcad | what function? |
| 16:37.28 | hoiji | strtoull |
| 16:38.19 | brlcad | you have a need to print an unsigned long long?? |
| 16:38.45 | brlcad | s/print/parse/ |
| 16:39.01 | hoiji | yes |
| 16:39.09 | brlcad | infobot: mode #stepcode sed 0 |
| 16:39.20 | brlcad | hoiji: can you explain? |
| 16:39.27 | hoiji | ok |
| 16:39.48 | hoiji | I want to read an instance ID from a step file |
| 16:40.27 | hoiji | And since the instance id is of 64 bytes. I am using unsigned long long |
| 16:42.08 | hoiji | mpictor suggested using _strtoui64 |
| 16:43.12 | hoiji | however the problem with it is that the error values returned by _strtoui64 (MSVC) and strtoull (g++) are different |
| 16:43.42 | hoiji | And my subsequent code is dependent upon the error value |
| 16:43.59 | hoiji | ^64 bits |
| 17:02.03 | brlcad | you care about the actual value or just that an error occurred? |
| 17:02.12 | hoiji | both |
| 17:02.17 | brlcad | if you get any error back, I'd think that's a problem |
| 17:02.43 | hoiji | I want to detect overflows |
| 17:04.38 | hoiji | In a normal case I will just convert the values into unsigned long long. |
| 17:04.57 | brlcad | heh, why? not like you can do much about a 64-bit unsigned overflow :) |
| 17:05.40 | hoiji | by normal case I meant that when their is no overflow |
| 17:05.54 | hoiji | If their is an overflow I want to report it |
| 17:06.06 | *** join/#stepcode mailtoandrew (~mailtoand@193.0.146.108) |
| 17:06.32 | brlcad | but how's that any different than reporting "Failed to parse ID" .. it's a failure either way that will probably halt all parsing |
| 17:06.42 | brlcad | overflow or not |
| 17:07.07 | brlcad | giving the specific reason seems unnecessary |
| 17:07.15 | brlcad | or at least unhelpful |
| 17:08.03 | hoiji | the problem is that I can detect overflow in strtoull only if the errno is set to ERANGE |
| 17:09.37 | brlcad | that's only a problem if detecting overflow vs detecting error has some value |
| 17:09.41 | brlcad | what value is it providing? |
| 17:12.55 | hoiji | sorry I wasn't able to get what you meant by detecting overflow vs detecting error |
| 17:13.32 | brlcad | i'm saying it doesn't matter what the error was |
| 17:13.57 | brlcad | if you fail to parse an ID, parsing is screwed |
| 17:14.04 | brlcad | for whatever reason |
| 17:14.36 | brlcad | it doesn't matter if it was an overflow or because the computer was on fire |
| 17:15.48 | brlcad | so don't bother .. you can just wrap a #if !defined(HAVE_STRTOULL) && defined(HAVE__STRTOUI64) #define strtoull _strtoui64 #endif |
| 17:16.34 | brlcad | and call if (!strtoull(...)) abort("the world is ending"; |
| 17:18.02 | hoiji | But without checking the errno, I wont be able to know that the whether the world is ending or not |
| 17:18.37 | hoiji | So in a rare case when parsing is screwed ..... |
| 17:19.54 | hoiji | it will map all the overflowed ids to 2^64 - 1 |
| 17:20.38 | hoiji | This I feel may lead to very hard to debug problems for someone who takes dependency on my code |
| 17:22.11 | brlcad | ahh, I'm beginning to see .. the return value is the parsed value |
| 17:22.15 | brlcad | not an error code |
| 17:22.55 | brlcad | still why not: errno=0; uint64_t val = strtoull(...); if (errno!=0) abort("the world is ending"); |
| 17:23.05 | brlcad | other than being not thread safe |
| 17:23.13 | brlcad | is that the issue with _strtoui64? |
| 17:23.21 | brlcad | doesn't set errno or something |
| 17:23.42 | hoiji | yes exactly! |
| 17:23.54 | brlcad | why didn't you say that! :) |
| 17:24.11 | brlcad | you said the VALUES RETURNED were different |
| 17:24.18 | hoiji | sorry |
| 17:24.22 | brlcad | I had that to go with |
| 17:24.56 | brlcad | so does _strtoui64 have an error mechanism? |
| 17:25.09 | hoiji | http://msdn.microsoft.com/en-us/library/85zk715d.aspx |
| 17:25.39 | hoiji | It just returns _UI64_MAX |
| 17:27.00 | hoiji | MSVC 2013 has strtoull http://msdn.microsoft.com/en-us/library/dn320173.aspx |
| 17:29.16 | hoiji | One way I think is go around this problem is to regard the _UI64_MAX as an indication of an overflow as strtoull also returns ULLONG_MAX along with setting the errno |
| 17:30.05 | hoiji | However in this case we would give a false alarm if the string value was exactly equal to 2^64 - 1 |
| 17:30.16 | brlcad | right, which was the point of #if !defined(HAVE_STRTOULL) && defined(HAVE__STRTOUI64) #define strtoull _strtoui64 #endif |
| 17:30.26 | brlcad | that way, you just call strtoull() |
| 17:30.54 | hoiji | but would the false be ok? |
| 17:31.01 | hoiji | ^false alarm |
| 17:31.13 | brlcad | errno=0; uint64_t val = (uint64_t)strtoull(...); if (errno!=0 || val == MAX_UINT64) abort(); |
| 17:31.29 | brlcad | that catches both cases portably |
| 17:32.55 | brlcad | i would not worry about the limit case being false as it's indistinguishable regardless |
| 17:32.56 | hoiji | But it would also catch the valid situation: if the value in the file is exactly MAX_UINT64 |
| 17:33.05 | hoiji | ok! |
| 17:33.16 | hoiji | thanks |
| 17:33.19 | brlcad | basically the call is only useful for values less than the max ull |
| 17:33.59 | brlcad | there are probably going to be other probablems LONG before you encounter that situation |
| 17:34.55 | hoiji | heh |
| 17:45.12 | hoiji | brlcad: you said that _strtoi64 is not thread safe. Could you point me to the source of the info? |
| 17:56.06 | brlcad | no setting and reading errno is not thread safe |
| 17:56.44 | brlcad | other threads will be reading/setting it .. can't truly know who error'd unles you semaphore-protect the entire parse |
| 17:58.08 | brlcad | that's another reason why it's basically just not worth caring about .. if the parse fails, val will probably be max or zero, so you could just make either be an error condition .. assuming zero is not a valid id |
| 17:58.20 | brlcad | if it is, then init to max and just check that |
| 17:58.39 | hoiji | oh!! |
| 17:58.58 | brlcad | uint64_t val = MAXUINT64; val = (uint64_t)strtoull(...); if (val == MAXUINT64_t) ... |
| 17:59.13 | hoiji | I understood about the maximum value thing |
| 17:59.14 | brlcad | safe and simple |
| 17:59.30 | hoiji | I was just asking about the thread safety |
| 17:59.56 | brlcad | won't catch an implementation that returns some value but sets errno, but meh |
| 18:01.13 | hoiji | thanks, I wont use use errno carelessly again.. (My gsoc project is "making step libraries thread safe") :P |
| 18:01.27 | brlcad | haha |
| 18:01.28 | brlcad | okay |
| 18:01.40 | brlcad | globals and thread safety don't go well together |
| 18:01.52 | brlcad | no matter whose global it is |
| 18:02.56 | hoiji | ya, i somehow overlooked the fact that errno is a global, even though I used it :( *it will not happen again* |
| 18:58.14 | hoiji | yet another commit https://github.com/hoiji09/stepcode/compare/stepcode:master...master |
| 20:01.56 | *** join/#stepcode cstirk (~Carola@pool-108-56-173-181.washdc.fios.verizon.net) |
| 20:35.38 | mpictor | brlcad: the docs I read on errno state that it can be changed by functions even if they succeed, and is only valid if the function returns a value that indicates an error occurred |
| 20:56.51 | brlcad | it's a global, anything can change it to anything ... :) |
| 20:57.05 | mpictor | true |
| 20:57.47 | brlcad | now a system proclaiming to being fully posix compliant "should" have certain behaviors, but that's almost irrelevant |
| 20:57.53 | mpictor | I'd never thought about it before... how in the world do you use those functions in a multithreaded environment ?! |
| 20:57.59 | mpictor | yea |
| 20:58.13 | brlcad | you include them in your semaphore block |
| 20:58.27 | mpictor | of course |
| 20:58.45 | brlcad | it's unusual to have to zero-set it, so normally you'd just acquire sem, call func, check errno, release sem |
| 20:59.02 | mpictor | yea |
| 21:00.02 | mpictor | would still be painful if one of those funcs didn't return quickly |
| 21:03.22 | brlcad | except their string processing functions .. generally inherently slow |
| 21:03.25 | brlcad | they're |
| 21:23.57 | mpictor | fast compared to disk IO, which is what I was thinking of |
| 22:56.44 | *** join/#stepcode kesha (~kesha@14.139.122.114) |
| 22:57.04 | *** join/#stepcode kesha (~kesha@14.139.122.114) |
| 23:39.19 | *** join/#stepcode kesha_ (~kesha@14.139.122.114) |