• Gaetan (unregistered)

    Yikes (and Frist?) ! I had almost forgotten about that one, and Remy’s article just appears when I have to dig into that part again … Well I can remember it made me pretty worked up at the time. At least I know what I am getting into now.

  • (nodebb)

    Which, if s.sorties is uninitialized and numero is zero, that check will work

    Either it's meaningless because s.sorties is an actual array, and therefore not a NULL pointer (and therefore it is always true), or because s.sorties is an actual pointer, in which case the condition is false if numero is zero and the pointer is NULL (NULL+0 == NULL which casts to bool as false ), and true in all other cases, including cases which are UB (NULL+non_zero).

    However, if s.sorties is uninitialised, we're immediately into first-stripe UB territory for reading from an uninitialised variable.

  • jfs (unregistered)

    Hey, a condition check for x<1 when x is a double can not quite be inverted to x>=1, because what if x is NaN?

  • (nodebb) in reply to Steve_The_Cynic

    The worst thing about that is it will often be initialised to zero anyway. If you get new memory from the O/S, it will be zero initialised because otherwise it could be full of stuff that was from some other program. So presuming not too much stuff had been malloced and then freed, the pointer will accidentally be null and will work fine right up to the point that someone starts doing interesting things before that object is created.

  • Loren Pechtel (unregistered)

    Something to note here. That's a sentinel value but even if you don't check it it's going to cause a blowup. And ensuring the consumer dies on bad data is often good enough--if they have no graceful way out of it you either report the problem and quit, or you blow up and quit.

    But assign and check--that's a big part of my problem with C, warrants the holy water and mirrors.

  • (nodebb)

    I just want to add, that in most languages the modulo operator is actually not operating a modulo operation as expected but it's actually a remainder operator. Not that this justifies the code, but eh - might come handy when you need a way to annoy some math teacher or something ;-) .

  • John (unregistered)

    I dislike these double atomic functions. Instead 1) does index exist, 2) what is value

  • (nodebb) in reply to MaxiTB

    What's the difference between a modulo operator and a remainder operator? Honest question. I have a degree in math but I thought those were synonyms.

  • Smithers (unregistered) in reply to jkshapiro

    TL;DR - handling of negatives.

    A remainder operator gives the remainder under integer division: 12 divided by 10 is 1 with remainder 2, so 12 % 10 == 2. A modulo operator matches the mathematical idea of modulo equivalence. 12 and 42 are equivalent modulo 10, so 12 % 10 == 42 % 10.

    But the way C and C++ handle division with a negative number is to always round towards zero; -28 divided by 10 is -2 with remainder -8, so -28 % 10 == -8. But this no longer meets the requirements of a modulo operator; 12 and -28 are equivalent mod 10, but 12 % 10 != -28 % 10.

    By contrast, Python integer division always rounds down (towards -inf); -28 // 10 == -3 and -28 % 10 == 2, so with this convention for division, % is both a modulo operator and a remainder operator.

  • Tinkle (unregistered) in reply to jkshapiro

    Modulo will always return a value between 0 (inclusive) and n(exclusive). Remainder will return negative values for negative numbers down to -n(exclusive).

    For example this table shows mod/remainder 4 Number 6 5 4 3 2 1 0 -1 -2 -3 -4 -5 -6 -7 -8 -9 Modulo 2 1 0 3 2 1 0 3 2 1 0 3 2 1 0 3 Rem 2 1 0 3 2 1 0 -1 -2 -3 0 -1 -2 -3 0 -1

    You can get from remainder to modulo by adding n(4 in this case) to a negative remainder.

    Modulo does the division, rounds down (so -1 becomes -4) and gives the difference (3). Remainder does the division, rounds towards 0 (so -1 becomes 0) and gives the difference (-1).

  • (nodebb) in reply to thosrtanner

    The worst thing about that is it will often be initialised to zero anyway. If you get new memory from the O/S, it will be zero initialised because otherwise it could be full of stuff that was from some other program. So presuming not too much stuff had been malloced and then freed, the pointer will accidentally be null and will work fine right up to the point that someone starts doing interesting things before that object is created.

    Yes, but no, but mostly no. It won't, in C/C++'s definition of such things, really be initialised. It might, by chance, contain the pattern which your platform says is a null pointer (but which is allowed by the C/C++ standards to not be the all-zeroes bit pattern, see e.g. AS/400 or iSystem), but that doesn't make the variable initialised. It just makes you lucky... Or perhaps unlucky, because it will explode for a different reason later.

    And don't forget that C and C++ programs rarely ask the OS itself for more memory themselves. Mostly, they use malloc or operator new/operator new[], and if they need to, they ask the OS for memory. But if they didn't, then as you suggest, the previous history of that memory in your program's memory map influences what happens next, but it will rarely be good.

Leave a comment on “C+=0.25”

Log In or post as a guest

Replying to comment #691367:

Log Out

« Return to Article