Visual Studio and ISO C++ Names
Tom Einertson
(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: to...@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...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
P.J. Plauger
news:YMqdnenWtqO...@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
Dilip
"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.lang.c++.moderated/msg/aeaf2aac72aa1312
Not sure if its the same thing though.
Jerry Coffin
[ ... ]
> 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.
Tom Einertson
news:tq2dnc2pUad...@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: to...@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
---
Guy Harrison
> 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.
Rob Williscroft
@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 <cstdio>
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/
dev...@octopull.demon.co.uk
"P.J. Plauger" wrote:
> ""Tom Einertson"" <to...@siemens-emis.com> wrote in message
> news:YMqdnenWtqO...@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
Tom Einertson
news:Xns975A7BE66BEDDrt...@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: to...@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
>
P.J. Plauger
news:1138546549.7...@o13g2000cwo.googlegroups.com...
> "P.J. Plauger" wrote:
>
>> ""Tom Einertson"" <to...@siemens-emis.com> wrote in message
>> news:YMqdnenWtqO...@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
Chris Hills
<to...@siemens-emis.com> 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/editorial/OverloadEditorial200601.pdf
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills
Jerry Coffin <jerry....@gmail.com> 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 /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
---
Chris Hills
<to...@siemens-emis.com> 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 /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
---
Tom Einertson
> <dev...@octopull.demon.co.uk> wrote in message
> news:1138546549.7...@o13g2000cwo.googlegroups.com...
>
>> "P.J. Plauger" wrote:
>>
>>> ""Tom Einertson"" <to...@siemens-emis.com> wrote in message
>>> news:YMqdnenWtqO...@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: to...@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
P.J. Plauger
> 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
Stephen Howe
> (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
kuy...@wizard.net
.
> 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.
P.J. Plauger
news:43dee0e6$0$27881$cc9e...@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
Anders Dalvander
> 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.
Stephen Howe
> 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
Tom Einertson
> ""Tom Einertson"" <to...@siemens-emis.com> wrote in message
> news:SaqdnbpzGsbKZkPe...@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: to...@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
---
Chris Hills
<to...@siemens-emis.com> writes
>"P.J. Plauger" <p...@dinkumware.com> wrote in message
>news:sPGdncLTh6ZzGkLe...@giganews.com...
>> ""Tom Einertson"" <to...@siemens-emis.com> wrote in message
>> news:SaqdnbpzGsbKZkPe...@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 /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
---
Krzysztof Żelechowski
Użytkownik ""Tom Einertson"" <to...@siemens-emis.com> napisał w wiadomości
news:iNGdnTGii-5...@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