Visual Studio and ISO C++ Names - Programmer

This is a discussion on Visual Studio and ISO C++ Names - Programmer ; "P.J. Plauger" wrote in message news:sPGdncLTh6ZzGkLenZ2dnUVZ_tydnZ2d@giganews.com ... > ""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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: Visual Studio and ISO C++ Names

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

    "P.J. Plauger" wrote in message
    news:sPGdncLTh6ZzGkLenZ2dnUVZ_tydnZ2d@giganews.com ...
    > ""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.


    OK. I agree that it is good that Microsoft is finally taking security
    seriously. I just wish they would exercise good judgement in the
    process. Not every call to strcpy is a potential security threat.
    There's a world of difference between copying a parameter passed in on
    a command line or data received on a socket vs copying data in a
    program which doesn't receive data directly from the outside world. A
    buffer overflow caused by data passed in from the outside represents a
    very real security threat, but a buffer overflow in a program which has
    no external interface is much less of a danger.

    I'm also worried that this is the next Microsoft programming fad that
    they'll try to push everyone to use. Remember when COM and DCOM were
    the wave of the future, and how they're hardly ever mentioned any
    more? Remember MFC and ATL? Remember everything .net? Remember when
    you could barely run notepad without it asking you if you wanted to
    create a Passport account?

    In two years I'll bet Microsoft will be telling us that even their new
    'secure' copy functions aren't good enough, and we should all be using
    another proprietary Microsoft programming language instead. (And I'll
    bet it won't be C#. That will be passe by then, too.)

    And finally there's the issue of telling people to replace standard
    C/C++ functions with Microsoft proprietary extensions and then wording
    it in such a way as to make you think that these changes are actually
    part of the C/C++ standard. I know Microsoft has submitted these
    functions to be included as part of the C/C++ standard, but they aren't
    part of the standard yet. (And may never be.)

    --
    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

    In article , Tom Einertson
    writes
    >"P.J. Plauger" wrote in message
    >news:sPGdncLTh6ZzGkLenZ2dnUVZ_tydnZ2d@giganews.com ...
    >> ""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.

    >
    >OK. I agree that it is good that Microsoft is finally taking security
    >seriously.


    I think the Jury is still out on that one.

    >And finally there's the issue of telling people to replace standard
    >C/C++ functions with Microsoft proprietary extensions and then wording
    >it in such a way as to make you think that these changes are actually
    >part of the C/C++ standard.


    That's marketing for you. However it does not do MS any favours in the
    non-windows world. It may surprise PC developers to know that x86 and
    windows computers are in the minority.

    > I know Microsoft has submitted these
    >functions to be included as part of the C/C++ standard,


    Actually they haven't They are a Technical Report. NOT part of the
    standard. They have not been submitted to be part of the standard AFAIK.
    There are lots of Technical Reports on things that never get into the
    standard. Actually putting things in a TR is one way of keeping things
    out of the standard :-)

    > but they aren't
    >part of the standard yet. (And may never be.)


    Since most of it is vendor specific they are not likely to be part of
    the standard. Not everyone programs on an x86 platform let alone
    Windows.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ 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 ]


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


    Użytkownik ""Tom Einertson"" napisał w wiadomości
    news:iNGdnTGii-5GpUDeRVn-qA@comcast.com...

    > 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.
    >


    I do not like the word "prototype" here, it means a declaration with
    argument types in C language. Whether the declaration contains argument
    types or not is irrelevant here. It is called a declaration in C++ talk
    because C++ requires argument type declarations anyway, whereas a prototype
    would be a template implementation.

    >> 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.
    >


    If you want to go POSIX, #define _POSIX_ and you are done, except that you
    will have to link against OLDNAMES.LIB, which means you will have to install
    static runtime libraries.

    Chris


    ---
    [ 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 2 of 2 FirstFirst 1 2