Numeric integrity check

Handling decimals

Here, the comment gives the impression that you allow one decimal in the input, but the code allows two:

//use hasdec to indicate a decimal in the string 
//but don't allow more than one.
if( arr[j] == numdig[b] && hasdec < 2) {

For inputs . .. ... the program gives:

. is a floating point number.
.. is a floating point number.
... is not a number.

I don't think any of these is a floating point number.

Simplify

A simpler way to write numdig:

char * numdig = "0123456789,.$";

And in the main function I don't understand why you copied argv to argvarray. You can drop the copying and use argv directly.

Clarity

The code doesn't make it clear where the numbers come from in b < 13 and b == 11. You could make them clear by putting in variables with descriptive names. For example numdig_len for 13.

For the number 11, there's no really good name. When it's difficult to find a good name, that usually indicates a problem. What is this 11 anyway? It's the position of . inside numdig. That's a bit obscure way to refer to a .. Why not just use '.'?

And this brings us to another point: why are unrelated things mixed in numdig? It would be better to separate:

• digits
• things to ignore, such as $ and ,
• decimal point

That brings us to other issues as well...

Logical issues

Why allow $ anywhere in the input? That isn't right. If we ignore as first and last character, that could make sense. Ignoring anyway, and ignoring multiple of it doesn't make much sense.

The program is a bit forgiving with respect to commas. For example it reports ,,, as integer. That isn't right.

Using constants

numdig could be a constant, defined at the top, outside of functions:

const char * numdig = "0123456789,.$";

More importantly, it would be good to move the return values 0, 1, 2 to constants with descriptive names.

As far as the C programming language goes, check_is_numeric is a quite good function name. I could spend some time talking about a few variable names through your code that could stand to be a little bit better (as people around here know, I'm a stickler for writing readable code).

But we can also use types as a way to improve the readability and self-documentation of our code base.

Your check_is_numeric function has a return type of int. Based on reading the function name, I'd assume a bool return type: true or false (and be disappointed that you're not using a bool). There's no comments to go along with the function, and I'm not sure where I'd find any technical documentation. So, it might be extraordinarily easy for me to miss the fact that your function even differentiates between integer and floating point numbers. I could very easily have written the following...

if (check_is_numeric(3.14159)) {

And I'd never notice that this is returning 2, which will still behave as expected here if we are working under the assumption that the function simply returns true or false.

Even if we do spend some time playing with the function and see that we sometimes get 1 and sometimes get 2 and sometimes get 0, it might be difficult to notice what these values mean (especially if there are some bugs). So, importantly, I could incorrectly make the assumption that your function returns 0 for non-numbers, and non-zero for numbers, and that number returned is insignificant.

Or we could make our code self-documenting with an enum which clearly self-describes what the return value means:

typedef enum { 
    NON_NUMBER, 
    INTEGER_NUMBER, 
    FLOATING_POINT_NUMBER
} number_type;

And now, our function returns this type:

number_type check_is_numeric(const char * string) {
    // ...
    return NON_NUMBER;
    // or...
    return INTEGER_NUMBER;
    // or...
    return FLOATING_POINT_NUMBER;
}

Consider reading about Finite-State Machines. You basically keep track of a state, which can be represented as a flow-chart, with various ways of changing state from one node to another. For example, to parse a number, you'd have a chart that looks something like this:

By following the arrows, you'll note that you can only have a -, . or a digit at the beginning. If you chose the -, the next character must be a digit. If you chose a digit, you can have any number of digits after that, followed by a . or \0 at the end of the string. Note that there are two states for digits, one of them before and one after the . state. This ensures that there can be at most one . in the number. If at any point you receive a character that is not valid (there is no arrow) from the current state, you can immediately conclude that the string is not a valid number.

This is a very simple example. For example, it's optional whether you want to allow a \0 immediately after a ., or allow the first character to be a .. You could also add another state if you don't want to allow leading 0s, or any other number rules you want to enforce.

This is, of course, a completely different approach to text parsing than the code you've provided, but you asked for suggestions for other mechanisms, so hopefully this can give you some insight into another way, which is commonly used by code parsers for exactly this sort of task.