7 ms·

Some of this seems like horrendously bad advice: - Using fixed width integers in for loops seems like a fabulous way to reduce the portability of code - the s

by _wmd 11y ago

Some of this seems like horrendously bad advice: - Using fixed width integers in for loops seems like a fabulous way to reduce the portability of code - the statements in "C allows static initialization of stack-allocated arrays" are _not_ equivalent, one is a bitwise zeroing while the other is arithmetic initialization. On some machines changing these statements blindly will cause a different bit pattern to end up in memory (because there are no requirements on the machine's representations for e.g. integers or NULL or ..). There are sound reasons why the bitwise approach could be preferred, for example, because a project has debug wrappers for memset that clearly demarcate uninitialized data - the statements in "C99 allows variable length array initializsers" aren't even slightly equivalent. His suggestion uses automatic storage (and subsequently a stack overflow triggered by user input -- aka. a security bug) - "There is no performance penalty for getting zero'd memory" this is bullshit. calloc() might optimize for the case where it is allocating from a page the OS has just supplied but I doubt any implementation ever bothered to do this, since it relies on the host OS to always zero new pages - "If a function accepts arbitrary input data and a length to process, don't restrict the type of the parameter." the former version is in every way more self-documenting and consistent with the apparent function of the procedure than his use of void. It also runs counter to a rule from slightly more conservative times: avoid void at all costs, since it automatically silences all casting warnings. Modern C provides a bunch of new things that make typing safer but none of those techniques are mentioned here. For example word-sized structs combined with struct literals can eliminate whole classes of historical bugs. On the fixed width integers thing, the size of 'int', 'long' and 'long long' are designed to vary according to the machine in use. On some fancy Intel box perhaps there is no cost to using a 64bit type all the time, but on a microcontroller you've just caused the compiler to inject a software arithmetic implementation into your binary (and your code is running 100x slower too). He doesn't even mention types like intfast_t designed for this case, despite explicitly indicating "don't write C if you have to", which in 2016 pretty commonly means you're targeting such a device

Nursie 11y ago
>> - Using fixed width integers in for loops seems like a fabulous way to reduce the portability of code Can you explain this? I'm not seeing it. You should generally know the range of numbers you're seeking to store in an integer variable, if you don't then you're asking for trouble.
- _wmd 11y ago
  Assuming running time is considered a feature of your project, oversized int types on smaller hardware will adversely effect that You can still range check the natural integer types, just use INT_MAX and suchlike
  - Nursie 11y ago
    >> Assuming running time is considered a feature of your project, oversized int types on smaller hardware will adversely effect that Either you need the range, in which case you're stuck with a large type, or you don't and can use a smaller one. I'm not sure where 'oversized' comes into it.
- zAy0LfpBZLC8mAC 11y ago
  You "know the range", but not necessarily in terms of concrete numbers. Often, you iterate over variable size data structures, for example. All you know is that it won't be larger than the C implementation it's being compiled with allows--which usually roughly means that it won't be larger than the amount of memory the processor it's running on can address. But how much that actually is? Well, depends on the processor, and there also is no upper limit, as you always can invent a processor that can address more memory than any processor before. That's why you should usually use appropriate abstract types (such as size_t in this case) that the compiler will make sure are large enough to be able to iterate over any data structure you will encounter on that target.
  - Nursie 11y ago
    Oh sure, for array index stuff like that. For general iteration against another number, say, I would use a fixed (or fast) size appropriate to my data.
- IshKebab 11y ago
  Yeah in fact using non-fixed width integers reduces portability! I ran into a bug where I was running some Arduino code (16-bit) on an mBed (32-bit). The use of `int` rather than `uint16_t` caused a timeout to become an infinite loop. I'm pretty sure it would be impossible to have portability issues due to using fixed-width types - I mean their entire point is to ensure portability.
xcgvgh 11y ago
In the second to last paragraph; did you hint that wrapping a char*, used as a string, into a struct, to get type safety?
- _wmd 11y ago
  Yep, you don't even need struct literals for it. Quite a few int types are wrapped this way in the Linux kernel
  - deleted 11y ago
    [deleted]
mpu 11y ago
You're wrong about the arrays, the standard guarantees that zeroing the bytes of an object of integer type will give a 0 value to the integer. Pointers are a different matter though.
_yosefk 11y ago
Advice presented along the lines of "there are no reasons to do anything but that which I recommend" is usually somewhat flawed... just because there are so many reasons to do different things in different situations. Regarding calloc (which indeed might be slower than malloc contrary to TFA) - a variable that should have been initialized to something but instead keeps zero bits written by calloc is not necessarily a great situation. If you use malloc, at least Valgrind will show you where you use the uninitialized variable. With calloc it won't, though it might still be a bug - a consistently behaving bug, but a bug nonetheless. Someone preferring consistently behaving bugs to inconsistently behaving bugs in production code might use a function my_malloc (not my_calloc...) which in a release build calls calloc, but in debug builds it calls malloc (and perhaps detects whether it runs under Valgrind and if not, initializes the buffer not with zeros, but with deterministic pseudo-random garbage.)
- amadvance 11y ago
  I follow a similar approach. Valgrind is a must. Just using malloc()+memset(,0,) in release, to override someway the Linux OOM killer. In starvation, malloc+memset "usually" results in a malloc() failure, instead of the process being silently killed by the OOM killer.
- MichaelMoser123 11y ago
  another thing is that both calloc and malloc return non null pointer for zero arguments (that can be very bad). my_alloc should check for zero size arguments and return NULL in this case. (The problem is that if your size computation overflowed then you will get a very small non null memory block - which you will be very likely to overwrite) Calloc has another benefit: if you calculate size by n * sizeof(kuku) then it will detect integer overflow (this can be very important for security sensitive stuff that deals with untrusted input), if you did the computation before that and passed calloc( size, 1) then this multiplication and check is another few cycles wasted. I wonder if they could have done a standard library allocation function like calloc that does the multiplication with overflow detection, does not zero out memory and that returns NULL on zero arguments - but that would be too much to ask.
stevejones 11y ago
The initialisers bit seems downright dangerously wrong. This code: uint32_t array[10] = {0}; Does not initialise every element to 0 in the way it would seem to. To see the difference contrast the difference you get when you a) remove the initialiser and b) replace the initialiser with {1}.
- jzwinck 11y ago
  You may find it distasteful but that has been idiomatic C for more than a decade.
  - stevejones 11y ago
    I've not seen anyone use that construct anywhere.
- to3m 11y ago
  When you replace the initialiser with 1, it should only initialse the first element to 1. Objects initialized in this way have unmentioned elements set to 0 or NULL (recursing into aggregates, initialising the first named union member). (See C11 standard, 6.7.9.21. 6.7.9.10 gives the rules for selecting the default value. Aside from the extra syntax, I don't think the rules differ substantially from C89...) C++ lets you do "uint32_t array[10]={}", which is something C should allow as well, really. But it doesn't.
- Arnavion 11y ago
  >Does not initialise every element to 0 in the way it would seem to. Yes it does, since atleast C99. As for the others: a) Removing the initializer will leave the values undefined. b) Using an initializer of { 1 } will initialize the first element to 1 and the rest to 0.
  - stevejones 11y ago
    "the way it would seem to" {} initialises all elements to 0. {0} initialises the first element to 0 and the rest to 0. The latter form just introduces confusion.
pslam 11y ago
Is this parody? You've written a list of coding practices which assure job security for folks like me, who have to undo these gross portability problems, bugs, and security vulnerabilities these result in. for (int i = 0; i < 100000; ++i) // most optimal int size used Is bullshit, always.

by _wmd 11y ago

Nursie 11y ago

>> - Using fixed width integers in for loops seems like a fabulous way to reduce the portability of code Can you explain this? I'm not seeing it. You should generally know the range of numbers you're seeking to store in an integer variable, if you don't then you're asking for trouble.

_wmd 11y ago
Assuming running time is considered a feature of your project, oversized int types on smaller hardware will adversely effect that You can still range check the natural integer types, just use INT_MAX and suchlike
- Nursie 11y ago
  >> Assuming running time is considered a feature of your project, oversized int types on smaller hardware will adversely effect that Either you need the range, in which case you're stuck with a large type, or you don't and can use a smaller one. I'm not sure where 'oversized' comes into it.
zAy0LfpBZLC8mAC 11y ago
You "know the range", but not necessarily in terms of concrete numbers. Often, you iterate over variable size data structures, for example. All you know is that it won't be larger than the C implementation it's being compiled with allows--which usually roughly means that it won't be larger than the amount of memory the processor it's running on can address. But how much that actually is? Well, depends on the processor, and there also is no upper limit, as you always can invent a processor that can address more memory than any processor before. That's why you should usually use appropriate abstract types (such as size_t in this case) that the compiler will make sure are large enough to be able to iterate over any data structure you will encounter on that target.
- Nursie 11y ago
  Oh sure, for array index stuff like that. For general iteration against another number, say, I would use a fixed (or fast) size appropriate to my data.
IshKebab 11y ago
Yeah in fact using non-fixed width integers reduces portability! I ran into a bug where I was running some Arduino code (16-bit) on an mBed (32-bit). The use of `int` rather than `uint16_t` caused a timeout to become an infinite loop. I'm pretty sure it would be impossible to have portability issues due to using fixed-width types - I mean their entire point is to ensure portability.

xcgvgh 11y ago

In the second to last paragraph; did you hint that wrapping a char*, used as a string, into a struct, to get type safety?

_wmd 11y ago
Yep, you don't even need struct literals for it. Quite a few int types are wrapped this way in the Linux kernel
- deleted 11y ago
  [deleted]

mpu 11y ago

You're wrong about the arrays, the standard guarantees that zeroing the bytes of an object of integer type will give a 0 value to the integer. Pointers are a different matter though.

_yosefk 11y ago

Advice presented along the lines of "there are no reasons to do anything but that which I recommend" is usually somewhat flawed... just because there are so many reasons to do different things in different situations. Regarding calloc (which indeed might be slower than malloc contrary to TFA) - a variable that should have been initialized to something but instead keeps zero bits written by calloc is not necessarily a great situation. If you use malloc, at least Valgrind will show you where you use the uninitialized variable. With calloc it won't, though it might still be a bug - a consistently behaving bug, but a bug nonetheless. Someone preferring consistently behaving bugs to inconsistently behaving bugs in production code might use a function my_malloc (not my_calloc...) which in a release build calls calloc, but in debug builds it calls malloc (and perhaps detects whether it runs under Valgrind and if not, initializes the buffer not with zeros, but with deterministic pseudo-random garbage.)

amadvance 11y ago
I follow a similar approach. Valgrind is a must. Just using malloc()+memset(,0,) in release, to override someway the Linux OOM killer. In starvation, malloc+memset "usually" results in a malloc() failure, instead of the process being silently killed by the OOM killer.
MichaelMoser123 11y ago
another thing is that both calloc and malloc return non null pointer for zero arguments (that can be very bad). my_alloc should check for zero size arguments and return NULL in this case. (The problem is that if your size computation overflowed then you will get a very small non null memory block - which you will be very likely to overwrite) Calloc has another benefit: if you calculate size by n * sizeof(kuku) then it will detect integer overflow (this can be very important for security sensitive stuff that deals with untrusted input), if you did the computation before that and passed calloc( size, 1) then this multiplication and check is another few cycles wasted. I wonder if they could have done a standard library allocation function like calloc that does the multiplication with overflow detection, does not zero out memory and that returns NULL on zero arguments - but that would be too much to ask.

stevejones 11y ago

The initialisers bit seems downright dangerously wrong. This code: uint32_t array[10] = {0}; Does not initialise every element to 0 in the way it would seem to. To see the difference contrast the difference you get when you a) remove the initialiser and b) replace the initialiser with {1}.

jzwinck 11y ago
You may find it distasteful but that has been idiomatic C for more than a decade.
- stevejones 11y ago
  I've not seen anyone use that construct anywhere.
to3m 11y ago
When you replace the initialiser with 1, it should only initialse the first element to 1. Objects initialized in this way have unmentioned elements set to 0 or NULL (recursing into aggregates, initialising the first named union member). (See C11 standard, 6.7.9.21. 6.7.9.10 gives the rules for selecting the default value. Aside from the extra syntax, I don't think the rules differ substantially from C89...) C++ lets you do "uint32_t array[10]={}", which is something C should allow as well, really. But it doesn't.
Arnavion 11y ago
>Does not initialise every element to 0 in the way it would seem to. Yes it does, since atleast C99. As for the others: a) Removing the initializer will leave the values undefined. b) Using an initializer of { 1 } will initialize the first element to 1 and the rest to 0.
- stevejones 11y ago
  "the way it would seem to" {} initialises all elements to 0. {0} initialises the first element to 0 and the rest to 0. The latter form just introduces confusion.

pslam 11y ago

Is this parody? You've written a list of coding practices which assure job security for folks like me, who have to undo these gross portability problems, bugs, and security vulnerabilities these result in. for (int i = 0; i < 100000; ++i) // most optimal int size used Is bullshit, always.