Thread: C Code Confidence Issue

So this question is going to be a little "different" but it's true and I am asking for advice.

I've noticed especially when I program in C and I'm trying to tackle a medium to larger sized problem/application (lots of funcs I have to write), I tend to have what I will call "code confidence" issues. I think it's because I do software security at work, I've become paranoid when I am coding myself and it slows me way down. I've come to this realization because I often find myself questioning how to do things "Maybe that's not the best way... Maybe there's a gaping security or performance hole here... Is this loosely coupled enough???" etc....

It gets to the point where I sometimes search for someone else's implementation on Google but when I do, I often find that the other person either did exactly what I did, something else that I knew but was afraid to try, or something even uglier actually.

For example, I was writing a demo module of a program recently and I needed to convert a struct to a string to hash the data. Well, I was like "uh oh, haven't had to do something like that in a while..." etc etc... And just overall was overthinking it.

I then found another guy's example and he simply wrote something like these few lines and was done with it:

Code:

char* to_string(BLOCK * block)
{
    char *string_data = malloc(sizeof(BLOCK)); // Using a char* instead of a struct BLOCK * makes the data into a "string"
    if(!string_data)
        return NULL;

    memcpy(string_data, block, sizeof(block));
    return string_data;
}

While of course I haven't tested it enough to see if there are any nasty bugs, the point is this guy took 30 seconds to get a basic toString going whereas I was sitting there overthinking it and that code is something I definitely could have thrown together easily. It's not so much I don't know how as it is I don't trust my choice.

Has anyone else experienced this and do you have tips on dealing with it? I feel like I could bang out code a lot faster if I didn't do this. By the way, I'm not necessarily talking about production code here, but this program I'm working on is sort of a "rough draft" anyway.

It probably comes from the fact that I'm in the software security field and also that I've not been a 100% full-time professional C coder but rather I have to constantly changes languages at work and I'm generally doing smaller things with each one rather than a large-scale C program, etc...

Originally Posted by Asymptotic

Code:

char* to_string(BLOCK * block)
{
    char *string_data = malloc(sizeof(BLOCK)); // Using a char* instead of a struct BLOCK * makes the data into a "string"
    if(!string_data)
        return NULL;

    memcpy(string_data, block, sizeof(block));
    return string_data;
}

An C-String has a terminating zero byte; which the above code does *not* make happen.

Tim S.

Originally Posted by Asymptotic

I then found another guy's example and he simply wrote something like these few lines and was done with it:

Yet, without knowing what BLOCK looks like, this guy's example is immediately suspect:

• Does BLOCK contain pointer members? If so, this solution is too simple, i.e., it merely converts the pointers into sequences of characters, rather than considering what they point to.
• Does BLOCK contain anything other than arrays of char that are supposed to be strings? If not, then this solution is again too simple, i.e., if we take "to_string" to mean a null terminated preferably human-readable representation of a BLOCK object, then this solution does not work as it fails to represent the members of BLOCK as would be expected for such a "to_string" function. In fact, the resulting "string" might not even be null terminated!
• What about padding?

The way I see it, if you were considering all these before finding this example, that that's not overthinking. You're just being careful, and the author of this function might have considered these too and found them not important, or perhaps was not as careful as you when he should have been.

If you were not considering these, then perhaps that's just down to inexperience? It's alright to go slow and overthink at first, then later with experience you will have a better idea of how to proceed when faced with problems that have some relationship to ones you have faced in the past.

laserlight, yes those are similar considerations as to what will go through my head when I'm coding... I guess I'm still adapting to what is a reasonable pace expectation for myself and also to building larger applications. This is what happens when you spend most of your time coding small utility programs and scripts like I have.

About this string though, the main issue here may be that he named the function wrong. This data won't actually be used as a string but rather as input to a hashing function. I think "to_buffer" may have been more appropriate ie converting from a struct to a basic array so that it can be fed into the has func. I'm not sure if the hash func needs a null terminator as it may just terminate at the end of the BLOCK size if that makes sense.

But, it's strange he named it toString unless it's supposed to actually be a string. The fact that it is being used to hash data though means it probably does not need to be user-readable.

Originally Posted by Asymptotic

About this string though, the main issue here may be that he named the function wrong. This data won't actually be used as a string but rather as input to a hashing function. I think "to_buffer" may have been more appropriate ie converting from a struct to a basic array so that it can be fed into the has func. I'm not sure if the hash func needs a null terminator as it may just terminate at the end of the BLOCK size if that makes sense.

That's plausible, but then yes, it is very badly named. In fact, you don't need this function at all: you can just cast to char* (or unsigned char*) and then access the bytes of the BLOCK as needed.

Originally Posted by laserlight

That's plausible, but then yes, it is very badly named. In fact, you don't need this function at all: you can just cast to char* (or unsigned char*) and then access the bytes of the BLOCK as needed.

Ha, was almost thinking that since a pointer just holds the first address and structs are contiguous... That's awesome.

I guess the better question here would be, do you scratch code down like this and then think about it later or do you not even write the code out until you know exactly how you want to implement it? I tend to do #2 but I find that it slows me down and also sometimes if I do way #1, I at least can see what I'm trying to do and remember the idea.

If the BLOCK contains any padding bytes it might be a good idea to set them to an consistent value.
If the BLOCK contains an C-String that do not use the full allocated length; likely be a good idea to zero out those bytes.

Tim S.