Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tighten constraints on parameters #74

Open
alibabashack opened this issue Jun 4, 2015 · 2 comments
Open

tighten constraints on parameters #74

alibabashack opened this issue Jun 4, 2015 · 2 comments

Comments

@alibabashack
Copy link

In many functions there are parameters which are of type int, but whose value will always be unsigned (processor count, width, height, etc.). In order to reduce overhead by parameter validity checks (which btw. I have not seen anywhere), I suggest to change these to unsigned int.

For further optimization on bit level it might also be nice to use fixed size types from stdint.h everywhere e.g. uint32_t. This should improve portability of low level optimization.

@WesleyCeraso
Copy link
Contributor

I noticed that too. The memory types are not being used consistently as well, for instance, the p_malloc returns a p_mem_t, and p_memcpy receives a void * (I know they are the same, for now).
Function p_memcpy also returns a size_t that makes no sense.

@GBuella
Copy link
Contributor

GBuella commented Jun 5, 2015

Meanwhile, array size should always be passed around as size_t.

p_stuff_f32(float *a, int n) -> p_stuff_f32(const float *a, size_t n)

If one claims any portability, then on does not know if int, or unsigned int is enough to hold the size of any object on the platform, while size_t is invented for this purpose. It gives consistency with other libraries, including standard libraries

  • in C memcpy, memchr, memset, qsort, strncat, malloc, etc. have size_t arguments
  • in C strlen, fread, fwrite, strspn, etc. return size_t
  • even C++ STL implementations usually use size_t by default to refer to element counts.

If assume C99, we can get even stricter:
p_stuff_f32(size_t n, const float a[static n])

This declaration obviously nicely documents, that n is the expected size of the array a points to, and the compilers expects a to be non-null, even on the calling side ( clang example ):

p_stuff_f32(45, NULL);
warning: null passed to a callee which requires a non-null argument

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants