www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Buglet: extern (Windows) even on linux?

reply Andy Friesen <andy ikagames.com> writes:
The linux version of DMD will blithely allow you to declare functions as 
being extern (Windows), even though this isn't very useful.  Should it? 
(maybe this is convenient when cross-compiling or something)

  -- andy
May 03 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:c779ec$1p8i$1 digitaldaemon.com...
 The linux version of DMD will blithely allow you to declare functions as
 being extern (Windows), even though this isn't very useful.  Should it?
 (maybe this is convenient when cross-compiling or something)
It might come in handy when writing portable code.
May 04 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
if we can count on extern(Windows) to work on linux
why not call it
extern(PlatformDLL)
or just
extern(dll)
then the platform can choose the calling convention it pleases for 
loading a standard dynamic lib
in linux that would be .so--in windows that would be .dll
on mac it would by .dylib

that way we wouldn't need to paste the header thrice for 3 platforms (n 
times for n platforms) or need more powerful version() stuff

under linux leaving extern(Windows) undefined in the spec is a recipe 
for disaster though--it's a bug thats going to have to be supported for 
a long, long time.

Another benefit: sometimes linux programs want to load .dll's (like 
mplayer loads dll's )  then we could use extern(Windows) to specify the 
WINDOWS calling convention, instead of leaving it at the linux one

Walter wrote:

 "Andy Friesen" <andy ikagames.com> wrote in message
 news:c779ec$1p8i$1 digitaldaemon.com...
 
The linux version of DMD will blithely allow you to declare functions as
being extern (Windows), even though this isn't very useful.  Should it?
(maybe this is convenient when cross-compiling or something)
It might come in handy when writing portable code.
May 04 2004
parent reply "Walter" <newshound digitalmars.com> writes:
It's a good idea, but a couple problems with it are:
1) in Win32, you can have C functions exported from DLL's, too.
extern(Windows) is not a dll specific thing, it is specific to Microsoft API
conventions.
2) if you use inline asm, that depends on the calling conventions, having
extern(Windows) mean a different calling convention on different platforms
will muck it up.

"Daniel Horn" <hellcatv hotmail.com> wrote in message
news:c79dmh$1vv6$1 digitaldaemon.com...
 if we can count on extern(Windows) to work on linux
 why not call it
 extern(PlatformDLL)
 or just
 extern(dll)
 then the platform can choose the calling convention it pleases for
 loading a standard dynamic lib
 in linux that would be .so--in windows that would be .dll
 on mac it would by .dylib

 that way we wouldn't need to paste the header thrice for 3 platforms (n
 times for n platforms) or need more powerful version() stuff

 under linux leaving extern(Windows) undefined in the spec is a recipe
 for disaster though--it's a bug thats going to have to be supported for
 a long, long time.

 Another benefit: sometimes linux programs want to load .dll's (like
 mplayer loads dll's )  then we could use extern(Windows) to specify the
 WINDOWS calling convention, instead of leaving it at the linux one

 Walter wrote:

 "Andy Friesen" <andy ikagames.com> wrote in message
 news:c779ec$1p8i$1 digitaldaemon.com...

The linux version of DMD will blithely allow you to declare functions as
being extern (Windows), even though this isn't very useful.  Should it?
(maybe this is convenient when cross-compiling or something)
It might come in handy when writing portable code.
May 05 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
this is why I proposed a different keyword that would do the platform 
default
extern(PlatformDll)
extern(C) would take care of the things that are C for all platforms

It's important to make importing C headers as easy as possible
Having to paste the gl.h 3 times, one for win, mac and linux is just 
unacceptible. What about SGI, BSD, ... ... it's unmanagable

The other option is to increase the power of version to let you specify 
different calling conventions for a function depending on the platform.

I think improving version to deal with this simple case is important for 
porting headers over :-)
--Daniel

Walter wrote:
 It's a good idea, but a couple problems with it are:
 1) in Win32, you can have C functions exported from DLL's, too.
 extern(Windows) is not a dll specific thing, it is specific to Microsoft API
 conventions.
 2) if you use inline asm, that depends on the calling conventions, having
 extern(Windows) mean a different calling convention on different platforms
 will muck it up.
 
 "Daniel Horn" <hellcatv hotmail.com> wrote in message
 news:c79dmh$1vv6$1 digitaldaemon.com...
 
if we can count on extern(Windows) to work on linux
why not call it
extern(PlatformDLL)
or just
extern(dll)
then the platform can choose the calling convention it pleases for
loading a standard dynamic lib
in linux that would be .so--in windows that would be .dll
on mac it would by .dylib

that way we wouldn't need to paste the header thrice for 3 platforms (n
times for n platforms) or need more powerful version() stuff

under linux leaving extern(Windows) undefined in the spec is a recipe
for disaster though--it's a bug thats going to have to be supported for
a long, long time.

Another benefit: sometimes linux programs want to load .dll's (like
mplayer loads dll's )  then we could use extern(Windows) to specify the
WINDOWS calling convention, instead of leaving it at the linux one

Walter wrote:


"Andy Friesen" <andy ikagames.com> wrote in message
news:c779ec$1p8i$1 digitaldaemon.com...


The linux version of DMD will blithely allow you to declare functions as
being extern (Windows), even though this isn't very useful.  Should it?
(maybe this is convenient when cross-compiling or something)
It might come in handy when writing portable code.
May 05 2004
parent "Walter" <newshound digitalmars.com> writes:
The problem (as I see it) is that gl.h, for some inexplicable reason, chose
to use different calling conventions on different platforms, rather than the
C calling convention. Also, there is no standard dll calling convention
(even on Windows). And (correct me if I'm wrong) there are no calling
conventions (dll or otherwise) on other platforms other than the C calling
conventions.

"Daniel Horn" <hellcatv hotmail.com> wrote in message
news:c7bi3v$290g$1 digitaldaemon.com...
 this is why I proposed a different keyword that would do the platform
 default
 extern(PlatformDll)
 extern(C) would take care of the things that are C for all platforms

 It's important to make importing C headers as easy as possible
 Having to paste the gl.h 3 times, one for win, mac and linux is just
 unacceptible. What about SGI, BSD, ... ... it's unmanagable

 The other option is to increase the power of version to let you specify
 different calling conventions for a function depending on the platform.

 I think improving version to deal with this simple case is important for
 porting headers over :-)
 --Daniel

 Walter wrote:
 It's a good idea, but a couple problems with it are:
 1) in Win32, you can have C functions exported from DLL's, too.
 extern(Windows) is not a dll specific thing, it is specific to Microsoft
API
 conventions.
 2) if you use inline asm, that depends on the calling conventions,
having
 extern(Windows) mean a different calling convention on different
platforms
 will muck it up.

 "Daniel Horn" <hellcatv hotmail.com> wrote in message
 news:c79dmh$1vv6$1 digitaldaemon.com...

if we can count on extern(Windows) to work on linux
why not call it
extern(PlatformDLL)
or just
extern(dll)
then the platform can choose the calling convention it pleases for
loading a standard dynamic lib
in linux that would be .so--in windows that would be .dll
on mac it would by .dylib

that way we wouldn't need to paste the header thrice for 3 platforms (n
times for n platforms) or need more powerful version() stuff

under linux leaving extern(Windows) undefined in the spec is a recipe
for disaster though--it's a bug thats going to have to be supported for
a long, long time.

Another benefit: sometimes linux programs want to load .dll's (like
mplayer loads dll's )  then we could use extern(Windows) to specify the
WINDOWS calling convention, instead of leaving it at the linux one

Walter wrote:


"Andy Friesen" <andy ikagames.com> wrote in message
news:c779ec$1p8i$1 digitaldaemon.com...


The linux version of DMD will blithely allow you to declare functions
as
being extern (Windows), even though this isn't very useful.  Should
it?
(maybe this is convenient when cross-compiling or something)
It might come in handy when writing portable code.
May 10 2004