Visual Studio and ISO C++ Names - Programmer

This is a discussion on Visual Studio and ISO C++ Names - Programmer ; Some of the code we write at my company runs on both UNIX systems (mostly AIX) and Microsoft Windows systems. The code which was originally written on UNIX contains a number of Posix function calls, many of which compile and ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: Visual Studio and ISO C++ Names

  1. Visual Studio and ISO C++ Names

    Some of the code we write at my company runs on both UNIX systems
    (mostly AIX) and Microsoft Windows systems. The code which was
    originally written on UNIX contains a number of Posix function calls,
    many of which compile and execute properly on Windows. We have
    recently begun using the Microsoft Visual Studio .net 2005 compiler and
    we now getting the following warning message about a number of Posix
    calls.

    ..\wuu.c(790) : warning C4996: 'unlink' was declared deprecated
    C:\Program Files\Microsoft Visual Studio 8\VC\include\stdio.h(290) :
    see declaration of 'unlink'
    Message: 'The POSIX name for this item is deprecated. Instead, use
    the ISO C++ conformant name: _unlink. See online help for details.'

    Does anyone know what the reason for this is? I've read every C and
    C++ book I own and searched the internet trying to find an explanation
    for this change. For the life of me, I can't see how "_unlink" is any
    more ISO C++ conformant than "unlink".

    PS - Even after reading the charter of several newsgroups it wasn't
    clear to me where a question like this belongs, so I cross-posted this
    to a Windows newsgroup, figuring perhaps people there have heard an
    explanation from Microsoft which I missed, and a C++ and UNIX
    newsgroup, figuring you might have some insight on the issue of ISO C++
    and Posix names. If there are more relevant groups, please redirect
    the discussion as you see fit.

    --
    Tom Einertson E-mail: tome@siemens-emis.com
    SIEMENS Power Transmission & Distribution Phone: (952) 607-2244
    Energy Management & Automation Division Fax: (952) 607-2018
    10900 Wayzata Boulevard, Suite 400
    Minnetonka, MN, 55305



    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  2. Re: Visual Studio and ISO C++ Names

    ""Tom Einertson"" wrote in message
    news:YMqdnenWtqO8n0beRVn-iQ@comcast.com...

    > Some of the code we write at my company runs on both UNIX systems
    > (mostly AIX) and Microsoft Windows systems. The code which was
    > originally written on UNIX contains a number of Posix function calls,
    > many of which compile and execute properly on Windows. We have
    > recently begun using the Microsoft Visual Studio .net 2005 compiler and
    > we now getting the following warning message about a number of Posix
    > calls.
    >
    > .\wuu.c(790) : warning C4996: 'unlink' was declared deprecated
    > C:\Program Files\Microsoft Visual Studio 8\VC\include\stdio.h(290)
    > :
    > see declaration of 'unlink'
    > Message: 'The POSIX name for this item is deprecated. Instead, use
    > the ISO C++ conformant name: _unlink. See online help for details.'
    >
    > Does anyone know what the reason for this is?


    Microsoft decided to add a whole slew of new warnings with V8 (VC++
    2005). They've taken no small amount of heat for using the phrase
    "declared deprecated" since a) "deprecated" is a term of art from
    ISO standards, and b) Microsoft is doing the deprecating here, not
    ISO. Your best bet is probably to make it standard practice to
    disable this warning for all compiles.

    In any event, unlink is a perfectly fine function to call in a
    combined Standard C/Posix environment. It's not okay in Standard
    C alone, but you probably don't care about that.

    > I've read every C and
    > C++ book I own and searched the internet trying to find an explanation
    > for this change. For the life of me, I can't see how "_unlink" is any
    > more ISO C++ conformant than "unlink".


    Both Standard C and Standard C++ let the implementation define
    external symbols with a leading underscore, as conforming
    extensions. But "unlink" invades the space of names reserved
    to the programmer.

    HTH,

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com


    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  3. Re: Visual Studio and ISO C++ Names


    "Tom Einertson" wrote:
    > Some of the code we write at my company runs on both UNIX systems
    > (mostly AIX) and Microsoft Windows systems. The code which was
    > originally written on UNIX contains a number of Posix function calls,
    > many of which compile and execute properly on Windows. We have
    > recently begun using the Microsoft Visual Studio .net 2005 compiler and
    > we now getting the following warning message about a number of Posix
    > calls.
    >
    > .\wuu.c(790) : warning C4996: 'unlink' was declared deprecated
    > C:\Program Files\Microsoft Visual Studio 8\VC\include\stdio.h(290) :
    > see declaration of 'unlink'
    > Message: 'The POSIX name for this item is deprecated. Instead, use
    > the ISO C++ conformant name: _unlink. See online help for details.'


    This is definitely confusing. A few months ago a similar thread
    started in c.l.c++.m. Here is a link to it:
    http://groups.google.com/group/comp....af2aac72aa1312

    Not sure if its the same thing though.

    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  4. Re: Visual Studio and ISO C++ Names

    "Tom Einertson" wrote:

    [ ... ]

    > Does anyone know what the reason for this is? I've read every C and
    > C++ book I own and searched the internet trying to find an explanation
    > for this change. For the life of me, I can't see how "_unlink" is any
    > more ISO C++ conformant than "unlink".


    IMO, this is simply a mistake on MS' part. First of all, this only
    matters at all if the name is declared in a header that's defined as
    part of the C++ standard in the first place.

    Second, if that was the case, it would probably need to become _Unlink
    or __unlink (though, of course, variations like un__link are also
    possible).

    --
    Later,
    Jerry.

    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  5. Re: Visual Studio and ISO C++ Names

    ""P.J. Plauger"" wrote in message
    news:tq2dnc2pUadY5EbeRVn-tw@giganews.com...

    > Microsoft decided to add a whole slew of new warnings with V8 (VC++
    > 2005). They've taken no small amount of heat for using the phrase
    > "declared deprecated" since a) "deprecated" is a term of art from
    > ISO standards, and b) Microsoft is doing the deprecating here, not
    > ISO. Your best bet is probably to make it standard practice to
    > disable this warning for all compiles.


    I don't fault them for using the term deprecated, just in trying to
    blame it on ISO C++. If Microsoft decides they might not support some
    interface in the future that's up to them. But the error message seems
    to imply that they were forced to do this in order to become C++
    conformant.

    > In any event, unlink is a perfectly fine function to call in a
    > combined Standard C/Posix environment. It's not okay in Standard
    > C alone, but you probably don't care about that.
    >
    > Both Standard C and Standard C++ let the implementation define
    > external symbols with a leading underscore, as conforming
    > extensions. But "unlink" invades the space of names reserved
    > to the programmer.


    It's clear that as the supplier of the compiler Microsoft has the
    option to use names beginning with an underscore for conforming
    extensions. But "unlink" is an operating system interface, and there
    has always been overlap between the names assigned for operating system
    interfaces and user programs.

    I can't find anything, though, that REQUIRES Microsoft to use leading
    underscores in the names of operating system interfaces. I also notice
    that they only declared Posix names without leading underscores to be
    non-conformant. We don't get errors saying that Microsoft Win32 system
    interfaces such as CreateFile needs to be named _CreateFile in order to
    be ISO C++ conformant.

    --
    Tom Einertson E-mail: tome@siemens-emis.com
    SIEMENS Power Transmission & Distribution Phone: (952) 607-2244
    Energy Management & Automation Division Fax: (952) 607-2018
    10900 Wayzata Boulevard, Suite 400
    Minnetonka, MN, 55305



    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  6. Re: Visual Studio and ISO C++ Names

    Tom Einertson wrote:

    > Some of the code we write at my company runs on both UNIX systems
    > (mostly AIX) and Microsoft Windows systems. The code which was
    > originally written on UNIX contains a number of Posix function calls,
    > many of which compile and execute properly on Windows. We have
    > recently begun using the Microsoft Visual Studio .net 2005 compiler and
    > we now getting the following warning message about a number of Posix
    > calls.
    >
    > .\wuu.c(790) : warning C4996: 'unlink' was declared deprecated
    > C:\Program Files\Microsoft Visual Studio 8\VC\include\stdio.h(290)
    > :
    > see declaration of 'unlink'
    > Message: 'The POSIX name for this item is deprecated. Instead, use
    > the ISO C++ conformant name: _unlink. See online help for details.'


    Strictly speaking I guess this is correct, albeit typical misleading M$
    waffle. "unlink" is may be depreciated (it never could work under windoze)
    but iirc the language states leading underscores are reserved for the
    implementation.

    > Does anyone know what the reason for this is? I've read every C and
    > C++ book I own and searched the internet trying to find an explanation
    > for this change. For the life of me, I can't see how "_unlink" is any
    > more ISO C++ conformant than "unlink".


    You can likely replace "unlink" with "remove" (or std::remove). The
    semantics are different however - *nix can unlink a file which is open
    whereas windoze cannot. Under unix a file/folder is trashed when the last
    process with a handle to it, dies. Think tempfiles...

    //create file
    //unlink
    //carry on accessing it
    //(process dies, kernel removes file from disk if last handle

    ..whereas windoze will barf.

    > PS - Even after reading the charter of several newsgroups it wasn't
    > clear to me where a question like this belongs, so I cross-posted this
    > to a Windows newsgroup, figuring perhaps people there have heard an
    > explanation from Microsoft which I missed, and a C++ and UNIX
    > newsgroup, figuring you might have some insight on the issue of ISO C++
    > and Posix names. If there are more relevant groups, please redirect
    > the discussion as you see fit.


    Any generic group will suffice - look for "inode" references in manuals.

    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  7. Re: Visual Studio and ISO C++ Names

    Jerry Coffin wrote in news:1138443947.035791.316900
    @g47g2000cwa.googlegroups.com in comp.std.c++:

    > "Tom Einertson" wrote:
    >
    > [ ... ]
    >
    >> Does anyone know what the reason for this is? I've read every C and
    >> C++ book I own and searched the internet trying to find an explanation
    >> for this change. For the life of me, I can't see how "_unlink" is any
    >> more ISO C++ conformant than "unlink".

    >
    > IMO, this is simply a mistake on MS' part. First of all, this only
    > matters at all if the name is declared in a header that's defined as
    > part of the C++ standard in the first place.


    It's defined in stdio.h, so this is the case here.

    >
    > Second, if that was the case, it would probably need to become _Unlink
    > or __unlink (though, of course, variations like un__link are also
    > possible).
    >


    Names begining with a single underscore are reserved for the
    implementation in the global namespace, so Microsoft are moving
    ::unlink to the implementations reserved set of names by
    prepending a single underscore, or in there words making it an
    "ISO C++ conformant name".

    This program will produce the warning:

    #include

    int main()
    {
    unlink( "c:\\please-delete-me.txt" );
    }

    But I only get the warning if use unlink(), So (IMO) this
    warning is useful as its telling me my programme won't
    compile under the next version of VC++.

    Rob.
    --
    http://www.victim-prime.dsl.pipex.com/

    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  8. Re: Visual Studio and ISO C++ Names


    "P.J. Plauger" wrote:

    > ""Tom Einertson"" wrote in message
    > news:YMqdnenWtqO8n0beRVn-iQ@comcast.com...
    >
    > > I've read every C and
    > > C++ book I own and searched the internet trying to find an explanation
    > > for this change. For the life of me, I can't see how "_unlink" is any
    > > more ISO C++ conformant than "unlink".

    >
    > Both Standard C and Standard C++ let the implementation define
    > external symbols with a leading underscore, as conforming
    > extensions. But "unlink" invades the space of names reserved
    > to the programmer.


    Um, doesn't this say that only an implementor of C++ should use the
    name "_unlink" - and that a vendor neutral API would not be ISO
    conformant were it to use this name?
    --
    Alan Griffiths

    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  9. Re: Visual Studio and ISO C++ Names

    "Rob Williscroft" wrote in message
    news:Xns975A7BE66BEDDrtwfreenetREMOVEcouk@216.196. 109.145...
    > Jerry Coffin wrote in news:1138443947.035791.316900
    > @g47g2000cwa.googlegroups.com in comp.std.c++:
    >
    >> "Tom Einertson" wrote:
    >>
    >> [ ... ]
    >>
    >>> Does anyone know what the reason for this is? I've read every C and
    >>> C++ book I own and searched the internet trying to find an explanation
    >>> for this change. For the life of me, I can't see how "_unlink" is any
    >>> more ISO C++ conformant than "unlink".

    >>
    >> IMO, this is simply a mistake on MS' part. First of all, this only
    >> matters at all if the name is declared in a header that's defined as
    >> part of the C++ standard in the first place.

    >
    > It's defined in stdio.h, so this is the case here.

    ...
    >
    > Names begining with a single underscore are reserved for the
    > implementation in the global namespace, so Microsoft are moving
    > ::unlink to the implementations reserved set of names by
    > prepending a single underscore, or in there words making it an
    > "ISO C++ conformant name".


    I didn't realize that Microsoft defined unlink in stdio.h. On most
    UNIXes, it is defined in unistd.h. That seems to explain what's going
    on here, though. Presumably Microsoft realized that they shouldn't
    have non-standard extensions in a standard header file unless the name
    began with an underscore, and this was their solution.

    Unfortunately they have fixed the problem in the wrong way (or at least
    in the most inconvenient way possible for their users). Why didn't
    they just move the prototype from stdio.h to a .h file which is not
    defined in the C++ standard? Putting it in a file named unistd.h would
    seem the obvious choice, since doing so would simplify porting of UNIX
    code to Windows. Or instead of moving it immediately to the new file,
    they could have defined the prototype in both .h files during the
    transition period and used the pre-processor to prevent duplicate
    definitions.

    Microsoft already went to the work of flagging these functions for
    warnings. Instead of warning you change the function name, couldn't
    they instead have warned you to #include the correct file if you hadn't
    done so? That doesn't seem that difficult to implement and would move
    users toward correct usage.

    > But I only get the warning if use unlink(), So (IMO) this
    > warning is useful as its telling me my programme won't
    > compile under the next version of VC++.


    Normally I wouldn't care about such an issue. I would just change the
    name to the one Microsoft wants me to use. Unfortunately in this case
    doing so will make the code so it won't compile on UNIX any more. So
    what we had before was a harmless non-compliance with the C++ spec.
    What we have now is something which will make it more difficult to
    maintain a common code base on Windows and UNIX.

    --
    Tom Einertson E-mail: tome@siemens-emis.com
    SIEMENS Power Transmission & Distribution Phone: (952) 607-2244
    Energy Management & Automation Division Fax: (952) 607-2018
    10900 Wayzata Boulevard, Suite 400
    Minnetonka, MN, 55305

    >



    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  10. Re: Visual Studio and ISO C++ Names

    wrote in message
    news:1138546549.729355.195400@o13g2000cwo.googlegr oups.com...

    > "P.J. Plauger" wrote:
    >
    >> ""Tom Einertson"" wrote in message
    >> news:YMqdnenWtqO8n0beRVn-iQ@comcast.com...
    >>
    >> > I've read every C and
    >> > C++ book I own and searched the internet trying to find an explanation
    >> > for this change. For the life of me, I can't see how "_unlink" is any
    >> > more ISO C++ conformant than "unlink".

    >>
    >> Both Standard C and Standard C++ let the implementation define
    >> external symbols with a leading underscore, as conforming
    >> extensions. But "unlink" invades the space of names reserved
    >> to the programmer.

    >
    > Um, doesn't this say that only an implementor of C++ should use the
    > name "_unlink" - and that a vendor neutral API would not be ISO
    > conformant were it to use this name?


    Basically, yes. I'm the guy who insisted back in 1983 that the space of
    names available to a C program be partitioned into:

    a) those defined by the implementation for the benefit of the programmer
    (such as printf)

    b) those reserved to the programmer (such as foo)

    c) those reserved to the implementation (such as _unlink)

    We knew even then that "the implementation" was too monolithic --
    often more than one source supplies bits of the implementation --
    but that was the best we could do at the time. Standard C++
    has introduced namespaces to help, but they have achieved only
    a fraction of their stated goals. (That's what happens when you
    standardize a paper tiger.)

    In this particular case, Posix supplies a list of category (a) names
    (such as unlink) that you should get defined when and only when you
    include certain headers. Since the C Standard stole its headers from
    Unix, which is the same source as for Posix, some of those headers
    overlap historically. Nevertheless, compiler warnings should have
    some way of taking into account whether the supported environment
    is "pure" Standard C++ (a Platonic ideal) or a mixed C/C++/Posix
    environment. The current attempt by Microsoft to help us poor
    programmers fails to take that into account. It insists on treating
    unlink as a category (b) name, which is myopic.

    Still another wrinkle is what to do about category (c) names,
    which was the nub of your original question. We implementers are
    still in the Bad Old Days where we have to duke it out with
    other implementers for the use of the implementation-reserved
    space of names. You try adding _unlink and see what happens when
    you test under a given compiler. (Just recently, in fact, one of
    our larger embedded compiler customers asked us to rename our
    macro _POSIX_C_LIB, because Posix insists that all _POSIX* names
    are theirs.) But at least that reserves the worst problems to us
    Trained Professionals. We just have to get our stories straight.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com


    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  11. Re: Visual Studio and ISO C++ Names

    In article , Tom Einertson
    writes
    >Some of the code we write at my company runs on both UNIX systems
    >(mostly AIX) and Microsoft Windows systems. The code which was
    >originally written on UNIX contains a number of Posix function calls,
    >many of which compile and execute properly on Windows. We have
    >recently begun using the Microsoft Visual Studio .net 2005 compiler and
    >we now getting the following warning message about a number of Posix
    >calls.
    >
    >.\wuu.c(790) : warning C4996: 'unlink' was declared deprecated
    > C:\Program Files\Microsoft Visual Studio 8\VC\include\stdio.h(290) :
    >see declaration of 'unlink'
    > Message: 'The POSIX name for this item is deprecated. Instead, use
    >the ISO C++ conformant name: _unlink. See online help for details.'
    >
    >Does anyone know what the reason for this is? I've read every C and
    >C++ book I own and searched the internet trying to find an explanation
    >for this change. For the life of me, I can't see how "_unlink" is any
    >more ISO C++ conformant than "unlink".


    All will be explained.
    http://www.octopull.demon.co.uk/edit...rial200601.pdf



    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  12. Re: Visual Studio and ISO C++ Names

    In article <1138443947.035791.316900@g47g2000cwa.googlegroups. com>,
    Jerry Coffin writes
    >"Tom Einertson" wrote:
    >
    >[ ... ]
    >
    >> Does anyone know what the reason for this is? I've read every C and
    >> C++ book I own and searched the internet trying to find an explanation
    >> for this change. For the life of me, I can't see how "_unlink" is any
    >> more ISO C++ conformant than "unlink".

    >
    >IMO, this is simply a mistake on MS' part.


    It's not a mistake....


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  13. Re: Visual Studio and ISO C++ Names

    In article , Tom Einertson
    writes
    >
    >Normally I wouldn't care about such an issue. I would just change the
    >name to the one Microsoft wants me to use. Unfortunately in this case
    >doing so will make the code so it won't compile on UNIX any more.


    I think the reasons for the MS "mistake" are becoming clear.....

    > So
    >what we had before was a harmless non-compliance with the C++ spec.
    >What we have now is something which will make it more difficult to
    >maintain a common code base on Windows and UNIX.


    Yes. SO why use Unix? It is not an approved MS OS what is more Unix does
    not conform to the ISO Safe C or ISO Safe C++ Libraries.....

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  14. Re: Visual Studio and ISO C++ Names

    ""P.J. Plauger"" wrote in message
    news:37-dnTQ056haQ0DeRVn-pw@giganews.com...
    > wrote in message
    > news:1138546549.729355.195400@o13g2000cwo.googlegr oups.com...
    >
    >> "P.J. Plauger" wrote:
    >>
    >>> ""Tom Einertson"" wrote in message
    >>> news:YMqdnenWtqO8n0beRVn-iQ@comcast.com...
    >>>
    >>> > I've read every C and
    >>> > C++ book I own and searched the internet trying to find an explanation
    >>> > for this change. For the life of me, I can't see how "_unlink" is any
    >>> > more ISO C++ conformant than "unlink".
    >>>
    >>> Both Standard C and Standard C++ let the implementation define
    >>> external symbols with a leading underscore, as conforming
    >>> extensions. But "unlink" invades the space of names reserved
    >>> to the programmer.

    >>
    >> Um, doesn't this say that only an implementor of C++ should use the
    >> name "_unlink" - and that a vendor neutral API would not be ISO
    >> conformant were it to use this name?

    >
    > Basically, yes. I'm the guy who insisted back in 1983 that the space of
    > names available to a C program be partitioned into:
    >
    > a) those defined by the implementation for the benefit of the programmer
    > (such as printf)
    >
    > b) those reserved to the programmer (such as foo)
    >
    > c) those reserved to the implementation (such as _unlink)

    ...
    > In this particular case, Posix supplies a list of category (a) names
    > (such as unlink) that you should get defined when and only when you
    > include certain headers. Since the C Standard stole its headers from
    > Unix, which is the same source as for Posix, some of those headers
    > overlap historically. Nevertheless, compiler warnings should have
    > some way of taking into account whether the supported environment
    > is "pure" Standard C++ (a Platonic ideal) or a mixed C/C++/Posix
    > environment. The current attempt by Microsoft to help us poor
    > programmers fails to take that into account. It insists on treating
    > unlink as a category (b) name, which is myopic.


    Actually it seems to me that previous versions of Visual Studio treated
    unlink as a category (a) name, but now Microsoft wants to treat it as a
    category (c) name (ie, _unlink), so they have introduced warnings to try
    to get everyone to use _unlink instead. Of course there's not good
    reason

    Just slightly off the main topic of this thread, there's also the
    situation with all the Visual Studio warning messages telling you that
    all your favorite C/C++ functions are insecure and you should use the
    new and improved Microsoft-provided secure interfaces instead. Just
    because Microsoft apparently couldn't write secure code with the
    existing functions doesn't mean that other people can't. Beyond that
    issue, who made Microsoft the software police anyway? There's just a
    certain arrogance about the whole thing.

    I really wonder how this happened anyway. Did the Visual Studio team
    really not think through the implications of what they were doing when
    they introduced these warning messages? Or did they think it through
    and decide to go ahead anyway? Or is this all the work of one rogue
    programmer who wasn't adequately supervised? Or for you conspiracy
    buffs out there, did they do it to try to push people away from
    standard C++ interfaces and get them to use Microsoft proprietary
    interfaces instead?

    Don't any of the developers from Microsoft C++ hang out in this
    newsgroup? I haven't seen any postings on this thread from anyone with
    @microsoft.com in their e-mail address. If there is a more benign
    explanation for this mess, I'd like to hear it.

    --
    Tom Einertson E-mail: tome@siemens-emis.com
    SIEMENS Power Transmission & Distribution Phone: (952) 607-2244
    Energy Management & Automation Division Fax: (952) 607-2018
    10900 Wayzata Boulevard, Suite 400
    Minnetonka, MN, 55305


    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  15. Re: Visual Studio and ISO C++ Names

    ""Tom Einertson"" wrote in message
    news:SaqdnbpzGsbKZkPenZ2dnUVZ_tudnZ2d@comcast.com. ..

    > Just slightly off the main topic of this thread, there's also the
    > situation with all the Visual Studio warning messages telling you that
    > all your favorite C/C++ functions are insecure and you should use the
    > new and improved Microsoft-provided secure interfaces instead. Just
    > because Microsoft apparently couldn't write secure code with the
    > existing functions doesn't mean that other people can't.


    It's not a question of whether people *can* write secure code, it's
    the likelihood that they *do*. I'm not defending Microsoft's decision
    to inflict their internal standards by default on their compiler
    customers, but I can sympathize with their belief that they might
    be doing the world a service.

    > Beyond that
    > issue, who made Microsoft the software police anyway? There's just a
    > certain arrogance about the whole thing.


    *Every* compiler I use issues warning messages about practices
    that the compiler vendor thinks should be discouraged, even
    though it's conforming code. (Thus the warning instead of an
    outright error.) IMO, that puts *every* compiler vendor in the
    position of playing software police to some extent. It makes
    my particular life miserable because our customers in turn
    treat warnings caused by our code as errors. So we have to cruft
    up our code with casts and circumlocutions to keep the union
    of all possible warnings at bay. And yes, I agree that there's
    a certain arrogance behind warnings turned on by default.

    > I really wonder how this happened anyway. Did the Visual Studio team
    > really not think through the implications of what they were doing when
    > they introduced these warning messages? Or did they think it through
    > and decide to go ahead anyway? Or is this all the work of one rogue
    > programmer who wasn't adequately supervised? Or for you conspiracy
    > buffs out there, did they do it to try to push people away from
    > standard C++ interfaces and get them to use Microsoft proprietary
    > interfaces instead?


    As a close bystander, what I saw was a group of very able and well
    intentioned programmers within Microsoft who got religion about
    security. (And about time too, given the growing popularity of
    attacking Microsoft software over the internet as an indoor sport.)
    They had a long beta release period where they solicited feedback,
    but that feedback kinda resembles what you get from the choir when
    you ask them to evaluate your sermons. I believe that the folks
    at Microsoft were genuinely surprised at the vehemence they met
    from some quarters when they formally released V8. And FWIW, nobody
    asked my opinion about these warnings, or they would have heard it.

    > Don't any of the developers from Microsoft C++ hang out in this
    > newsgroup? I haven't seen any postings on this thread from anyone with
    > @microsoft.com in their e-mail address. If there is a more benign
    > explanation for this mess, I'd like to hear it.


    I find it pretty benign, knowing the principal players on all
    sides of this flap. But I have no expectation that I will
    reduce the endemic paranoia by one iota -- paranoia is its own
    reward.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com


    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  16. Re: Visual Studio and ISO C++ Names

    > a) those defined by the implementation for the benefit of the programmer
    > (such as printf)
    >
    > b) those reserved to the programmer (such as foo)
    >
    > c) those reserved to the implementation (such as _unlink)


    Pardon me for asking and I may be wrong here, but I thought it should be

    b) foo, _unlink

    c) __unlink, _Unlink

    that is, leading single underscores followed by lowercase letter was
    reserved for the programmer and only double underscores and single
    underscore followed by uppercase letter was reserved for the implementation.

    Stephen Howe


    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  17. Re: Visual Studio and ISO C++ Names

    "Tom Einertson" wrote:
    ..
    > Don't any of the developers from Microsoft C++ hang out in this
    > newsgroup? I haven't seen any postings on this thread from anyone with
    > @microsoft.com in their e-mail address. If there is a more benign
    > explanation for this mess, I'd like to hear it.


    I just noticed that this is a cross-posted message. I presume from the
    context that the newsgroup you're referring to is comp.std.c++? I
    should hope that Microsoft developers contribute occasionally to
    comp.os.ms-windows.programmer.misc.

    Rani Sharoni posts on comp.std.c++ occasionally. He uses a hotmail.com
    e-mail address, but his messages all come from news.microsoft.com; it's
    possible that he's a Microsoft developer. However, going back several
    years, he does seem to be the only person posting to comp.std.c++ from
    that server.

    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  18. Re: Visual Studio and ISO C++ Names

    ""Stephen Howe"" wrote in message
    news:43dee0e6$0$27881$cc9e4d1f@news.dial.pipex.com ...

    >> a) those defined by the implementation for the benefit of the programmer
    >> (such as printf)
    >>
    >> b) those reserved to the programmer (such as foo)
    >>
    >> c) those reserved to the implementation (such as _unlink)

    >
    > Pardon me for asking and I may be wrong here, but I thought it should be
    >
    > b) foo, _unlink
    >
    > c) __unlink, _Unlink
    >
    > that is, leading single underscores followed by lowercase letter was
    > reserved for the programmer and only double underscores and single
    > underscore followed by uppercase letter was reserved for the
    > implementation.


    : 17.4.3.1.2 - Global names [lib.global.names]
    :
    : -1- Certain sets of names and function signatures are always
    : reserved to the implementation:
    :
    : Each name that contains a double underscore ("__") or begins
    : with an underscore followed by an uppercase letter (lex.key)
    : is reserved to the implementation for any use.
    :
    : Each name that begins with an underscore is reserved to the
    : implementation for use as a name in the global namespace.*
    :
    : [Footnote: Such names are also reserved in namespace ::std
    : (lib.reserved.names). --- end foonote]

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com


    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  19. Re: Visual Studio and ISO C++ Names

    "Tom Einertson" wrote:
    > I can't find anything, though, that REQUIRES Microsoft to use leading
    > underscores in the names of operating system interfaces. I also notice
    > that they only declared Posix names without leading underscores to be
    > non-conformant. We don't get errors saying that Microsoft Win32 system
    > interfaces such as CreateFile needs to be named _CreateFile in order to
    > be ISO C++ conformant.


    This is an interesting point, and it's more to it: The new secure
    functions found in VS2005 (strcpy_s, sprintf_s and such) should also
    the "_" prefix (_strcpy_s, _sprintf_s and so on) as they only exist on
    that single implementation.

    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


  20. Re: Visual Studio and ISO C++ Names

    > I just noticed that this is a cross-posted message. I presume from the
    > context that the newsgroup you're referring to is comp.std.c++? I
    > should hope that Microsoft developers contribute occasionally to
    > comp.os.ms-windows.programmer.misc.


    I have noticed that Microsoft developers do respond to messages in the
    microsoft.public.vc.* newgroups on their own newserver, particularly if a
    customer reports a bug (and the customer is correct) with the C++ compiler,
    other tools or libraries.

    Stephen Howe


    ---
    [ comp.std.c++ is moderated. To submit articles, try just posting with ]
    [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]


+ Reply to Thread
Page 1 of 2 1 2 LastLast