fmemopen: assignment makes pointer from integer without a cast

Discussion in 'C Programming' started by Markus Dehmann, Jun 25, 2004.

  1. The following if condition

    if((stream = fmemopen((void*)str, strlen(str), "r")) == NULL){
    // ...
    }
    gives me a warning: assignment makes pointer from integer without a
    cast

    But only when I compile it with gcc. With g++ it's fine. Why does the
    warning show up and how can I get rid of it (using gcc)?

    I tried it with gcc 3.2.2 and 3.3.1 and got the same warnings both
    times.

    Thanks!
    Markus


    PS: Here is a mini version of a program I am trying

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

    int main(){
    char ch;
    FILE *stream;
    char *str = "test";
    if((stream = fmemopen((void*)str, strlen(str), "r")) == NULL){
    fprintf(stderr, "Cannot open stream to string '%s'\n", str);
    }
    while ((ch = fgetc (stream)) != EOF)
    printf ("Got %c\n", ch);
    fclose (stream);
    return 0;
    }
     
    Markus Dehmann, Jun 25, 2004
    #1
    1. Advertising

  2. Markus Dehmann wrote:
    > The following if condition
    >
    > if((stream = fmemopen((void*)str, strlen(str), "r")) == NULL){
    > // ...
    > }
    > gives me a warning: assignment makes pointer from integer without a
    > cast


    Since no fmem* function exists as part of standard C or even C++, you
    need to ask in a newsgroup, mailing list, or tech support for your
    implementation...
    >
    > But only when I compile it with gcc. With g++ it's fine. Why does the
    > warning show up and how can I get rid of it (using gcc)?


    .... and there are current gcc implementations delivered without any
    fmem* functions as part of the supplied libraries.

    It appears that you have not included the appropriate prototypes for
    your function. If you have invoked gcc as a c89 or c99 compliant
    compiler then it is certain that the headers you included

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


    have no prototypes for any fmem* functions visible.
     
    Martin Ambuhl, Jun 25, 2004
    #2
    1. Advertising

  3. Markus Dehmann

    CBFalconer Guest

    Markus Dehmann wrote:
    >
    > The following if condition
    >
    > if((stream = fmemopen((void*)str, strlen(str), "r")) == NULL){
    > // ...
    > }
    > gives me a warning: assignment makes pointer from integer without
    > a cast

    .... snip ...
    >
    > #include <stdio.h>
    > #include <string.h>
    >
    > int main(){
    > char ch;
    > FILE *stream;
    > char *str = "test";
    > if((stream = fmemopen((void*)str, strlen(str), "r")) == NULL){
    > fprintf(stderr, "Cannot open stream to string '%s'\n", str);
    > }
    > while ((ch = fgetc (stream)) != EOF)
    > printf ("Got %c\n", ch);
    > fclose (stream);
    > return 0;
    > }


    There is no such standard function as fmemopen. Even if there
    were and you have simply neglected to #include the appropriate
    header, and the function took a void* first parameter, you should
    not be casting anything. So your code should really read:

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

    int main(void) {
    char ch;
    FILE *stream;
    char *str = "test";

    if (!(stream = fmemopen(str, strlen(str), "r"))) {
    fprintf(stderr, "Cannot open stream to string '%s'\n",
    str);
    }
    else {
    while ((ch = fgetc(stream)) != EOF)
    printf("Got %c\n", ch);
    fclose(stream);
    }
    return 0;
    }

    assuming fmemopen.h declares:

    FILE *fmemopen(void *, size_t, char *);

    In addition, names begining with "str" are reserved for the
    implementation. You should change those.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jun 25, 2004
    #3
  4. "CBFalconer" <> wrote in message news:...
    > Markus Dehmann wrote:

    [..]

    > assuming fmemopen.h declares:
    >
    > FILE *fmemopen(void *, size_t, char *);
    >
    > In addition, names begining with "str" are reserved for the
    > implementation. You should change those.
    >


    IIRC, the restriction is not for the local variables. Please
    correct me, if I understood it wrongly.

    Vijay

    > --
    > Chuck F () ()
    > Available for consulting/temporary embedded and systems.
    > <http://cbfalconer.home.att.net> USE worldnet address!
    >
    >
     
    Vijay Kumar R Zanvar, Jun 25, 2004
    #4
  5. Markus Dehmann

    Dan Pop Guest

    In <> CBFalconer <> writes:

    >Markus Dehmann wrote:
    >>
    >> The following if condition
    >>
    >> if((stream = fmemopen((void*)str, strlen(str), "r")) == NULL){
    >> // ...
    >> }
    >> gives me a warning: assignment makes pointer from integer without
    >> a cast

    >... snip ...
    >>
    >> #include <stdio.h>
    >> #include <string.h>
    >>
    >> int main(){
    >> char ch;
    >> FILE *stream;
    >> char *str = "test";
    >> if((stream = fmemopen((void*)str, strlen(str), "r")) == NULL){
    >> fprintf(stderr, "Cannot open stream to string '%s'\n", str);
    >> }
    >> while ((ch = fgetc (stream)) != EOF)
    >> printf ("Got %c\n", ch);
    >> fclose (stream);
    >> return 0;
    >> }


    ....
    >In addition, names begining with "str" are reserved for the
    >implementation. You should change those.


    A little knowledge is a dangerous thing. If you can't be bothered to
    learn the full rule (or it exceeds your learning capabilities) it is OK
    if you use the simplified version above for *your own* purposes. It is,
    however, sheer stupidity to try to impose it to others, who may be capable
    of learning the full rule and, therefore, have no use for your simplified
    version.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 25, 2004
    #5
  6. "Vijay Kumar R Zanvar" <> wrote in message
    news:...
    > "CBFalconer" <> wrote in message news:...
    > >
    > > In addition, names begining with "str" are reserved for the
    > > implementation. You should change those.
    > >

    >
    > IIRC, the restriction is not for the local variables. Please
    > correct me, if I understood it wrongly.


    See 7.1.3, 7.1.4 & 7.26

    Identifiers beginning with 'str' followed by at least one lower case letter are reserved
    for use as identifiers with external linkage. [In C90, such linkage is possibly case
    insensitive.] If <string.h> or <stdlib.h> is included, then they are reserved as macro
    names and file scope identifiers too.

    But it's still possible to declare a local (auto) variable and have problems...

    #include <string.h>

    void bar(int);

    void foo(void)
    {
    void (*strobe)(int) = bar; /* ok */
    strobe(42); /* UB */
    }

    --
    Peter
     
    Peter Nilsson, Jun 26, 2004
    #6
  7. Markus Dehmann

    Jack Klein Guest

    On Sat, 26 Jun 2004 12:38:41 +1000, "Peter Nilsson"
    <> wrote in comp.lang.c:

    > "Vijay Kumar R Zanvar" <> wrote in message
    > news:...
    > > "CBFalconer" <> wrote in message news:...
    > > >
    > > > In addition, names begining with "str" are reserved for the
    > > > implementation. You should change those.
    > > >

    > >
    > > IIRC, the restriction is not for the local variables. Please
    > > correct me, if I understood it wrongly.

    >
    > See 7.1.3, 7.1.4 & 7.26
    >
    > Identifiers beginning with 'str' followed by at least one lower case letter are reserved
    > for use as identifiers with external linkage. [In C90, such linkage is possibly case
    > insensitive.] If <string.h> or <stdlib.h> is included, then they are reserved as macro
    > names and file scope identifiers too.
    >
    > But it's still possible to declare a local (auto) variable and have problems...
    >
    > #include <string.h>
    >
    > void bar(int);
    >
    > void foo(void)
    > {
    > void (*strobe)(int) = bar; /* ok */
    > strobe(42); /* UB */
    > }


    I disagree with your assessment. The fact that a block scoped pointer
    object holds the name of something (function or object) with external
    linkage does not violate the standard requirement above. The linkage
    and scope that count are only that of the identifier itself, 'strobe'
    in this case.

    There is absolutely no undefined behavior in your example.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    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, Jun 26, 2004
    #7
  8. "Jack Klein" <> wrote in message
    news:...
    >
    > On Sat, 26 Jun 2004 12:38:41 +1000, "Peter Nilsson"
    > <> wrote in comp.lang.c:
    >
    > > "Vijay Kumar R Zanvar" <> wrote in message
    > > news:...
    > > >
    > > > "CBFalconer" <> wrote in message
    > > > news:...
    > > > >
    > > > > In addition, names begining with "str" are reserved for the
    > > > > implementation. You should change those.
    > > > >
    > > >
    > > > IIRC, the restriction is not for the local variables. Please
    > > > correct me, if I understood it wrongly.

    > >
    > > See 7.1.3, 7.1.4 & 7.26
    > >
    > > Identifiers beginning with 'str' followed by at least one lower
    > > case letter are reserved for use as identifiers with external
    > > linkage. [In C90, such linkage is possibly case insensitive.]
    > > If <string.h> or <stdlib.h> is included, then they are reserved

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > > as macro names and file scope identifiers too.

    ^^^^^^^^^^^^^^
    > >
    > > But it's still possible to declare a local (auto) variable and have
    > > problems...
    > >
    > > #include <string.h>
    > >
    > > void bar(int);
    > >
    > > void foo(void)
    > > {
    > > void (*strobe)(int) = bar; /* ok */
    > > strobe(42); /* UB */


    This is a function macro like application of a reserved identifier.

    > > }

    >
    > I disagree with your assessment. The fact that a block scoped pointer
    > object holds the name of something (function or object) with external
    > linkage does not violate the standard requirement above. ...


    It's the reserved use as a function macro which is the problem.

    --
    Peter
     
    Peter Nilsson, Jun 27, 2004
    #8
  9. "Peter Nilsson" <> wrote:
    >"Jack Klein" <> wrote in message
    >news:...
    >>
    >> On Sat, 26 Jun 2004 12:38:41 +1000, "Peter Nilsson"
    >> <> wrote in comp.lang.c:
    >>
    >> > "Vijay Kumar R Zanvar" <> wrote in message
    >> > news:...
    >> > >
    >> > > "CBFalconer" <> wrote in message
    >> > > news:...
    >> > > >
    >> > > > In addition, names begining with "str" are reserved for the
    >> > > > implementation. You should change those.
    >> > >
    >> > > IIRC, the restriction is not for the local variables. Please
    >> > > correct me, if I understood it wrongly.
    >> >
    >> > See 7.1.3, 7.1.4 & 7.26
    >> >
    >> > Identifiers beginning with 'str' followed by at least one lower
    >> > case letter are reserved for use as identifiers with external
    >> > linkage. [In C90, such linkage is possibly case insensitive.]
    >> > If <string.h> or <stdlib.h> is included, then they are reserved

    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> > as macro names and file scope identifiers too.

    > ^^^^^^^^^^^^^^
    >> >
    >> > But it's still possible to declare a local (auto) variable and have
    >> > problems...
    >> >
    >> > #include <string.h>
    >> >
    >> > void bar(int);
    >> >
    >> > void foo(void)
    >> > {
    >> > void (*strobe)(int) = bar; /* ok */
    >> > strobe(42); /* UB */

    >
    >This is a function macro like application of a reserved identifier.


    No. I can't find *any* macro defined in your code, for that matter.
    What's disallowed is to write something like this:

    #include <string.h>
    #define strobe0 42 /* UB, str[a-z]* used as macro name */
    static int strobe; /* UB, str[a-z]* used as file scope identifier */

    whereas e.g. the following TU is valid:

    /* Look Ma, no string.h included. */
    #define strobe0 42
    static int strobe;

    as well as this one:

    #include <string.h>
    int foo( void )
    {
    int strstr = 666; /* Look Ma, block scope identifier. */
    return strstr;
    }

    >> I disagree with your assessment. The fact that a block scoped pointer
    >> object holds the name of something (function or object) with external
    >> linkage does not violate the standard requirement above. ...

    >
    >It's the reserved use as a function macro which is the problem.


    No. It's used as a simple block scope identifier, which is perfectly
    fine (modulo it may shadow a 'strobe' identifier defined in some
    future version of string.h, but that's the programmer's problem then,
    and doesn't result in undefined behaviour a priori).

    Regards
    --
    Irrwahn Grausewitz ()
    welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
    clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
    clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
     
    Irrwahn Grausewitz, Jun 27, 2004
    #9
  10. "Irrwahn Grausewitz" <> wrote in message
    news:...
    > "Peter Nilsson" <> wrote:
    > >"Jack Klein" <> wrote in message
    > >news:...
    > >>
    > >> On Sat, 26 Jun 2004 12:38:41 +1000, "Peter Nilsson"
    > >> <> wrote in comp.lang.c:
    > >>
    > >> > "Vijay Kumar R Zanvar" <> wrote in message
    > >> > news:...
    > >> > >
    > >> > > "CBFalconer" <> wrote in message
    > >> > > news:...
    > >> > > >
    > >> > > > In addition, names begining with "str" are reserved for the
    > >> > > > implementation. You should change those.
    > >> > >
    > >> > > IIRC, the restriction is not for the local variables. Please
    > >> > > correct me, if I understood it wrongly.
    > >> >
    > >> > See 7.1.3, 7.1.4 & 7.26
    > >> >
    > >> > Identifiers beginning with 'str' followed by at least one lower
    > >> > case letter are reserved for use as identifiers with external
    > >> > linkage. [In C90, such linkage is possibly case insensitive.]
    > >> > If <string.h> or <stdlib.h> is included, then they are reserved

    > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > >> > as macro names and file scope identifiers too.

    > > ^^^^^^^^^^^^^^
    > >> >
    > >> > But it's still possible to declare a local (auto) variable and have
    > >> > problems...
    > >> >
    > >> > #include <string.h>
    > >> >
    > >> > void bar(int);
    > >> >
    > >> > void foo(void)
    > >> > {
    > >> > void (*strobe)(int) = bar; /* ok */
    > >> > strobe(42); /* UB */

    > >
    > >This is a function macro like application of a reserved identifier.

    >
    > No.


    Huh? You don't think its a reserved identifier, or you don't think its a 'function macro
    like' application?

    > I can't find *any* macro defined in your code, for that matter.


    It's right there in the line...

    #include <string.h>

    Translation phases 1 through 4 occur long before any block scopes are identified by the
    implementation.

    My argument is quite simple: The identifier strobe is reserved as an external identifier,
    therefore it is reserved as a macro whenever <string.h> or <stdlib.h> is included,
    therefore a token sequence like...

    strobe(42)

    ....is potentially a macro invocation, therefore it is potentially UB since no programmer
    cannot possibly know the number of arguments the identifier will be defined with (until it
    makes the standard as a prototyped function).

    What am I missing?

    --
    Peter
     
    Peter Nilsson, Jun 28, 2004
    #10
  11. Markus Dehmann

    Richard Bos Guest

    "Peter Nilsson" <> wrote:

    > "Irrwahn Grausewitz" <> wrote in message
    > news:...
    > > "Peter Nilsson" <> wrote:
    > > >"Jack Klein" <> wrote in message
    > > >news:...
    > > >>
    > > >> On Sat, 26 Jun 2004 12:38:41 +1000, "Peter Nilsson"
    > > >> <> wrote in comp.lang.c:
    > > >>
    > > >> > Identifiers beginning with 'str' followed by at least one lower
    > > >> > case letter are reserved for use as identifiers with external
    > > >> > linkage. [In C90, such linkage is possibly case insensitive.]
    > > >> > If <string.h> or <stdlib.h> is included, then they are reserved
    > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > > >> > as macro names and file scope identifiers too.
    > > > ^^^^^^^^^^^^^^
    > > >> >
    > > >> > But it's still possible to declare a local (auto) variable and have
    > > >> > problems...
    > > >> >
    > > >> > #include <string.h>
    > > >> >
    > > >> > void bar(int);
    > > >> >
    > > >> > void foo(void)
    > > >> > {
    > > >> > void (*strobe)(int) = bar; /* ok */
    > > >> > strobe(42); /* UB */
    > > >
    > > >This is a function macro like application of a reserved identifier.


    > > I can't find *any* macro defined in your code, for that matter.


    > My argument is quite simple: The identifier strobe is reserved as an external identifier,
    > therefore it is reserved as a macro whenever <string.h> or <stdlib.h> is included,
    > therefore a token sequence like...
    >
    > strobe(42)
    >
    > ...is potentially a macro invocation, therefore it is potentially UB since no programmer
    > cannot possibly know the number of arguments the identifier will be defined with (until it
    > makes the standard as a prototyped function).
    >
    > What am I missing?


    The fact that, if it _were_ a function-like macro, the first line would
    in all probability have been an error.

    Richard
     
    Richard Bos, Jun 28, 2004
    #11
  12. "Richard Bos" <> wrote in message
    news:...
    > "Peter Nilsson" <> wrote:
    > > >
    > > > >> >
    > > > >> > #include <string.h>
    > > > >> >
    > > > >> > void bar(int);


    [!! I have no idea why I put in this decleration!]

    > > > >> > void foo(void)
    > > > >> > {
    > > > >> > void (*strobe)(int) = bar; /* ok */
    > > > >> > strobe(42); /* UB */
    > > > >
    > > > >This is a function macro like application of a reserved identifier.

    >
    > > > I can't find *any* macro defined in your code, for that matter.

    >
    > > My argument is quite simple: The identifier strobe is reserved as an
    > > external identifier, therefore it is reserved as a macro whenever
    > > <string.h> or <stdlib.h> is included, therefore a token sequence
    > > like...
    > >
    > > strobe(42)
    > >
    > > ...is potentially a macro invocation, therefore it is potentially UB
    > > since no programmer cannot possibly know the number of arguments the
    > > identifier will be defined with (until it makes the standard as a
    > > prototyped function).
    > >
    > > What am I missing?

    >
    > The fact that, if it _were_ a function-like macro, the first line would
    > in all probability have been an error.


    Which 'first line'?

    I don't think you mean...

    void (*strobe)(int) = bar;

    ....since I'm sure you've seen code like...

    #define foo(x) ((x) + 42)

    int (foo)(int x) /* avoid macro invocation */
    {
    return x + 42;
    }

    But I can't see a problem with any other line, other than the one I highlight as UB.

    --
    Peter
     
    Peter Nilsson, Jun 28, 2004
    #12
  13. Markus Dehmann

    Dan Pop Guest

    In <> Jack Klein <> writes:

    >On Sat, 26 Jun 2004 12:38:41 +1000, "Peter Nilsson"
    ><> wrote in comp.lang.c:
    >
    >> But it's still possible to declare a local (auto) variable and have problems...
    >>
    >> #include <string.h>
    >>
    >> void bar(int);
    >>
    >> void foo(void)
    >> {
    >> void (*strobe)(int) = bar; /* ok */
    >> strobe(42); /* UB */
    >> }

    >
    >I disagree with your assessment. The fact that a block scoped pointer
    >object holds the name of something (function or object) with external
    >linkage does not violate the standard requirement above. The linkage
    >and scope that count are only that of the identifier itself, 'strobe'
    >in this case.
    >
    >There is absolutely no undefined behavior in your example.


    Wrong. There are two key factors in this simple example:

    1. <string.h> is included. As a result, a function-like macro named
    strobe may be in scope until the end of the translation unit or until
    explicitly undefined.

    2. strobe(42) would invoke the macro described above. The behaviour, is,
    of course, undefined.

    And the programmer got exactly what he deserved, by dereferencing a
    function pointer as if it were a real function designator.
    (*strobe)(42) is perfectly immune to the problem illustrated above.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 28, 2004
    #13
  14. Markus Dehmann

    Dan Pop Guest

    In <> (Richard Bos) writes:

    >"Peter Nilsson" <> wrote:
    >
    >> "Irrwahn Grausewitz" <> wrote in message
    >> news:...
    >> > "Peter Nilsson" <> wrote:
    >> > >"Jack Klein" <> wrote in message
    >> > >news:...
    >> > >>
    >> > >> On Sat, 26 Jun 2004 12:38:41 +1000, "Peter Nilsson"
    >> > >> <> wrote in comp.lang.c:
    >> > >>
    >> > >> > Identifiers beginning with 'str' followed by at least one lower
    >> > >> > case letter are reserved for use as identifiers with external
    >> > >> > linkage. [In C90, such linkage is possibly case insensitive.]
    >> > >> > If <string.h> or <stdlib.h> is included, then they are reserved
    >> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> > >> > as macro names and file scope identifiers too.
    >> > > ^^^^^^^^^^^^^^
    >> > >> >
    >> > >> > But it's still possible to declare a local (auto) variable and have
    >> > >> > problems...
    >> > >> >
    >> > >> > #include <string.h>
    >> > >> >
    >> > >> > void bar(int);
    >> > >> >
    >> > >> > void foo(void)
    >> > >> > {
    >> > >> > void (*strobe)(int) = bar; /* ok */
    >> > >> > strobe(42); /* UB */
    >> > >
    >> > >This is a function macro like application of a reserved identifier.

    >
    >> > I can't find *any* macro defined in your code, for that matter.

    >
    >> My argument is quite simple: The identifier strobe is reserved as an external identifier,
    >> therefore it is reserved as a macro whenever <string.h> or <stdlib.h> is included,
    >> therefore a token sequence like...
    >>
    >> strobe(42)
    >>
    >> ...is potentially a macro invocation, therefore it is potentially UB since no programmer
    >> cannot possibly know the number of arguments the identifier will be defined with (until it
    >> makes the standard as a prototyped function).
    >>
    >> What am I missing?

    >
    >The fact that, if it _were_ a function-like macro, the first line would
    >in all probability have been an error.


    Nonsense! If it were a function-like macro, the first line wouldn't have
    referred to it, due to purely syntactical issues. See 7.1.4 for
    further enlightenment.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 28, 2004
    #14
  15. "Peter Nilsson" <> wrote:
    >"Irrwahn Grausewitz" <> wrote:
    >> "Peter Nilsson" <> wrote:
    >> >> "Peter Nilsson" wrote:

    <snippage>
    >> >> > Identifiers beginning with 'str' followed by at least one lower
    >> >> > case letter are reserved for use as identifiers with external
    >> >> > linkage. [In C90, such linkage is possibly case insensitive.]
    >> >> > If <string.h> or <stdlib.h> is included, then they are reserved
    >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> >> > as macro names and file scope identifiers too.
    >> > ^^^^^^^^^^^^^^
    >> >> >
    >> >> > But it's still possible to declare a local (auto) variable and have
    >> >> > problems...
    >> >> >
    >> >> > #include <string.h>
    >> >> >
    >> >> > void bar(int);
    >> >> >
    >> >> > void foo(void)
    >> >> > {
    >> >> > void (*strobe)(int) = bar; /* ok */
    >> >> > strobe(42); /* UB */
    >> >
    >> >This is a function macro like application of a reserved identifier.

    >>
    >> No.

    >
    >Huh? You don't think its a reserved identifier, or you don't think its a 'function macro
    >like' application?


    The latter, alas I screwed up.

    <snip>
    >My argument is quite simple: The identifier strobe is reserved as an external identifier,
    >therefore it is reserved as a macro whenever <string.h> or <stdlib.h> is included,
    >therefore a token sequence like...
    >
    > strobe(42)


    Though (strobe)(42) would still be OK, right?

    >...is potentially a macro invocation, therefore it is potentially UB since no programmer
    >cannot possibly know the number of arguments the identifier will be defined with (until it
    >makes the standard as a prototyped function).

    s/cannot/can/

    >What am I missing?


    The fact that I had things kind of backwards in my mind - sorry for
    the confusion... :eek:}

    Regards
    --
    Irrwahn Grausewitz ()
    welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
    clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
    clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
     
    Irrwahn Grausewitz, Jun 28, 2004
    #15
    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. Rocke Robertson
    Replies:
    14
    Views:
    13,033
    Dan Pop
    Oct 2, 2003
  2. Dawn Minnis
    Replies:
    4
    Views:
    1,574
    Dawn Minnis
    Feb 20, 2005
  3. Replies:
    2
    Views:
    1,308
    Martin Ambuhl
    Apr 1, 2005
  4. Juggernaut
    Replies:
    10
    Views:
    1,662
    CBFalconer
    Apr 9, 2005
  5. Zach
    Replies:
    3
    Views:
    7,635
Loading...

Share This Page