Portability / compatibility issues

Discussion in 'C Programming' started by OzBob, Jan 15, 2006.

  1. OzBob

    OzBob Guest

    I am developing some basic string / file manipulation C progams at home
    (Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    encountered problems performing the most basic of manipulations and
    comparisons.

    I have posted my test code below, and the results I get on each compiler.
    The crux of the matter is that the 'strstr' function differs wildly in its
    behaviour on different platforms, and precious few man pages will actually
    provide a worked example of any function, let alone this one. I have had to
    write the "has_slash" function and use the reserved work SLASH already, to
    get around the problems that strstr() gives me.

    I know C is touted as an standardised development environment that provides
    portability (the immortal phrase "we converted to another platform by typing
    'make'" springs to mind); I'm not seeing that right now.

    Any advise / comments? Share and Enjoy, Ian

    #include <stdio.h>

    #define SLASH "/"

    int has_slash(char in_str[24])
    {
    int i=0;

    while (in_str != *SLASH && in_str != NULL && i < 100) i++;

    /* wrong format */
    if (in_str != *SLASH)
    {
    i=0;
    } else
    { i++;
    }
    printf("In function - i = %i\n", i);
    return(i);

    }

    void main()
    {
    int test_true;

    /* PROVEN ON BOTH PA_RISC AND SPARC */
    test_true=has_slash("copy /f file");
    if (test_true != 0) printf("Has slash = true\n");

    /* New test, strstr results */
    char *str_result;
    char test_date[24];

    strcpy(test_date, "02_04_2005");
    if (strstr(test_date, SLASH) != NULL) printf(" By self- found
    slash\n");
    if (strstr(test_date, SLASH) == NULL) printf(" By self- not found
    slash\
    n");

    str_result=strstr(test_date, "/");

    if (str_result != NULL) printf("Found slash :%s:!\n", str_result);
    if (str_result == NULL) printf("Not found slash :%s:!\n",
    str_result);
    }
    /* server1: PA_RISC with c99 compatible compiler */
    /* server1:/tmp> ./a.out
    In function - i = 6
    Has slash = true
    By self- not found slash
    Not found slash ::!
    server1:/tmp> */

    /* server 2: SPARC with gcc */
    /* # ./a.out
    In function - i = 6
    Has slash = true
    By self- not found slash
    Segmentation Fault - core dumped
    #
    /
     
    OzBob, Jan 15, 2006
    #1
    1. Advertising

  2. OzBob

    Michael Mair Guest

    OzBob wrote:
    > I am developing some basic string / file manipulation C progams at home
    > (Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    > running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    > encountered problems performing the most basic of manipulations and
    > comparisons.
    >
    > I have posted my test code below, and the results I get on each compiler.
    > The crux of the matter is that the 'strstr' function differs wildly in its
    > behaviour on different platforms, and precious few man pages will actually
    > provide a worked example of any function, let alone this one. I have had to
    > write the "has_slash" function and use the reserved work SLASH already, to
    > get around the problems that strstr() gives me.
    >
    > I know C is touted as an standardised development environment that provides
    > portability (the immortal phrase "we converted to another platform by typing
    > 'make'" springs to mind); I'm not seeing that right now.
    >
    > Any advise / comments? Share and Enjoy, Ian



    Yes: Compile with the highest warning level and in a standard C
    mode. E.g.

    $ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c
    strstr.c: In function `has_slash':
    strstr.c:9: warning: comparison between pointer and integer
    strstr.c: At top level:
    strstr.c:24: warning: return type of 'main' is not `int'
    strstr.c: In function `main':
    strstr.c:35: warning: implicit declaration of function `strcpy'
    strstr.c:36: warning: implicit declaration of function `strstr'
    strstr.c:36: error: missing terminating " character
    strstr.c:37: error: stray '\' in program
    strstr.c:37: error: `slash' undeclared (first use in this function)
    strstr.c:37: error: (Each undeclared identifier is reported only once
    strstr.c:37: error: for each function it appears in.)
    strstr.c:37: error: parse error before "n"
    strstr.c:36: warning: empty body in an if-statement
    strstr.c:37: error: missing terminating " character
    strstr.c:38: error: `n' undeclared (first use in this function)
    strstr.c:38: error: missing terminating " character
    strstr.c:39: error: missing terminating " character

    where the include directive is on line 1.

    Your program does not compile -- so how can you expect us to
    look at it?

    Cheers
    Michael
    >
    > #include <stdio.h>
    >
    > #define SLASH "/"
    >
    > int has_slash(char in_str[24])
    > {
    > int i=0;
    >
    > while (in_str != *SLASH && in_str != NULL && i < 100) i++;
    >
    > /* wrong format */
    > if (in_str != *SLASH)
    > {
    > i=0;
    > } else
    > { i++;
    > }
    > printf("In function - i = %i\n", i);
    > return(i);
    >
    > }
    >
    > void main()
    > {
    > int test_true;
    >
    > /* PROVEN ON BOTH PA_RISC AND SPARC */
    > test_true=has_slash("copy /f file");
    > if (test_true != 0) printf("Has slash = true\n");
    >
    > /* New test, strstr results */
    > char *str_result;
    > char test_date[24];
    >
    > strcpy(test_date, "02_04_2005");
    > if (strstr(test_date, SLASH) != NULL) printf(" By self- found
    > slash\n");
    > if (strstr(test_date, SLASH) == NULL) printf(" By self- not found
    > slash\
    > n");
    >
    > str_result=strstr(test_date, "/");
    >
    > if (str_result != NULL) printf("Found slash :%s:!\n", str_result);
    > if (str_result == NULL) printf("Not found slash :%s:!\n",
    > str_result);
    > }
    > /* server1: PA_RISC with c99 compatible compiler */
    > /* server1:/tmp> ./a.out
    > In function - i = 6
    > Has slash = true
    > By self- not found slash
    > Not found slash ::!
    > server1:/tmp> */
    >
    > /* server 2: SPARC with gcc */
    > /* # ./a.out
    > In function - i = 6
    > Has slash = true
    > By self- not found slash
    > Segmentation Fault - core dumped
    > #
    > /
    >
    >



    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Jan 15, 2006
    #2
    1. Advertising

  3. OzBob

    OzBob Guest

    "Michael Mair" <> wrote in message
    news:...
    > OzBob wrote:
    >> I am developing some basic string / file manipulation C progams at home
    >> (Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    >> running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    >> encountered problems performing the most basic of manipulations and
    >> comparisons.
    >>
    >> I have posted my test code below, and the results I get on each compiler.
    >> The crux of the matter is that the 'strstr' function differs wildly in
    >> its behaviour on different platforms, and precious few man pages will
    >> actually provide a worked example of any function, let alone this one. I
    >> have had to write the "has_slash" function and use the reserved work
    >> SLASH already, to get around the problems that strstr() gives me.
    >>
    >> I know C is touted as an standardised development environment that
    >> provides portability (the immortal phrase "we converted to another
    >> platform by typing 'make'" springs to mind); I'm not seeing that right
    >> now.
    >>
    >> Any advise / comments? Share and Enjoy, Ian

    >
    >
    > Yes: Compile with the highest warning level and in a standard C
    > mode. E.g.
    >
    > $ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c
    > strstr.c: In function `has_slash':
    > strstr.c:9: warning: comparison between pointer and integer
    > strstr.c: At top level:
    > strstr.c:24: warning: return type of 'main' is not `int'
    > strstr.c: In function `main':
    > strstr.c:35: warning: implicit declaration of function `strcpy'
    > strstr.c:36: warning: implicit declaration of function `strstr'
    > strstr.c:36: error: missing terminating " character
    > strstr.c:37: error: stray '\' in program
    > strstr.c:37: error: `slash' undeclared (first use in this function)
    > strstr.c:37: error: (Each undeclared identifier is reported only once
    > strstr.c:37: error: for each function it appears in.)
    > strstr.c:37: error: parse error before "n"
    > strstr.c:36: warning: empty body in an if-statement
    > strstr.c:37: error: missing terminating " character
    > strstr.c:38: error: `n' undeclared (first use in this function)
    > strstr.c:38: error: missing terminating " character
    > strstr.c:39: error: missing terminating " character
    >
    > where the include directive is on line 1.
    >
    > Your program does not compile -- so how can you expect us to
    > look at it?
    >
    > Cheers
    > Michael
    >>
    >> #include <stdio.h>
    >>
    >> #define SLASH "/"
    >>
    >> int has_slash(char in_str[24])
    >> {
    >> int i=0;
    >>
    >> while (in_str != *SLASH && in_str != NULL && i < 100) i++;
    >>
    >> /* wrong format */
    >> if (in_str != *SLASH)
    >> {
    >> i=0;
    >> } else
    >> { i++;
    >> }
    >> printf("In function - i = %i\n", i);
    >> return(i);
    >>
    >> }
    >>
    >> void main()
    >> {
    >> int test_true;
    >>
    >> /* PROVEN ON BOTH PA_RISC AND SPARC */
    >> test_true=has_slash("copy /f file");
    >> if (test_true != 0) printf("Has slash = true\n");
    >>
    >> /* New test, strstr results */
    >> char *str_result;
    >> char test_date[24];
    >>
    >> strcpy(test_date, "02_04_2005");
    >> if (strstr(test_date, SLASH) != NULL) printf(" By self- found
    >> slash\n");
    >> if (strstr(test_date, SLASH) == NULL) printf(" By self- not found
    >> slash\
    >> n");
    >>
    >> str_result=strstr(test_date, "/");
    >>
    >> if (str_result != NULL) printf("Found slash :%s:!\n",
    >> str_result);
    >> if (str_result == NULL) printf("Not found slash :%s:!\n",
    >> str_result);
    >> }
    >> /* server1: PA_RISC with c99 compatible compiler */
    >> /* server1:/tmp> ./a.out
    >> In function - i = 6
    >> Has slash = true
    >> By self- not found slash
    >> Not found slash ::!
    >> server1:/tmp> */
    >>
    >> /* server 2: SPARC with gcc */
    >> /* # ./a.out
    >> In function - i = 6
    >> Has slash = true
    >> By self- not found slash
    >> Segmentation Fault - core dumped
    >> #
    >> /

    >
    >
    > --
    > E-Mail: Mine is an /at/ gmx /dot/ de address.


    Micheal,

    Have submitted the commands for gcc, with the following response. Have also
    checked the code and string.h is not included. I have since modified the
    comments at the end, included the <string.h> library at the start, and
    succesfully compiled using the commands provided. I even went a step further
    and removed the "-c" option from the command string to generate "a.out",
    which (in the interests of consistency) fails at the same point with the
    same error.

    I figure its the strstr command and the assignment of a pointer, which
    again, works fine on the HP-UX 'cc' compiler (the full one, not the inbuilt
    kernel-only one) with the '-AC99' c99 compatibility option, yet bails on the
    gcc compiler.

    Any further ideas? Share and Enjoy, OzBob

    /* original compiler output */
    # gcc -std=c99 -pedantic -W -Wall -O test.c -c
    test.c:24: warning: return type of `main' is not `int'
    test.c: In function `main':
    test.c:35: warning: implicit declaration of function `strcpy'
    test.c:36: warning: implicit declaration of function `strstr'
    test.c:53:1: unterminated comment

    /* included <string.h>, terminated comment */
    # gcc -std=c99 -pedantic -W -Wall -O test.c
    test.c:25: warning: return type of `main' is not `int'
    ls # -l a.out
    -rwxr-xr-x 1 root other 7280 Jan 15 15:04 a.out
    # ./a.out
    In function - i = 6
    Has slash = true
    By self- not found slash
    Segmentation Fault - core dumped
    #

    /* Context information */
    # gcc --version
    gcc (GCC) 3.3.2
    Copyright (C) 2003 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    # uname -a
    SunOS sunhome1 5.9 Generic_112233-07 sun4m sparc SUNW,SPARCstation-4
    #
     
    OzBob, Jan 15, 2006
    #3
  4. OzBob

    Ico Guest

    Michael Mair <> wrote:
    > OzBob wrote:
    >> I am developing some basic string / file manipulation C progams at home
    >> (Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    >> running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    >> encountered problems performing the most basic of manipulations and
    >> comparisons.
    >>
    >> I have posted my test code below, and the results I get on each compiler.
    >> The crux of the matter is that the 'strstr' function differs wildly in its
    >> behaviour on different platforms, and precious few man pages will actually
    >> provide a worked example of any function, let alone this one. I have had to
    >> write the "has_slash" function and use the reserved work SLASH already, to
    >> get around the problems that strstr() gives me.
    >>
    >> I know C is touted as an standardised development environment that provides
    >> portability (the immortal phrase "we converted to another platform by typing
    >> 'make'" springs to mind); I'm not seeing that right now.
    >>
    >> Any advise / comments? Share and Enjoy, Ian

    >
    >
    > Yes: Compile with the highest warning level and in a standard C
    > mode. E.g.
    >
    > $ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c


    <snipped a lot of warnings and errors>

    > Your program does not compile -- so how can you expect us to
    > look at it?


    It *does* compile, if you only fix the line wraps, probably caused by
    the OT's newsreader software. These things do happen.

    --
    :wq
    ^X^Cy^K^X^C^C^C^C
     
    Ico, Jan 15, 2006
    #4
  5. OzBob

    pemo Guest

    "OzBob" <> wrote in message
    news:dqdnj6$g1k$-infra.bt.com...
    >
    > "Michael Mair" <> wrote in message
    > news:...
    >> OzBob wrote:
    >>> I am developing some basic string / file manipulation C progams at home
    >>> (Sparcstation running Solaris 9 and gcc) for my work environment
    >>> (PA-RISC running HP-UX 11.11 and c99 compatible compiler). However I
    >>> seem to have encountered problems performing the most basic of
    >>> manipulations and comparisons.
    >>>
    >>> I have posted my test code below, and the results I get on each
    >>> compiler. The crux of the matter is that the 'strstr' function differs
    >>> wildly in its behaviour on different platforms, and precious few man
    >>> pages will actually provide a worked example of any function, let alone
    >>> this one. I have had to write the "has_slash" function and use the
    >>> reserved work SLASH already, to get around the problems that strstr()
    >>> gives me.
    >>>
    >>> I know C is touted as an standardised development environment that
    >>> provides portability (the immortal phrase "we converted to another
    >>> platform by typing 'make'" springs to mind); I'm not seeing that right
    >>> now.
    >>>
    >>> Any advise / comments? Share and Enjoy, Ian

    >>
    >>
    >> Yes: Compile with the highest warning level and in a standard C
    >> mode. E.g.
    >>
    >> $ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c
    >> strstr.c: In function `has_slash':
    >> strstr.c:9: warning: comparison between pointer and integer
    >> strstr.c: At top level:
    >> strstr.c:24: warning: return type of 'main' is not `int'
    >> strstr.c: In function `main':
    >> strstr.c:35: warning: implicit declaration of function `strcpy'
    >> strstr.c:36: warning: implicit declaration of function `strstr'
    >> strstr.c:36: error: missing terminating " character
    >> strstr.c:37: error: stray '\' in program
    >> strstr.c:37: error: `slash' undeclared (first use in this function)
    >> strstr.c:37: error: (Each undeclared identifier is reported only once
    >> strstr.c:37: error: for each function it appears in.)
    >> strstr.c:37: error: parse error before "n"
    >> strstr.c:36: warning: empty body in an if-statement
    >> strstr.c:37: error: missing terminating " character
    >> strstr.c:38: error: `n' undeclared (first use in this function)
    >> strstr.c:38: error: missing terminating " character
    >> strstr.c:39: error: missing terminating " character
    >>
    >> where the include directive is on line 1.
    >>
    >> Your program does not compile -- so how can you expect us to
    >> look at it?
    >>
    >> Cheers
    >> Michael
    >>>
    >>> #include <stdio.h>
    >>>
    >>> #define SLASH "/"
    >>>
    >>> int has_slash(char in_str[24])
    >>> {
    >>> int i=0;
    >>>
    >>> while (in_str != *SLASH && in_str != NULL && i < 100) i++;
    >>>
    >>> /* wrong format */
    >>> if (in_str != *SLASH)
    >>> {
    >>> i=0;
    >>> } else
    >>> { i++;
    >>> }
    >>> printf("In function - i = %i\n", i);
    >>> return(i);
    >>>
    >>> }
    >>>
    >>> void main()
    >>> {
    >>> int test_true;
    >>>
    >>> /* PROVEN ON BOTH PA_RISC AND SPARC */
    >>> test_true=has_slash("copy /f file");
    >>> if (test_true != 0) printf("Has slash = true\n");
    >>>
    >>> /* New test, strstr results */
    >>> char *str_result;
    >>> char test_date[24];
    >>>
    >>> strcpy(test_date, "02_04_2005");
    >>> if (strstr(test_date, SLASH) != NULL) printf(" By self- found
    >>> slash\n");
    >>> if (strstr(test_date, SLASH) == NULL) printf(" By self- not
    >>> found slash\
    >>> n");
    >>>
    >>> str_result=strstr(test_date, "/");
    >>>
    >>> if (str_result != NULL) printf("Found slash :%s:!\n",
    >>> str_result);
    >>> if (str_result == NULL) printf("Not found slash :%s:!\n",
    >>> str_result);
    >>> }
    >>> /* server1: PA_RISC with c99 compatible compiler */
    >>> /* server1:/tmp> ./a.out
    >>> In function - i = 6
    >>> Has slash = true
    >>> By self- not found slash
    >>> Not found slash ::!
    >>> server1:/tmp> */
    >>>
    >>> /* server 2: SPARC with gcc */
    >>> /* # ./a.out
    >>> In function - i = 6
    >>> Has slash = true
    >>> By self- not found slash
    >>> Segmentation Fault - core dumped
    >>> #
    >>> /

    >>
    >>
    >> --
    >> E-Mail: Mine is an /at/ gmx /dot/ de address.

    >
    > Micheal,
    >
    > Have submitted the commands for gcc, with the following response. Have
    > also checked the code and string.h is not included. I have since modified
    > the comments at the end, included the <string.h> library at the start, and
    > succesfully compiled using the commands provided. I even went a step
    > further and removed the "-c" option from the command string to generate
    > "a.out", which (in the interests of consistency) fails at the same point
    > with the same error.
    >
    > I figure its the strstr command and the assignment of a pointer, which
    > again, works fine on the HP-UX 'cc' compiler (the full one, not the
    > inbuilt kernel-only one) with the '-AC99' c99 compatibility option, yet
    > bails on the gcc compiler.
    >
    > Any further ideas? Share and Enjoy, OzBob
    >
    > /* original compiler output */
    > # gcc -std=c99 -pedantic -W -Wall -O test.c -c
    > test.c:24: warning: return type of `main' is not `int'
    > test.c: In function `main':
    > test.c:35: warning: implicit declaration of function `strcpy'
    > test.c:36: warning: implicit declaration of function `strstr'
    > test.c:53:1: unterminated comment
    >
    > /* included <string.h>, terminated comment */
    > # gcc -std=c99 -pedantic -W -Wall -O test.c
    > test.c:25: warning: return type of `main' is not `int'
    > ls # -l a.out
    > -rwxr-xr-x 1 root other 7280 Jan 15 15:04 a.out
    > # ./a.out
    > In function - i = 6
    > Has slash = true
    > By self- not found slash
    > Segmentation Fault - core dumped
    > #
    >
    > /* Context information */
    > # gcc --version
    > gcc (GCC) 3.3.2
    > Copyright (C) 2003 Free Software Foundation, Inc.
    > This is free software; see the source for copying conditions. There is NO
    > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
    > PURPOSE.
    >
    > # uname -a
    > SunOS sunhome1 5.9 Generic_112233-07 sun4m sparc SUNW,SPARCstation-4
    > #



    >> while (in_str != *SLASH && in_str != NULL && i < 100) i++;


    >> while (in_str != *SLASH && in_str != '\0' && i < 100) i++;


    OR

    >> while (in_str != *SLASH && in_str && i < 100) i++;


    OR, if it's always a nul terminated string

    >> while (in_str != *SLASH && in_str i++;


    OR

    Perhaps a rewrite of some sort? ...

    int has_slash(char in_str[24])
    {
    for(int i = 0; in_str != '\0'; ++i)
    {
    if(in_str == *SLASH)
    {
    return i;
    }
    }

    return 0;
    }
     
    pemo, Jan 15, 2006
    #5
  6. OzBob

    Ico Guest

    OzBob <> wrote:
    >
    > "Michael Mair" <> wrote in message
    > news:...
    >> OzBob wrote:
    >>> I am developing some basic string / file manipulation C progams at home
    >>> (Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    >>> running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    >>> encountered problems performing the most basic of manipulations and
    >>> comparisons.
    >>>
    >>> I have posted my test code below, and the results I get on each compiler.
    >>> The crux of the matter is that the 'strstr' function differs wildly in
    >>> its behaviour on different platforms, and precious few man pages will
    >>> actually provide a worked example of any function, let alone this one.


    That's very strange. strstr() is very well standarized, and should not
    give you any troubles.

    >>> I have had to write the "has_slash" function and use the reserved
    >>> work SLASH already, to get around the problems that strstr() gives
    >>> me.


    Maybe your 'problem' is that you don't expect strstr() to return NULL
    when the string you are searching for is not found ?

    >>> I know C is touted as an standardised development environment that
    >>> provides portability (the immortal phrase "we converted to another
    >>> platform by typing 'make'" springs to mind); I'm not seeing that right
    >>> now.


    That's very well possible, considering your code is written with
    portability in mind.

    >>> Any advise / comments? Share and Enjoy, Ian


    Some comments :

    - include string.h (you already did)
    - main() is supposed to return an int. The proper definition is
    int main(void) or int main(int argc, char *argv[])

    >>> str_result=strstr(test_date, "/");
    >>>
    >>> if (str_result != NULL) printf("Found slash :%s:!\n", str_result);
    >>> if (str_result == NULL) printf("Not found slash :%s:!\n", str_result);

    [...]
    >>> By self- not found slash
    >>> Segmentation Fault - core dumped


    That's no so strange : strstr() returns NULL when "/" is not found in
    "02_04_2005". Thus, str_result is NULL, but you pass it to printf(),
    which does not like NULL arguments.

    The obvious solution would be to check the return value of strstr() for
    NULL.

    Regards,

    Ico

    --
    :wq
    ^X^Cy^K^X^C^C^C^C
     
    Ico, Jan 15, 2006
    #6
  7. OzBob

    OzBob Guest

    "Ico" <> wrote in message
    news:43ca68d0$0$4279$4all.nl...
    > OzBob <> wrote:
    >>
    >> "Michael Mair" <> wrote in message
    >> news:...
    >>> OzBob wrote:
    >>>> I am developing some basic string / file manipulation C progams at home
    >>>> (Sparcstation running Solaris 9 and gcc) for my work environment
    >>>> (PA-RISC
    >>>> running HP-UX 11.11 and c99 compatible compiler). However I seem to
    >>>> have
    >>>> encountered problems performing the most basic of manipulations and
    >>>> comparisons.
    >>>>
    >>>> I have posted my test code below, and the results I get on each
    >>>> compiler.
    >>>> The crux of the matter is that the 'strstr' function differs wildly in
    >>>> its behaviour on different platforms, and precious few man pages will
    >>>> actually provide a worked example of any function, let alone this one.

    >
    > That's very strange. strstr() is very well standarized, and should not
    > give you any troubles.
    >
    >>>> I have had to write the "has_slash" function and use the reserved
    >>>> work SLASH already, to get around the problems that strstr() gives
    >>>> me.

    >
    > Maybe your 'problem' is that you don't expect strstr() to return NULL
    > when the string you are searching for is not found ?
    >
    >>>> I know C is touted as an standardised development environment that
    >>>> provides portability (the immortal phrase "we converted to another
    >>>> platform by typing 'make'" springs to mind); I'm not seeing that right
    >>>> now.

    >
    > That's very well possible, considering your code is written with
    > portability in mind.
    >
    >>>> Any advise / comments? Share and Enjoy, Ian

    >
    > Some comments :
    >
    > - include string.h (you already did)
    > - main() is supposed to return an int. The proper definition is
    > int main(void) or int main(int argc, char *argv[])
    >
    >>>> str_result=strstr(test_date, "/");
    >>>>
    >>>> if (str_result != NULL) printf("Found slash :%s:!\n", str_result);
    >>>> if (str_result == NULL) printf("Not found slash :%s:!\n", str_result);

    > [...]
    >>>> By self- not found slash
    >>>> Segmentation Fault - core dumped

    >
    > That's no so strange : strstr() returns NULL when "/" is not found in
    > "02_04_2005". Thus, str_result is NULL, but you pass it to printf(),
    > which does not like NULL arguments.
    >
    > The obvious solution would be to check the return value of strstr() for
    > NULL.
    >
    > Regards,
    >
    > Ico
    >
    > --
    > :wq
    > ^X^Cy^K^X^C^C^C^C


    Ico,

    Appreciate the feedback. I think I need to simplify my code to demonstrate
    what the precise problem is. I will remove the NULL values from the printf()
    command and see what I get. Will reply from work tomorrow

    Thanks all for the input so far, Share and Enjoy! OzBob
     
    OzBob, Jan 15, 2006
    #7
  8. OzBob

    Chuck F. Guest

    OzBob wrote:
    > "Michael Mair" <> wrote:
    >

    .... snip ...
    >>
    >> Your program does not compile -- so how can you expect us to
    >> look at it?
    >>

    .... snip ...
    >
    > Have submitted the commands for gcc, with the following
    > response. Have also checked the code and string.h is not
    > included. I have since modified the comments at the end,
    > included the <string.h> library at the start, and succesfully
    > compiled using the commands provided. I even went a step further
    > and removed the "-c" option from the command string to generate
    > "a.out", which (in the interests of consistency) fails at the
    > same point with the same error.
    >
    > I figure its the strstr command and the assignment of a pointer,
    > which again, works fine on the HP-UX 'cc' compiler (the full
    > one, not the inbuilt kernel-only one) with the '-AC99' c99
    > compatibility option, yet bails on the gcc compiler. Any further
    > ideas? Share and Enjoy, OzBob
    >
    > /* original compiler output */
    > # gcc -std=c99 -pedantic -W -Wall -O test.c -c
    > test.c:24: warning: return type of `main' is not `int'
    > test.c: In function `main':
    > test.c:35: warning: implicit declaration of function `strcpy'
    > test.c:36: warning: implicit declaration of function `strstr'
    > test.c:53:1: unterminated comment


    Obviously you haven't fixed the code. The above is not what we
    consider 'compiling'. The warnings and the error are serious.

    Keep code line length under 72 chars for Usenet posting. 65 is
    even better. This will avoid awkward wraps.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
     
    Chuck F., Jan 15, 2006
    #8
  9. OzBob a écrit :
    > Any advise / comments? Share and Enjoy, Ian


    #include <stdio.h>

    /* -ed- was missing (strcpy()) */
    #include <string.h>

    #define SLASH "/"

    /* -ed- not exported function. static added.
    Accepts string literals : const added (see further)
    static int has_slash(char const in_str[24])

    a complicated way of writing
    */
    static int has_slash (char const *in_str)
    {
    int i = 0;

    /* -ed-
    while (in_str != *SLASH && in_str != NULL && i < 100)

    you don't want 'NULL' but 0

    {} added for readability and maintenance.

    What the hell is this 100 ?
    */
    while (in_str != *SLASH && in_str != 0)
    {
    i++;
    }
    /* wrong format */
    if (in_str != *SLASH)
    {
    i = 0;
    }
    else
    {
    i++;
    }
    printf("In function - i = %i\n", i);

    /* -ed-
    return (i);

    useless parens
    */
    return i;

    }

    /* -ed-
    void main()

    main() returns int. Always.
    */
    int main (void)
    {
    int test_true;

    /* PROVEN ON BOTH PA_RISC AND SPARC */

    /* -ed- warning : a string litteral is not mutable.
    char const * expected. */
    test_true = has_slash("copy /f file");

    if (test_true != 0)
    {
    printf("Has slash = true\n");
    }

    /* -ed- C90 wants data definitions to be at the top of a block. */
    {
    /* New test, strstr results */
    char *str_result;
    char test_date[24];

    strcpy(test_date, "02_04_2005");
    if (strstr(test_date, SLASH) != NULL)
    /* -ed-

    printf(" By self- found
    slash\n");
    uncomplete string. */
    {
    printf(" By self- found slash\n");
    }

    /* -ed- sounds that we have a job for if-else too... */
    if (strstr(test_date, SLASH) == NULL)
    /* -ed-
    printf(" By self- not found
    slash\
    n");

    what the heck are you doing there ?
    */
    {
    printf(" By self- not found slash\n");
    }

    str_result = strstr(test_date, "/");

    if (str_result != NULL)
    {
    printf("Found slash :%s:!\n", str_result);
    }

    /* -ed- sounds that we have a job for if-else too... */
    if (str_result == NULL)
    {
    /* -ed- do not ettempt to printout a NULL pointer.
    The behaviour is undefined. */
    printf("Not found slash :%s:!\n",
    str_result);
    }
    }
    /* -ed- because main() returnes int... */
    return 0;
    }


    --
    A+

    Emmanuel Delahaye
     
    Emmanuel Delahaye, Jan 15, 2006
    #9
  10. OzBob

    Chris Torek Guest

    In article <dqdgi7$ctk$-infra.bt.com>
    OzBob <> wrote:
    >I am developing some basic string / file manipulation C progams at home
    >(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    >running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    >encountered problems performing the most basic of manipulations and
    >comparisons.


    Actually, your immediate problem is with the line:

    printf("some text including the %s directive\n", (char *)NULL);

    which is not a valid operation: the effect of providing NULL to
    the "%s" directive is undefined. On the HP-UX machine, the actual
    effect turns out to be a no-op, and on the SPARC, it turns out to
    be "Segmentation Fault - core dumped".

    Besdies the comments others have posted, the has_slash() function
    is coded quite oddly:

    >int has_slash(char in_str[24])
    >{


    It is worth noting that the actual type of "in_str" within has_slash
    is "char *", not "char [24]". The size provided in the brackets is
    ignored and the declaration runs into the following sentence (from
    the C99 draft, section 6.7.1):

    A declaration of a parameter as ``array of type'' shall be
    adjusted to ``pointer to type,'' and a declaration of a
    parameter as ``function returning type'' shall be adjusted to
    ``pointer to function returning type,'' as in 6.2.2.1.

    Thus, you could equally write:

    int has_slash(char *in_str) {

    here, omitting the constant 24. But since you did include it:

    > int i=0;
    >
    > while (in_str != *SLASH && in_str != NULL && i < 100) i++;


    .... it seems quite odd that you would limit "i" to below-100 instead
    of below-24.

    In any case, if NULL is defined as ((void *)0) (which is allowed,
    but apparently not the case on either of the two ocmpilers you have
    used so far), the comparison:

    in_str != NULL

    will "draw a diagnostic" (produce a warning or error message). The
    correct test is:

    in_str != '\0'

    or similar: '\0' is an int with value zero, so you can write any
    int with value zero here, including 0, 0x0, (34 + 43 - 77), etc.
    I prefer to use '\0' to emphasize the "character-ness" of the test:
    we are looking to stop when we reach the NUL character (the one-L
    NUL; not the two-L NULL pointer[%]).

    [
    The one-l lama
    He's a priest
    The two-l llama
    He's a beast
    And I will bet
    A silk pajama
    There isn't any
    Three-l lllama.*

    *The author's attention has been called to a type of
    conflagration known as a three-alarmer. Pooh.

    Ogden Nash <http://www.who2.com/ogdennash.html>.]
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jan 15, 2006
    #10
  11. OzBob

    Michael Mair Guest

    Ico wrote:
    > Michael Mair <> wrote:
    >
    >>OzBob wrote:
    >>

    <snip>
    >>>
    >>>Any advise / comments? Share and Enjoy, Ian

    >>
    >>
    >>Yes: Compile with the highest warning level and in a standard C
    >>mode. E.g.
    >>
    >>$ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c

    >
    > <snipped a lot of warnings and errors>
    >
    >>Your program does not compile -- so how can you expect us to
    >>look at it?

    >
    > It *does* compile, if you only fix the line wraps, probably caused by
    > the OT's newsreader software. These things do happen.


    You are right; I could have looked into it more deeply.
    I just saw the missing of #include <string.h> and a "void main"
    and just fed the whole thing to the compiler (as the OP claimed
    to have used a "C99 compatible compiler") and pasted its output.
    However, this was to illustrate the point that code which does
    not meet minimum requirements may be ignored by the regulars...

    The attempts at improvement speak for the OP, so the regulars
    are motivated to put more effort into the reply (which was the
    intention -- either save us all time or prove that it's worth
    it).


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Jan 15, 2006
    #11
  12. OzBob

    Michael Mair Guest

    OzBob wrote:
    > "Michael Mair" <> wrote in message
    > news:...
    >
    >>OzBob wrote:
    >>
    >>>I am developing some basic string / file manipulation C progams at home
    >>>(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    >>>running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    >>>encountered problems performing the most basic of manipulations and
    >>>comparisons.
    >>>
    >>>I have posted my test code below, and the results I get on each compiler.
    >>>The crux of the matter is that the 'strstr' function differs wildly in
    >>>its behaviour on different platforms, and precious few man pages will
    >>>actually provide a worked example of any function, let alone this one. I
    >>>have had to write the "has_slash" function and use the reserved work
    >>>SLASH already, to get around the problems that strstr() gives me.
    >>>
    >>>I know C is touted as an standardised development environment that
    >>>provides portability (the immortal phrase "we converted to another
    >>>platform by typing 'make'" springs to mind); I'm not seeing that right
    >>>now.
    >>>
    >>>Any advise / comments? Share and Enjoy, Ian

    >>
    >>
    >>Yes: Compile with the highest warning level and in a standard C
    >>mode. E.g.
    >>
    >>$ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c
    >>strstr.c: In function `has_slash':
    >>strstr.c:9: warning: comparison between pointer and integer
    >>strstr.c: At top level:
    >>strstr.c:24: warning: return type of 'main' is not `int'
    >>strstr.c: In function `main':
    >>strstr.c:35: warning: implicit declaration of function `strcpy'
    >>strstr.c:36: warning: implicit declaration of function `strstr'
    >>strstr.c:36: error: missing terminating " character
    >>strstr.c:37: error: stray '\' in program
    >>strstr.c:37: error: `slash' undeclared (first use in this function)
    >>strstr.c:37: error: (Each undeclared identifier is reported only once
    >>strstr.c:37: error: for each function it appears in.)
    >>strstr.c:37: error: parse error before "n"
    >>strstr.c:36: warning: empty body in an if-statement
    >>strstr.c:37: error: missing terminating " character
    >>strstr.c:38: error: `n' undeclared (first use in this function)
    >>strstr.c:38: error: missing terminating " character
    >>strstr.c:39: error: missing terminating " character
    >>
    >>where the include directive is on line 1.
    >>
    >>Your program does not compile -- so how can you expect us to
    >>look at it?
    >>

    <snip>
    > Micheal,


    I'm not that Irish ;-)

    > Have submitted the commands for gcc, with the following response. Have also
    > checked the code and string.h is not included. I have since modified the
    > comments at the end, included the <string.h> library at the start, and
    > succesfully compiled using the commands provided. I even went a step further
    > and removed the "-c" option from the command string to generate "a.out",
    > which (in the interests of consistency) fails at the same point with the
    > same error.
    >
    > I figure its the strstr command and the assignment of a pointer, which
    > again, works fine on the HP-UX 'cc' compiler (the full one, not the inbuilt
    > kernel-only one) with the '-AC99' c99 compatibility option, yet bails on the
    > gcc compiler.
    >
    > Any further ideas? Share and Enjoy, OzBob
    >
    > /* original compiler output */
    > # gcc -std=c99 -pedantic -W -Wall -O test.c -c
    > test.c:24: warning: return type of `main' is not `int'
    > test.c: In function `main':
    > test.c:35: warning: implicit declaration of function `strcpy'
    > test.c:36: warning: implicit declaration of function `strstr'
    > test.c:53:1: unterminated comment
    >
    > /* included <string.h>, terminated comment */
    > # gcc -std=c99 -pedantic -W -Wall -O test.c
    > test.c:25: warning: return type of `main' is not `int'


    Note: This is not to be taken lightly -- in principle, all
    bets are off for a "void main" main().

    > ls # -l a.out
    > -rwxr-xr-x 1 root other 7280 Jan 15 15:04 a.out
    > # ./a.out
    > In function - i = 6
    > Has slash = true
    > By self- not found slash
    > Segmentation Fault - core dumped
    > #

    <snip>

    Look at this one; it is yours with slight changes and works
    as I expect:

    #include <stdio.h>
    #include <string.h>

    #define SLASH "/"

    int has_slash (const char *in_str);

    int main (void)
    {
    int test_true;

    test_true = has_slash("copy /f file");
    if (test_true != 0)
    printf("Has slash = true\n");

    /* New test, strstr results */
    char *str_result;
    char test_date[24];

    strcpy(test_date, "02_04_2005");
    if (strstr(test_date, SLASH) != NULL)
    printf(" By self- found slash\n");
    else
    printf(" By self- not found slash\n");

    str_result=strstr(test_date, "/");

    if (str_result != NULL)
    printf("Found slash: %s[%s]\n",
    str_result, test_date);
    if (str_result == NULL)
    printf("Not found slash: \'\\0\'[%s]\n",
    test_date);

    return 0;
    }

    int has_slash (const char *in_str)
    {
    int i=0;

    while (in_str != *SLASH && in_str != '\0'
    /* && i < 100 */)
    i++;

    /* wrong format */
    i = (in_str != *SLASH) ? 0 : i+1;

    printf("In function - i = %i\n", i);

    return(i);
    }

    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Jan 15, 2006
    #12
  13. "OzBob" <> writes:
    > I am developing some basic string / file manipulation C progams at home
    > (Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    > running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    > encountered problems performing the most basic of manipulations and
    > comparisons.
    >
    > I have posted my test code below, and the results I get on each compiler.
    > The crux of the matter is that the 'strstr' function differs wildly in its
    > behaviour on different platforms, and precious few man pages will actually
    > provide a worked example of any function, let alone this one. I have had to
    > write the "has_slash" function and use the reserved work SLASH already, to
    > get around the problems that strstr() gives me.
    >
    > I know C is touted as an standardised development environment that provides
    > portability (the immortal phrase "we converted to another platform by typing
    > 'make'" springs to mind); I'm not seeing that right now.
    >
    > Any advise / comments? Share and Enjoy, Ian
    >
    > #include <stdio.h>
    >
    > #define SLASH "/"
    >
    > int has_slash(char in_str[24])
    > {
    > int i=0;
    >
    > while (in_str != *SLASH && in_str != NULL && i < 100) i++;

    [snip]

    What is the point of the SLASH macro? (It's a macro, not a reserved
    word.) Delete the macro, change each occurrence of *SLASH to '/', and
    change all other occurrences of SLASH to "/".

    That won't fix your problem, but it will clean up some clutter and
    make it easier to see the real problems.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 15, 2006
    #13
  14. Michael Mair <> writes:
    > OzBob wrote:

    [...]
    >> # gcc -std=c99 -pedantic -W -Wall -O test.c
    >> test.c:25: warning: return type of `main' is not `int'

    >
    > Note: This is not to be taken lightly -- in principle, all
    > bets are off for a "void main" main().


    In principle, yes. But in fact, I've never seen a C compiler that
    misbehaves really badly given a "void main" declaration. The worst
    I've seen is that the main program returns some arbitrary status to
    the calling environment, equivalent to
    int main(void) { .... return garbage; }

    Having said that, "void main()" does invoke undefined behavior (unless
    the implementation specifically documents it), and you should correct
    it to "int main(void)" *before* you try to figure out what else is
    going wrong. Most likely it won't make any real difference, and
    you'll have one less thing to worry about.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 15, 2006
    #14
  15. OzBob

    Eric Sosman Guest

    OzBob wrote:
    > [...]
    > int has_slash(char in_str[24])


    Nobody seems to have mentioned it, but if in_str is
    a string (that is, a char array with a '\0' terminator,
    rather than an array of arbitrary form), you should
    consider using the strchr() function instead of this
    rather convoluted and confused mess. C.f. the Seventh
    Commandment at

    http://www.lysator.liu.se/c/ten-commandments.html

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 15, 2006
    #15
  16. Keith Thompson said:

    > Michael Mair <> writes:
    >> OzBob wrote:

    > [...]
    >>> # gcc -std=c99 -pedantic -W -Wall -O test.c
    >>> test.c:25: warning: return type of `main' is not `int'

    >>
    >> Note: This is not to be taken lightly -- in principle, all
    >> bets are off for a "void main" main().

    >
    > In principle, yes. But in fact, I've never seen a C compiler that
    > misbehaves really badly given a "void main" declaration.


    If you're prepared to generalise this to "given a declaration of main that
    returns something other than int", I can vouch for the fact that I once
    managed to crash Windows NT in a most colourful way by experimenting with
    double main(void)!

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
     
    Richard Heathfield, Jan 16, 2006
    #16
  17. OzBob

    Jordan Abel Guest

    On 2006-01-15, Chris Torek <> wrote:
    > In article <dqdgi7$ctk$-infra.bt.com>
    > OzBob <> wrote:
    >>I am developing some basic string / file manipulation C progams at home
    >>(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    >>running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    >>encountered problems performing the most basic of manipulations and
    >>comparisons.

    >
    > Actually, your immediate problem is with the line:
    >
    > printf("some text including the %s directive\n", (char *)NULL);
    >
    > which is not a valid operation: the effect of providing NULL to
    > the "%s" directive is undefined. On the HP-UX machine, the actual
    > effect turns out to be a no-op, and on the SPARC, it turns out to
    > be "Segmentation Fault - core dumped".


    more data points: On glibc, freebsd, and 7th edition UNIX, it's
    "(null)" - i'm surprised this wasn't codified into the standard, given
    its age.

    (note: 6th edition doesn't do this, either in the kernel or in iolib.
    However, 6th edition unix didn't have the same I/O library - iolib
    printf in 6th edition was called as, near as i can tell, any of the
    following)

    printf(-1, buf, format, args...);
    printf(fd, format, args...); /* fd in 0..9 */
    printf(format, args...); /* to stdout */
     
    Jordan Abel, Jan 16, 2006
    #17
  18. OzBob

    Chris Torek Guest

    >On 2006-01-15, Chris Torek <> wrote:
    >> Actually, your immediate problem is with the line:
    >>
    >> printf("some text including the %s directive\n", (char *)NULL);
    >>
    >> which is not a valid operation: the effect of providing NULL to
    >> the "%s" directive is undefined. On the HP-UX machine, the actual
    >> effect turns out to be a no-op, and on the SPARC, it turns out to
    >> be "Segmentation Fault - core dumped".


    In article <>
    Jordan Abel <> wrote:
    >more data points: On glibc, freebsd, and 7th edition UNIX, it's
    >"(null)" - i'm surprised this wasn't codified into the standard, given
    >its age.


    The FreeBSD behavior is *my* doing: I wrote the stdio that was
    released with "4.3-networking" (which is the root of all the free
    BSDs). But I copied it from earlier Sun systems (rather than V7,
    which I never used myself). Sun apparently lost this when they
    converted to System V.

    A number of "odd corners" of the Standard are basically kowtowing
    to System V, which had very weird, arguably-broken semantics for
    a number of edge cases.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jan 16, 2006
    #18
  19. OzBob

    Jack Klein Guest

    On 16 Jan 2006 01:02:31 GMT, Jordan Abel <> wrote
    in comp.lang.c:

    > On 2006-01-15, Chris Torek <> wrote:
    > > In article <dqdgi7$ctk$-infra.bt.com>
    > > OzBob <> wrote:
    > >>I am developing some basic string / file manipulation C progams at home
    > >>(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
    > >>running HP-UX 11.11 and c99 compatible compiler). However I seem to have
    > >>encountered problems performing the most basic of manipulations and
    > >>comparisons.

    > >
    > > Actually, your immediate problem is with the line:
    > >
    > > printf("some text including the %s directive\n", (char *)NULL);
    > >
    > > which is not a valid operation: the effect of providing NULL to
    > > the "%s" directive is undefined. On the HP-UX machine, the actual
    > > effect turns out to be a no-op, and on the SPARC, it turns out to
    > > be "Segmentation Fault - core dumped".

    >
    > more data points: On glibc, freebsd, and 7th edition UNIX, it's
    > "(null)" - i'm surprised this wasn't codified into the standard, given
    > its age.


    I'd be very surprised if it had been. What arguments can you provide
    that this would be a Good Thing(tm)?

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jan 16, 2006
    #19
  20. OzBob

    pemo Guest

    "Richard Heathfield" <> wrote in message
    news:dqeo0l$i11$-infra.bt.com...
    > Keith Thompson said:
    >
    >> Michael Mair <> writes:
    >>> OzBob wrote:

    >> [...]
    >>>> # gcc -std=c99 -pedantic -W -Wall -O test.c
    >>>> test.c:25: warning: return type of `main' is not `int'
    >>>
    >>> Note: This is not to be taken lightly -- in principle, all
    >>> bets are off for a "void main" main().

    >>
    >> In principle, yes. But in fact, I've never seen a C compiler that
    >> misbehaves really badly given a "void main" declaration.

    >
    > If you're prepared to generalise this to "given a declaration of main that
    > returns something other than int", I can vouch for the fact that I once
    > managed to crash Windows NT in a most colourful way by experimenting with
    > double main(void)!


    Ah - the '!' invokes undefined behaviour.
     
    pemo, Jan 16, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MJL

    portability issues

    MJL, Aug 1, 2004, in forum: C++
    Replies:
    11
    Views:
    830
  2. Replies:
    17
    Views:
    820
    Kevin Handy
    Apr 26, 2006
  3. Jonathan Lamothe

    fread/fwrite Portability Issues

    Jonathan Lamothe, Jul 22, 2006, in forum: C Programming
    Replies:
    20
    Views:
    1,190
    Dave Thompson
    Jul 31, 2006
  4. Lionel B
    Replies:
    10
    Views:
    952
    Lionel B
    Jan 2, 2007
  5. Noob

    Portability issues (union, bitfields)

    Noob, Nov 4, 2009, in forum: C Programming
    Replies:
    7
    Views:
    1,052
    John Temples
    Nov 6, 2009
Loading...

Share This Page