Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

COMMENT macro is defined in os2.h, it is danger to use it in ckwin code #382

Open
jmalak opened this issue Oct 27, 2024 · 4 comments
Open

Comments

@jmalak
Copy link
Contributor

jmalak commented Oct 27, 2024

use of COMMENT macro in ckwin code is very danger because it is defined in os2.h header file.
It doesn't report any message if it is used incorrectly with os2.h.
only in code is this macro undefined after including os2.h, but not everywhere.

I think it can be source of some issues for OS/2.

I think it should be renamed to something like CKCOMMENT or replaced by #if 0 (transparent solution).

@jmalak jmalak changed the title COMMENT macro is defined in os2.h, it is danger to use in ckwin code COMMENT macro is defined in os2.h, it is danger to use it in ckwin code Oct 27, 2024
@davidrg
Copy link
Owner

davidrg commented Oct 27, 2024

Yeah, its been an issue for as long as the OS/2 port has existed. Everywhere os2.h is included, it should be followed by an #undef COMMENT, though I noticed a few places where that wasn't the case (now fixed).

The issues on OS/2 have so far all just been bugs in Open Watcom; there is a list of the bugs encountered in #369 - not sure at this stage if they're only in Open Watcom 1.9, or if they affect Open Watcom 2.0 as well

@jmalak
Copy link
Contributor Author

jmalak commented Oct 27, 2024

I don't thing it is OW bugs, it is rather ckwin code implementation issues, by example calling conventions problems.
Generaly there is always two calling convention.
first for OS calls and second is user defined (default is Watcom registers calling convention, not cdecl).
If code is based on microsoft compilers then default calling convention is cdecl.
Also use of calling conventions as _System in ckwin code is wrong way.
Typically _System calling convention is override by macros _System than _System calling convention cannot be used until _System macro is undefined. I submit PR "fix issue with status_func which was unportable #386" which use properly macros CKDEVDLL and CKDEVAPI which define calling convention and don't mask _System calling convention which must be always available but it isn't. CKDEVDLL define calling convention of DLL entries and CKDEVAPI define calling convention of user functions in DLL (pointers) not exported from DLL. Both can be changed as needed, but don't affect _System calling convention which is used by system calls. Existing code destroy _System calling convention that any next system calls are incorrect.

Any code which define _System macro must be removed, see example below from ckossh.h

#ifdef NT
#ifndef _System
#define _System
#endif /* _System */
#endif /* NT */

or in p.h

#ifdef __EMX__
#define _System                 /* EMX/GCC doesn't have _System */
#endif
#ifdef NT
#define _System         /* Neither does Win32 */
#define _Inline __inline
#define APIRET DWORD
#else
#ifdef __WATCOMC__
#define _Inline inline
#endif /* __WATCOMC__ */
#endif /* NT */

below is proper use of calling conventions in ckotcp.h, there are defined SYSTEM and ENTRY macros and this is used.
It doesn't touch any calling convention definition.

#ifdef CK_DLL
  #ifdef __32BIT__
  #define ENTRY _System _Export
  #else
  #define ENTRY _export _loadds
  #endif
#else
  #ifdef __32BIT__
  #  ifdef __WATCOMC__
  #    define ENTRY _System
  #    define SYSTEM
  #  else /* __IBMC__ */
  #    define SYSTEM _System
  #  endif /* if __WATCOMC__ */
  #else
  #define SYSTEM
  #endif

EXTERN int ENTRY ck_sockinit(void);
EXTERN int ENTRY ck_connect(int socket, struct ck_sockaddr *name, int namelen);

@davidrg
Copy link
Owner

davidrg commented Oct 27, 2024

I don't thing it is OW bugs, it is rather ckwin code implementation issues, by example calling conventions problems.

yeah, the calling convention stuff isn't bugs Open Watcom, but earlier some actual compiler and/or runtime bugs (listed in #369) were encountered which mostly caused crashes in various places, in particular in the NetBIOS code which is a mix of 16bit and 32bit stuff. MichalN has found workarounds for most of them (including #368, he is just tidying up his solution for it at the moment), though aside from #368 I've no idea if they affect Open Watcom 2.0 or not.

@jmalak
Copy link
Contributor Author

jmalak commented Oct 27, 2024

OW 2.0 is backward compatible with OW 1.9 that OW1.9 code should be compiled by OW 2.0, but has fixed some OW 1.9 bugs
OW 2.0 has much better C99 support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants