Portability Niggles

[gemera]

I've a couple of niggling issues on code portability.

1)Am I right in saying that even though my unsigned ints have a limit of 4294967295 - if i need that kind of range I should really declare them as unsigned longs anyway and use the functions e.g. atol() appropriate to that type?

2)I wrote about 4 or 5 small programs in a row using string functions on the gcc compiler before realising i had forgotten to include the <string.h> header, and then discovered that most of the common functions are internal to the compiler anyway and don't need headers. Which initially seemed really convenient.

But if portability is an issue it would mean declaring them anyway? Which would not only completely null and void the convenience it would also increase the possibility of sometimes creating non-portable code anyway since there is nothing but my occasionally doddery self to check not only that a header has
been included,but more importantly, that it is the CORRECT header?

[laserlight]

1)Am I right in saying that even though my unsigned ints have a limit of 4294967295 - if i need that kind of range I should really declare them as unsigned longs anyway and use the functions e.g. atol() appropriate to that type?

Yes. Note that there are also typedefs in <stdint.h> that can help here, if you are compiling with respect to C99 or later.

2)I wrote about 4 or 5 small programs in a row using string functions on the gcc compiler before realising i had forgotten to include the <string.h> header, and then discovered that most of the common functions are internal to the compiler anyway and don't need headers. Which initially seemed really convenient.

But if portability is an issue it would mean declaring them anyway?

Yes.

Which would not only completely null and void the convenience it would also increase the possibility of sometimes creating non-portable code anyway since there is nothing but my occasionally doddery self to check not only that a header has
been included,but more importantly, that it is the CORRECT header?

Unfortunately, that is true. However, you would be testing using different compilers (and standard library implementations) too, right?

[Malcolm McLean]

I've a couple of niggling issues on code portability.

1)Am I right in saying that even though my unsigned ints have a limit of 4294967295 - if i need that kind of range I should really declare them as unsigned longs anyway and use the functions e.g. atol() appropriate to that type?

Yes and no. You are guaranteed only 16 bits in an int. But you have to ask if, realistically, the code will ever need to run on a machine with 16 bit ints. Then if the integer is used to index an array, or to count things stored in memory, it's unlikely it can go above 32,768 without running the machine out of memory, because most machines with 16 bit ints have 16 bit address spaces. To be really strict, you should use a size_t to index things in memory, long to store numers which aren't indices or counts and may go over 32,768.

2)I wrote about 4 or 5 small programs in a row using string functions on the gcc compiler before realising i had forgotten to include the <string.h> header, and then discovered that most of the common functions are internal to the compiler anyway and don't need headers. Which initially seemed really convenient.

Standard headers like string.h are a hangover from the past that we've got to live with. Just because everything works correctly when you omit them on your system doesn't mean it will be that way for all systems.

[cas]

2)I wrote about 4 or 5 small programs in a row using string functions on the gcc compiler before realising i had forgotten to include the <string.h> header, and then discovered that most of the common functions are internal to the compiler anyway and don't need headers. Which initially seemed really convenient.

Including string.h doesn't provide the functions, it allows the compiler to see what they look like, so it can tell you if you've called them incorrectly. The fact that gcc does provide some builtin functions is irrelevant, because libc is going to be linked in anyway. Try it with any (non-math) function. The fact that it compiles and links does not mean that it will work.

Gcc, given the proper flags, will complain about a missing prototype. You should always use at least the -Wall flag. Don't ignore warnings, either. Some people have the thought that warnings are harmless, but many of gcc's warnings tell you about real problems in your code.

[dmh2000]

2)I wrote about 4 or 5 small programs in a row using string functions on the gcc compiler before realising i had forgotten to include the <string.h> header, and then discovered that most of the common functions are internal to the compiler anyway and don't need headers. Which initially seemed really convenient.

you just got lucky that your code worked. without the include file and the function prototypes it defines, the compiler will happily accept whatever you pass as arguments. if you happened to pass in the wrong types the compiler will go ahead and let you and it will link. it just won't work right. so its not a portability issue, its a program correctness issue.

int main(int argc,char *argv[])
{
        int a = 0xc0000000;
        double b = 12345.0;

        strcpy(a,b);

        return 0;
}

at default warning level this compiles on VC10 without warnings and might even seem to work but will actually be doing horrible things. if you enable all warnings the compiler will complain bitterly.

[gemera]

The following code was compiled on the the codeblocks gcc compiler with

-wall
-wall(extra)
-pedantic

all on.

The code compiles and the exe runs fine.

#include <stdio.h>
#include <stdlib.h>

int main()
{
    char *p = "123456789";
    char *q = "abc";
    char str[20];
    int x,len,len2;

    strcpy(str,p);
    strcat(str,q);
    len = strlen(p);
    len2 = strlen(str);
    x = strcmp(str,p);
    printf("string length %d %d %d",len,len2,x);

    getchar();
    return 0;
}

The build log ( containing no errors or warnings) is.

Checking for existence: C:\Documents and Settings\windows\My Documents\C Programs\test\bin\Debug\test.exe
Executing: "C:\Program Files\CodeBlocks/cb_console_runner.exe" "C:\Documents and Settings\windows\My Documents\C Programs\test\bin\Debug\test.exe" (in C:\Documents and Settings\windows\My Documents\C Programs\test\.)
Process terminated with status 0 (0 minutes, 5 seconds)

[stahta01]

I can NOT duplicate it.

I call unlikely on your claim.

Tim S.

mingw32-gcc.exe -Wall  -g     -c C:\Users\tsta8844\cb\test\main.c -o obj\Debug\main.o
C:\Users\tsta8844\cb\test\main.c: In function 'main':
C:\Users\tsta8844\cb\test\main.c:11: warning: implicit declaration of function 'strcpy'
C:\Users\tsta8844\cb\test\main.c:11: warning: incompatible implicit declaration of built-in function 'strcpy'
C:\Users\tsta8844\cb\test\main.c:12: warning: implicit declaration of function 'strcat'
C:\Users\tsta8844\cb\test\main.c:12: warning: incompatible implicit declaration of built-in function 'strcat'
C:\Users\tsta8844\cb\test\main.c:13: warning: implicit declaration of function 'strlen'
C:\Users\tsta8844\cb\test\main.c:13: warning: incompatible implicit declaration of built-in function 'strlen'
C:\Users\tsta8844\cb\test\main.c:15: warning: implicit declaration of function 'strcmp'
mingw32-g++.exe  -o bin\Debug\test.exe obj\Debug\main.o    
Output size is 26.64 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 7 warnings

[stahta01]

You do realize that running your code erases the warnings in Code::Blocks!

[dmh2000]

like i said, you got lucky

[laserlight]

you just got lucky that your code worked. without the include file and the function prototypes it defines, the compiler will happily accept whatever you pass as arguments. if you happened to pass in the wrong types the compiler will go ahead and let you and it will link. it just won't work right. so its not a portability issue, its a program correctness issue.

That would be one scenario if no header was included. However, if a header was included, then it is possible that the header includes other headers, including <string.h> (or some other implementation detail header that <string.h> also includes). In such a case, it is a portability issue (you got lucky in a different way ) because it happens to be "correct" for the given standard library implementation, but may be wrong in other cases.

[gemera]

You do realize that running your code erases the warnings in Code::Blocks!

Aaaaaargh, well I do now!