Thread: Combine alike functions

To Narf, sorry, I don't get your point. If memset is not needed, why calloc does the same thing?

Sorry, I guess I'm not good at expressing myself. You need to put your instance in a predictable state, for example:

Code:

struct node {
  int contents;
  struct node *next;
};

struct node *p = malloc(sizeof *p);

/* Initialize to something predictable */
p->contents = 0;
p->next = NULL;

What you can't do safely is initialize the node with memset():

Code:

struct node {
  int contents;
  struct node *next;
};

struct node *p = malloc(sizeof *p);

/* Unsafe! */
memset(p, 0, sizeof *p);

Likewise, you can't use calloc() alone to create and initialize the node because the initialization that calloc() does is identical to memset():

Code:

struct node {
  int contents;
  struct node *next;
};

/* Unsafe! */
struct node *p = calloc(1, sizeof *p);

The reason is that memset() and anything that works like memset() copy the bit pattern 00000000--assuming eight bit bytes--to each byte of the destination memory. But, most types don't guarantee that this bit pattern is analogous to a zero value for that type. Which means that 0.0 for double isn't necessarily a bit pattern with all bits zero. That means that the variables aren't in a predictable state because you don't know what to test for without much awkwardness.

It's from so-called auto-indent function.

Any good editor will give you the option to replace tabs with spaces automatically. Which means that Notepad isn't a good editor.

Narf, since you just commented out _memset_ and didn't do anything about initialization, can I take that for it's not necesary to do so and can just leave it for further use.

I didn't comment it out, I just commented that it wasn't a good idea:

Code:

// memset() probably isn't a good idea
memset(tmp->ptr, 0, sizeof *tmp->ptr);

If I knew the declaration of DFNCOL then I could have given you a more appropriate initialization, because the only safe way to do it in this case is to initialize each member in turn. Like my first example with the node structure. But I'm sure you can figure that part out on your own.

The C standards for calloc()

And the actual standard says:

The space is initialized to all bits zero. 253)

Where the footnote 253 is exceptionally clear:

253) Note that this need not be the same as the representation of floating-point zero or a null pointer constant.

> I don't think redefining a variable time and again and again is a good idea.
It won't - this is C not C++.
I personally go with restricting variables to the smallest possible scope consistent with the intended usage. With the variable declared inside the loop, there's no temptation (or error) of trying to use that variable outside the loop, where it's likely to have some undefined value.
In addition, I find it useful when extracting blocks of code from within functions that have grown too big, to place them in a new function.

> Actually, MSVC initials new created pointer as NULL for me.
This is only true in debug builds. With release builds (and perhaps other compilers), different answers would result. Initialising things yourself is a good idea (especially initially setting pointers to NULL).

> As for the difference between debug and release build of MSVC....
Then you have bugs in your code which need to be fixed. Apart from being easier to debug (and being larger and slower), there should be no functional difference between the debug and release builds of your code. If there is, then you've got problems.

> I have to say that it is the same for pointer initialization
I think you'll find (if you study the generated code) that debug goes out of it's way to specifically initialise things even if you don't, whereas in release the value you find is down to pure dumb luck. Sure your stack may start all nice and clean, but after some function calls what you find in your uninitialised local variables is the junk just left their from earlier activity in the program.