The Player Project

> Unfortunately, to make my header file work properly, there must be added a 
> test for sys/types.h in autoconf scripts. It relays on HAVE_SYS_TYPES_H 
> definition.
>
Gosh, right after I've post the message, I've realised that MinGW (and 
other systems) provides sys/types.h header, unfortunately different than 
the Linux one: there's no uint/uchar/ushort definitions in it (and 
anywhere else in MinGW). There must be other way for checking if they're 
available, or better, let's remove all occurences of them in Player and 
Stage code!

Cheers,
Paul

What's the point of coming up with a new set of typedefs?

inttypes.h/stdint.h is a part of C99 (although admittedly not a part of the 
current C++ standard, I *think* it will be part of C++0x). Furthermore, 
uint32_t is shorter to type than psg_uint32 and it's already a wide-spread 
way of solving the problem at hand.

I usually follow the advice found in the Autoconf manual:

"inttypes.h vs. stdint.h
    The C99 standard says that inttypes.h includes stdint.h, so there's no 
need to include stdint.h separately in a standard environment. Some 
implementations have inttypes.h but not stdint.h (e.g., Solaris 7), but we 
don't know of any implementation that has stdint.h but not inttypes.h. "

And should that fail (works on mingw/msys, OS X and Linux at the very least) 
I'd resort to asking the user to manually typedef *_t in config.h.


SDL/SDL_net seems like a pretty nasty dependency, or maybe just unnecessary.
Unless Player is using any esoteric socket functions, sockets work almost the 
same on Windows as they do on unices. Usually, you can easily get socket code 
to compile and run on both Windows and UNIX if you're careful.

/Staffan

On Wednesday 24 October 2007 14:09:32 Paul Osmialowski wrote:
> Hi devels!
> Please forgive me I'm attaching a file again, this time it is a new
> feature rather than a patch so I see no point to put it on a tracker.
>
> Some time ago I was trying to do a very first step for making Player
> highly portable software. I was trying to compile some parts of it on
> MinGW (I've replaced some pieces of code, for example BSD-socket function
> calls with SDL_net function calls, Sun XDR function calls with my own
> implementation of XDR based on glibc code, slightly depending on SDL
> macros). The result was playerlibsdl - a set of libraries required to
> build client-side applications natively on every system that have
> SDL/SDL_net library (all UNIXes including QNX, BeOS, Windows and so on).
>
> One of the most anoying issues was the way integer types was called by
> different programmers. MinGW (and probably other non-UNIX systems) does
> not support ALL naming conventions. I've realised that the names were
> taken from:
> - C Standard (which is good) (unsigned int)
> - stdint.h (which is not that bad) (uint32_t)
> - sys/types.h (which is totally bad) (uint)
> - glib.h (fortunately only in glib/gtk/libgnomecanvas/xmms/-related code,
> which is not that bad or even reasonable) (guint/guint32)
>
> My proposal is to use only one naming convention: all integer types
> prefixed with psg_:
> psg_int
> psg_uint
> psg_int8
> psg_uint8
> psg_int16
> psg_uint16
> psg_int32
> psg_uint32
> psg_int64
> psg_uint64
> psg_ptr (which means void *)
>
> I've prepared header file which should be included by
> libplayercore/player.h which I expect is included by all other Player
> includes (I've checked libplayerc/playerc.h, and indeed it includes
> player.h).
>
> I'm realistic, I know there's a lot of code that should be reworked with
> that fashion, that's why at the end of my player_ints.h I've added so
> called 'compatibility tricks'. Depending on what includes are in use they
> add missing type definitions used in Player and Stage code, so for example
> MinGW gcc will not yeld for them anymore.
>
> Unfortunately, to make my header file work properly, there must be added a
> test for sys/types.h in autoconf scripts. It relays on HAVE_SYS_TYPES_H
> definition.
>
> Cheers,
> Paul

On Wed, 24 Oct 2007, Staffan Gimker wrote:

> What's the point of coming up with a new set of typedefs?
>
> inttypes.h/stdint.h is a part of C99 (although admittedly not a part of the
> current C++ standard, I *think* it will be part of C++0x). Furthermore,
> uint32_t is shorter to type than psg_uint32 and it's already a wide-spread
> way of solving the problem at hand.
>
The point is that there are parts of Player (and Stage) code that aren't 
using C standard nor stdint.h standard for naming integer types. The worst 
case is when sys/types.h naming is in use (and there are many places in 
Player code for that). My header wasn't only for adding new naming 
convention. It later uses this new typedefs to define typedefs that may be 
missing if there's no stdint.h available or there's no uint/uchar/ushort 
in sys/types.h. It means, when it is included, there's no need to make any 
changes in Player and Stage code to make them int-portable.
>
> SDL/SDL_net seems like a pretty nasty dependency, or maybe just unnecessary.
I don't want to make SDL/SDL_net a hard dependency. I can't imagine 
to link with libsdl Player binary supposed to work on embedded system. As 
I proposed months ago, usage of SDL/SDL_net should be an optional 
dependency for those who plan to use Player on Windows (as native binary) 
or other exotic systems like that. For them, it would be a solution for 
things like:
- threads (iff SDL thread model is enough)
- networking
- int typing
- shared object loading (plugins, i.e. Stage)
- some hardware access (sound, joystick)
I know that it's not much, all other hardware drivers won't built on 
exotic systems, but sometimes their users just want to run Stage 
simulation or use passthrough driver.
I'm planning to write OpenCV-based camera driver for all the systems that 
have OpenCV library (it can cooperate with both v4l and VideoForWindows). 
As long as there's no highly portable Player distribution, I see no 
reason for starting this project.
> Unless Player is using any esoteric socket functions, sockets work almost the
> same on Windows as they do on unices.
As we say it in Poland: 'almost' makes the real difference.

> Usually, you can easily get socket code
> to compile and run on both Windows and UNIX if you're careful.
Yup, and I can do that different ways. Use of SDL_net is one of the 
easiest.
Paul

> On Wednesday 24 October 2007 14:09:32 Paul Osmialowski wrote:
>> Hi devels!
>> Please forgive me I'm attaching a file again, this time it is a new
>> feature rather than a patch so I see no point to put it on a tracker.
>>
>> Some time ago I was trying to do a very first step for making Player
>> highly portable software. I was trying to compile some parts of it on
>> MinGW (I've replaced some pieces of code, for example BSD-socket function
>> calls with SDL_net function calls, Sun XDR function calls with my own
>> implementation of XDR based on glibc code, slightly depending on SDL
>> macros). The result was playerlibsdl - a set of libraries required to
>> build client-side applications natively on every system that have
>> SDL/SDL_net library (all UNIXes including QNX, BeOS, Windows and so on).
>>
>> One of the most anoying issues was the way integer types was called by
>> different programmers. MinGW (and probably other non-UNIX systems) does
>> not support ALL naming conventions. I've realised that the names were
>> taken from:
>> - C Standard (which is good) (unsigned int)
>> - stdint.h (which is not that bad) (uint32_t)
>> - sys/types.h (which is totally bad) (uint)
>> - glib.h (fortunately only in glib/gtk/libgnomecanvas/xmms/-related code,
>> which is not that bad or even reasonable) (guint/guint32)
>>
>> My proposal is to use only one naming convention: all integer types
>> prefixed with psg_:
>> psg_int
>> psg_uint
>> psg_int8
>> psg_uint8
>> psg_int16
>> psg_uint16
>> psg_int32
>> psg_uint32
>> psg_int64
>> psg_uint64
>> psg_ptr (which means void *)
>>
>> I've prepared header file which should be included by
>> libplayercore/player.h which I expect is included by all other Player
>> includes (I've checked libplayerc/playerc.h, and indeed it includes
>> player.h).
>>
>> I'm realistic, I know there's a lot of code that should be reworked with
>> that fashion, that's why at the end of my player_ints.h I've added so
>> called 'compatibility tricks'. Depending on what includes are in use they
>> add missing type definitions used in Player and Stage code, so for example
>> MinGW gcc will not yeld for them anymore.
>>
>> Unfortunately, to make my header file work properly, there must be added a
>> test for sys/types.h in autoconf scripts. It relays on HAVE_SYS_TYPES_H
>> definition.
>>
>> Cheers,
>> Paul
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

On Oct 24, 2007, at 5:09 AM, Paul Osmialowski wrote:

>
> One of the most anoying issues was the way integer types was called  
> by different programmers. MinGW (and probably other non-UNIX  
> systems) does not support ALL naming conventions. I've realised  
> that the names were taken from:
> - C Standard (which is good) (unsigned int)
> - stdint.h (which is not that bad) (uint32_t)
> - sys/types.h (which is totally bad) (uint)
> - glib.h (fortunately only in glib/gtk/libgnomecanvas/xmms/-related  
> code, which is not that bad or even reasonable) (guint/guint32)

Would the portability issues go away if we replace all usage of <sys/ 
types.h> types (e.g., uint) with either C99 types (e.g., uint32_t) or  
C types (e.g., unsigned int)?

	brian.

> Would the portability issues go away if we replace all usage of <sys/
> types.h> types (e.g., uint) with either C99 types (e.g., uint32_t) or
> C types (e.g., unsigned int)?
>
> 	brian.
>
Sure, I guess it would be the step into the right direction and it would 
terminate the "int type madness" topic.
Paul

On Wednesday 24 October 2007 16:58:35 Paul Osmialowski wrote:
> On Wed, 24 Oct 2007, Staffan Gimker wrote:
> > What's the point of coming up with a new set of typedefs?
> >
> > inttypes.h/stdint.h is a part of C99 (although admittedly not a part of
> > the current C++ standard, I *think* it will be part of C++0x).
> > Furthermore, uint32_t is shorter to type than psg_uint32 and it's already
> > a wide-spread way of solving the problem at hand.
>
> The point is that there are parts of Player (and Stage) code that aren't
> using C standard nor stdint.h standard for naming integer types. 

Don't get me wrong, I'm all for making it portable - I'm just questioning the 
need to introduce more "non-standard" typedefs.

IMO, the proper fix for that is to change those occurrences to be portable - 
i.e. uintX_t. sed is your friend :)

> The worst 
> case is when sys/types.h naming is in use (and there are many places in
> Player code for that). My header wasn't only for adding new naming
> convention. It later uses this new typedefs to define typedefs that may be
> missing if there's no stdint.h available or there's no uint/uchar/ushort
> in sys/types.h.

Again, inttypes.h (as well as stdint.h) are parts of the current C standard 
(C99). Since it's been ~8 years since the standard was adopted, it should be 
just about universally available. Thus, I don't see the need to add another 
set of typedefs.

Have you encountered any platforms/compilers where inttypes.h is not 
available?

It should cover at least 99% of the cases, and for that remaining percent 
manual intervention can solve the problem.

(On a side note, intX_t types are optional according to C99, but required if 
the implementation provides a non-padded type of exactly width X. 
int_leastX_t are the only "truly portable" typedefs.)

Anyway, it's not my decision to make so I'll hold my peace.

/Staffan

You can check whether a type exists using autoconf. Either using it's macros for 
checking for types, or including a short test program it runs.

(Also, MinGW has a winsock lib and that overaps more or less with Unix/BSD sockets.)

Reed

Paul Osmialowski wrote:
> Gosh, right after I've post the message, I've realised that MinGW (and 
> other systems) provides sys/types.h header, unfortunately different than 
> the Linux one: there's no uint/uchar/ushort definitions in it (and 

unsigned int
unsigned char
unsigned short

?

On Wed, 24 Oct 2007, Reed Hedges wrote:

> Paul Osmialowski wrote:
>> Gosh, right after I've post the message, I've realised that MinGW (and
>> other systems) provides sys/types.h header, unfortunately different than
>> the Linux one: there's no uint/uchar/ushort definitions in it (and
>
> unsigned int
> unsigned char
> unsigned short
>
> ?
nope, see in Linux's sys/types.h:
uint
ushort
uchar
Player code uses uint from sys/types.h

>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

> (Also, MinGW has a winsock lib and that overaps more or less with Unix/BSD sockets.)
> Reed
I know that winsock (also provided by MinGW) provides the same 
functionality as BSD sockets, my point is that source code that uses BSD 
sockets will not compile on systems that have Winsock and vice versa. Code 
using SDL_net will compile without a single change on both.
Paul

I have replaced all instances of uint with uint32_t in player, hopefully
this will aid in portability. Let me know if their are any issues arising
from this.
Toby

On 25/10/2007, Paul Osmialowski <newchief@...> wrote:
>
>
>
> > (Also, MinGW has a winsock lib and that overaps more or less with
> Unix/BSD sockets.)
> > Reed
> I know that winsock (also provided by MinGW) provides the same
> functionality as BSD sockets, my point is that source code that uses BSD
> sockets will not compile on systems that have Winsock and vice versa. Code
> using SDL_net will compile without a single change on both.
> Paul
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>



-- 
This email is intended for the addressee only and may contain privileged
and/or confidential information