Menu
▾
▴
uglycode-coders — UM1 Coders
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(22) |
Dec
(53) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(56) |
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: J.P. K. <jp...@he...> - 2001-12-13 12:50:07
|
> void f (char *s); > const char *cs; > f(s); // Should fail > f(const_cast<char *>(cs)); // Should succeed, I think Tested, not really understood, but implemented cos it blatantly works. Changes committed. > - Peter Julian |
|
From: Peter C. <pet...@ne...> - 2001-12-13 12:37:53
|
> From: J.P. King [mailto:jp...@he...] > > Can you not fix the calls (that do not change their string) using > > const_cast? > > Probably - however that appears to be a C++ extension, and I don't > know any C++. However I am reading what documentation I can > find to work out if we can use it, and how to use it if we can. void f (char *s); const char *cs; f(s); // Should fail f(const_cast<char *>(cs)); // Should succeed, I think - Peter |
|
From: J.P. K. <jp...@he...> - 2001-12-13 12:34:19
|
> > The const casts I dealt with by introducing a new variable > > char *tmpstring > > and using strcpy to copy a const char * (or quoted string) into > > tmpstring, and then used that. > > Ick! Yup. > Can you not fix the calls (that do not change their string) using > const_cast? Probably - however that appears to be a C++ extension, and I don't know any C++. However I am reading what documentation I can find to work out if we can use it, and how to use it if we can. Julian |
|
From: Peter C. <pet...@ne...> - 2001-12-13 12:12:21
|
> From: J.P. King [mailto:jp...@he...] > The const casts I dealt with by introducing a new variable > char *tmpstring > and using strcpy to copy a const char * (or quoted string) into > tmpstring, and then used that. Ick! Can you not fix the calls (that do not change their string) using const_cast? |
|
From: J.P. K. <jp...@he...> - 2001-12-13 12:11:35
|
> 1. Why is @channel boot and status disabled in the softcode? I _thought_ that there was a problem which caused the game to crash, and that this was a command which was known to cause the crashing. Ask on the main uglymug alias and hopefully someone should be able to confirm that. > Adrian. Julian |
|
From: J.P. K. <jp...@he...> - 2001-12-13 12:09:40
|
> > We now have no warnings under any of Solaris, Linux and FreeBSD. :-) > Good grief! How did you get rid of the const casts and the regexp stuff? The regexp stuff wasn't done in the recent round of fixes - I am not even sure that it was me that dealt with that. The const casts I dealt with by introducing a new variable char *tmpstring and using strcpy to copy a const char * (or quoted string) into tmpstring, and then used that. It is undoubtedly inefficient, but it avoids having to fix curses, which I view as a good thing. :-) > - Peter Julian |
|
From: Peter C. <pet...@ne...> - 2001-12-13 12:02:02
|
> From: Adrian St. John [mailto:AS...@pa...] > 2. Does anyone mind if NPCs can use chat channels? That way we can > have 'permenant' channels with an NPC operator. The NPCs might > have to have a special flag set on them for them to use channels. Hey, cool, I can write a spam-bot to spam all the channels. I'll call it... naah, that would be telling. - Peter |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-13 11:58:42
|
Ok, after a bit of work, I've cleaned up the chat code a bit. NOTE: This has not been extensively tested. It may crash. There is a test game up (full db) for you to use. However, I have a couple of comments. 1. Why is @channel boot and status disabled in the softcode? 2. Does anyone mind if NPCs can use chat channels? That way we can have 'permenant' channels with an NPC operator. The NPCs might have to have a special flag set on them for them to use channels. Adrian. -- Adrian St. John Software Engineer Pan Security International Ltd. T 0121 780 0619 as...@pa... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Pan Security International Limited, Vienna House, International Square, = Birmingham International Park, Bickenhill Lane, Solihull B37 7GN United = Kingdom. Registered company number 3965174=20 This message may contain information which is confidential and subject = to legal privilege. If you are not the intended recipient, you may not = peruse, use, disseminate, distribute or copy this message. If you have = received this message in error, please notify the sender immediately by = e-mail, facsimile or telephone and return and/or destroy the original = message. Pan Security International Limited accept no responsibility for = any changes made to this message after it has been sent by the original = author. |
|
From: Peter C. <pet...@ne...> - 2001-12-13 11:10:54
|
> From: J.P. King [mailto:jp...@he...] > We now have no warnings under any of Solaris, Linux and FreeBSD. :-) Good grief! How did you get rid of the const casts and the regexp stuff? - Peter |
|
From: J.P. K. <jp...@he...> - 2001-12-13 11:04:26
|
We now have no warnings under any of Solaris, Linux and FreeBSD. :-) Now I'll start working on moving the OS dependant stuff out of the main code and into an external file - however this may take some time. However, if you write code and you get warnings you now don't have the excuse that it was lost in the noise of all the other warnings. Julian ... Ok, this will be the case once I have a route to sourceforge again and can commit this code. |
|
From: J.P. K. <jp...@he...> - 2001-12-12 11:03:55
|
> There probably isn't. But good luck, as Sun's compiler suite is > suitably different from g++. > Oh hang on, yes there is a lint with it, but it (at least 4 years ago) > doesn't handle C++. Yes, there is a lint, it appears to handle C++ style comments, and not a lot more. > > I could probably install it on something, but that would be... > > what is the word I am looking for? Oh yes, 'illegal'. >:-> > > You can get hold of temporary 1 month licence if you're that bothered. Yeah, but I have a site licence here - it would only be useful for people wanting to develop the code on there properly. I have been having a quick play and it doesn't like the code at all. Lots of wonderful warnings, and errors. > Whoever is responsible for termcap/terminfo. Unfortunately that would > mean shooting the author of one of my favourite games, rogue, as > curses/termcap evolved out of that. Actually termcap isn't _that_ bad, I meant curses, which is pretty dire. > Adrian. Julian |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-12 10:35:51
|
> From: J.P. King [mailto:jp...@he...] >=20 > > __lint is for when you use 'lint', the C program fluff finder. > > I presume it is there specifically to avoid the=20 > double-defines, as lint > > will complain loudly about them. > >=20 > > When I get a chance, I'll run the source through lint here=20 > (I have one > > that deals with C++), and then let other people fix all the=20 > warnings... >=20 > Heh - want me to run the code through Sun's compiler suite? :-) > I don't know if there is a lint included there, although I can try it. There probably isn't. But good luck, as Sun's compiler suite is suitably different from g++. Oh hang on, yes there is a lint with it, but it (at least 4 years ago) doesn't handle C++. > I could probably install it on something, but that would be... > what is the word I am looking for? Oh yes, 'illegal'. >:-> You can get hold of temporary 1 month licence if you're that bothered. > > Ah, that one. My personal preference would be to take the programmer > > who wrote those functions out to a wall and shoot them. >=20 > The 'Ugly' functions or just whoever is responsible for=20 > termcap/terminfo? Whoever is responsible for termcap/terminfo. Unfortunately that would mean shooting the author of one of my favourite games, rogue, as curses/termcap evolved out of that. Adrian. |
|
From: J.P. K. <jp...@he...> - 2001-12-12 10:23:14
|
> __lint is for when you use 'lint', the C program fluff finder. > I presume it is there specifically to avoid the double-defines, as lint > will complain loudly about them. > > When I get a chance, I'll run the source through lint here (I have one > that deals with C++), and then let other people fix all the warnings... Heh - want me to run the code through Sun's compiler suite? :-) I don't know if there is a lint included there, although I can try it. I could probably install it on something, but that would be... what is the word I am looking for? Oh yes, 'illegal'. >:-> > Double-includes of header files should be OK if everyone remembers to > set include-guards. These were two separate header files though... seemed remarkably odd to be honest, I merely used some functionality that was already there. > Ah, that one. My personal preference would be to take the programmer > who wrote those functions out to a wall and shoot them. The 'Ugly' functions or just whoever is responsible for termcap/terminfo? Julian |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-12 09:40:54
|
> From: Peter Crowther [mailto:pet...@ne...] > > > From: Adrian St. John [mailto:AS...@pa...] > > When I get a chance, I'll run the source through lint here=20 > (I have one > > that deals with C++) >=20 > Cool! What is it, and is it generally available? It's Flex PC-Lint, and it is commercial. It is also available for UNIX (as source code!), but that would cost lots of money for a licence. >=20 > > > The rest of the changes are the creation of a tmpstring which is > > > used when calling tigetnum (and friends) which insist on a char * > > > and not a const char *. Again, I believe this is safe, but I > > > don't tend to mess with strcpy or malloc, so I am quite=20 > prepared to > > > believe that it is wrong. Also, whilst I know that it is the > > > terminal handling code, I am not sure how to test it. > >=20 > > Ah, that one. My personal preference would be to take the programmer > > who wrote those functions out to a wall and shoot them. >=20 > Do all the platforms we use have C++ compilers that can cope with > const_cast<char *>(str)? Given that all the platforms we use tend to be up to date, using g++, I suspect so. Adrian |
|
From: Peter C. <pet...@ne...> - 2001-12-12 09:31:56
|
> From: Adrian St. John [mailto:AS...@pa...] > When I get a chance, I'll run the source through lint here (I have one > that deals with C++) Cool! What is it, and is it generally available? > > The rest of the changes are the creation of a tmpstring which is > > used when calling tigetnum (and friends) which insist on a char * > > and not a const char *. Again, I believe this is safe, but I > > don't tend to mess with strcpy or malloc, so I am quite prepared to > > believe that it is wrong. Also, whilst I know that it is the > > terminal handling code, I am not sure how to test it. > > Ah, that one. My personal preference would be to take the programmer > who wrote those functions out to a wall and shoot them. Do all the platforms we use have C++ compilers that can cope with const_cast<char *>(str)? - Peter |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-12 09:28:54
|
> From: J.P. King [mailto:jp...@he...]
>=20
> I've changed, and committed the change to Makefile, there was a=20
> missing ' in a sed used in creating version.h Not sure how that
> happened, but it is there now.
Might have been me, with my Release tag version info thingy.
> I've also changed interface.c, I think this is safe, but I am feeling
> paranoid. It removes the last set of warnings for Solaris compiles.
>=20
> The '__lint' appears to avoid one set of defines kicking in
> removing the warning about double defines. This is probably a
> nasty hack, but based on my grep of the include files shouldn't
> cause any other problems. However maybe someone knows what
> it is supposed to be used for, and this isn't it. I can remove
> that, and see about another way of removing the error if necessary.
__lint is for when you use 'lint', the C program fluff finder.
I presume it is there specifically to avoid the double-defines, as lint
will complain loudly about them.
When I get a chance, I'll run the source through lint here (I have one
that deals with C++), and then let other people fix all the warnings...
Double-includes of header files should be OK if everyone remembers to
set include-guards.
> The rest of the changes are the creation of a tmpstring which is
> used when calling tigetnum (and friends) which insist on a char *
> and not a const char *. Again, I believe this is safe, but I
> don't tend to mess with strcpy or malloc, so I am quite prepared to
> believe that it is wrong. Also, whilst I know that it is the
> terminal handling code, I am not sure how to test it.
Ah, that one. My personal preference would be to take the programmer
who wrote those functions out to a wall and shoot them.
> I'll leave it for a while, and if noone shouts at me I'll commit the
> code.
>=20
> I've tested that it still compiles under Solaris, Linux and FreeBSD.
>=20
> (Note Linux still has one warning about PRIO_PROCESS in netmud.c)
>=20
> Oh, and all of these hacks I've been doing should probably be farmed=20
> off somewhere so as to make it easier to maintain, but I'm=20
> just trying to
> get the code into a state where if you see a warning when it compiles
> you notice, and maybe even investigate it.
>=20
> Cheers,
>=20
> Julian
>=20
>=20
> Index: interface.c
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/uglycode/UglyCODE/interface.c,v
> retrieving revision 1.32
> diff -c -r1.32 interface.c
> *** interface.c 2001/12/11 14:21:29 1.32
> --- interface.c 2001/12/11 18:22:00
> ***************
> *** 9,14 ****
> --- 9,16 ----
>=20
> /* KEITH: Buy a surperior spellchecker too. - Luggs */
>=20
> + #define __lint
> +
> #include "copyright.h"
>=20
> #include <stdio.h>
> ***************
> *** 1841,1846 ****
> --- 1843,1854 ----
> {
> char *terminal;
>=20
> + char *tmpstring;
> + tmpstring=3D(char *)malloc(sizeof("lines ")); /*=20
> 'lines' is the longest
> + *=20
> string needed, the
> + *=20
> spaces are paranoia
> + */
> +
> terminal =3D safe_strdup(termtype);
>=20
> for(int i =3D 0; terminal[i]; i++)
> ***************
> *** 1867,1880 ****
>=20
> if (terminal_width =3D=3D 0)
> {
> ! terminal_width =3D tigetnum("cols");
> #ifdef DEBUG_TELNET
> Trace( "Terminal width (from terminfo): =20
> %d\n", terminal_width);
> #endif
> }
> if (terminal_height =3D=3D 0)
> {
> ! terminal_height =3D tigetnum("lines");
> #ifdef DEBUG_TELNET
> Trace( "Terminal height (from terminfo): =20
> %d\n", terminal_height);
> #endif
> --- 1875,1892 ----
>=20
> if (terminal_width =3D=3D 0)
> {
> ! strcpy(tmpstring,"cols");
> ! terminal_width =3D tigetnum(tmpstring);
> ! //terminal_width =3D tigetnum("cols");
> #ifdef DEBUG_TELNET
> Trace( "Terminal width (from terminfo): =20
> %d\n", terminal_width);
> #endif
> }
> if (terminal_height =3D=3D 0)
> {
> ! strcpy(tmpstring,"lines");
> ! terminal_height =3D tigetnum(tmpstring);
> ! //terminal_height =3D tigetnum("lines");
> #ifdef DEBUG_TELNET
> Trace( "Terminal height (from terminfo): =20
> %d\n", terminal_height);
> #endif
> ***************
> *** 1897,1903 ****
> * }
> */
>=20
> ! const char *const bold =3D tigetstr("bold");
> if (bold !=3D (char *)-1)
> {
> if (termcap.bold_on)
> --- 1909,1917 ----
> * }
> */
>=20
> ! strcpy(tmpstring,"bold");
> ! const char *const bold =3D tigetstr(tmpstring);
> ! //const char *const bold =3D tigetstr("bold");
> if (bold !=3D (char *)-1)
> {
> if (termcap.bold_on)
> ***************
> *** 1905,1911 ****
> termcap.bold_on =3D safe_strdup(bold);
> }
>=20
> ! const char *const bold_off =3D tigetstr("sgr0");
> if (bold_off !=3D (char *)-1)
> {
> if (termcap.bold_off)
> --- 1919,1927 ----
> termcap.bold_on =3D safe_strdup(bold);
> }
>=20
> ! strcpy(tmpstring,"sgr0");
> ! const char *const bold_off =3D tigetstr(tmpstring);
> ! //const char *const bold_off =3D tigetstr("sgr0");
> if (bold_off !=3D (char *)-1)
> {
> if (termcap.bold_off)
> ***************
> *** 1913,1919 ****
> termcap.bold_off =3D safe_strdup(bold_off);
> }
>=20
> ! const char *const underline =3D tigetstr("smul");
> if (underline !=3D (char *)-1)
> {
> if (termcap.underscore_on)
> --- 1929,1937 ----
> termcap.bold_off =3D safe_strdup(bold_off);
> }
>=20
> ! strcpy(tmpstring,"smul");
> ! const char *const underline =3D tigetstr(tmpstring);
> ! //const char *const underline =3D tigetstr("smul");
> if (underline !=3D (char *)-1)
> {
> if (termcap.underscore_on)
> ***************
> *** 1921,1927 ****
> termcap.underscore_on =3D safe_strdup(underline);
> }
>=20
> ! const char *const underscore_off =3D tigetstr("rmul");
> if (underscore_off !=3D (char *)-1)
> {
> if (termcap.underscore_off)
> --- 1939,1947 ----
> termcap.underscore_on =3D safe_strdup(underline);
> }
>=20
> ! strcpy(tmpstring,"rmul");
> ! const char *const underscore_off =3D tigetstr(tmpstring);
> ! //const char *const underscore_off =3D tigetstr("rmul");
> if (underscore_off !=3D (char *)-1)
> {
> if (termcap.underscore_off)
>=20
>=20
>=20
> _______________________________________________
> Uglycode-coders mailing list
> Ugl...@li...
> https://lists.sourceforge.net/lists/listinfo/uglycode-coders
>=20
|
|
From: J.P. K. <jp...@he...> - 2001-12-11 19:06:03
|
I've changed, and committed the change to Makefile, there was a
missing ' in a sed used in creating version.h Not sure how that
happened, but it is there now.
I've also changed interface.c, I think this is safe, but I am feeling
paranoid. It removes the last set of warnings for Solaris compiles.
The '__lint' appears to avoid one set of defines kicking in
removing the warning about double defines. This is probably a
nasty hack, but based on my grep of the include files shouldn't
cause any other problems. However maybe someone knows what
it is supposed to be used for, and this isn't it. I can remove
that, and see about another way of removing the error if necessary.
The rest of the changes are the creation of a tmpstring which is
used when calling tigetnum (and friends) which insist on a char *
and not a const char *. Again, I believe this is safe, but I
don't tend to mess with strcpy or malloc, so I am quite prepared to
believe that it is wrong. Also, whilst I know that it is the
terminal handling code, I am not sure how to test it.
I'll leave it for a while, and if noone shouts at me I'll commit the
code.
I've tested that it still compiles under Solaris, Linux and FreeBSD.
(Note Linux still has one warning about PRIO_PROCESS in netmud.c)
Oh, and all of these hacks I've been doing should probably be farmed
off somewhere so as to make it easier to maintain, but I'm just trying to
get the code into a state where if you see a warning when it compiles
you notice, and maybe even investigate it.
Cheers,
Julian
Index: interface.c
===================================================================
RCS file: /cvsroot/uglycode/UglyCODE/interface.c,v
retrieving revision 1.32
diff -c -r1.32 interface.c
*** interface.c 2001/12/11 14:21:29 1.32
--- interface.c 2001/12/11 18:22:00
***************
*** 9,14 ****
--- 9,16 ----
/* KEITH: Buy a surperior spellchecker too. - Luggs */
+ #define __lint
+
#include "copyright.h"
#include <stdio.h>
***************
*** 1841,1846 ****
--- 1843,1854 ----
{
char *terminal;
+ char *tmpstring;
+ tmpstring=(char *)malloc(sizeof("lines ")); /* 'lines' is the longest
+ * string needed, the
+ * spaces are paranoia
+ */
+
terminal = safe_strdup(termtype);
for(int i = 0; terminal[i]; i++)
***************
*** 1867,1880 ****
if (terminal_width == 0)
{
! terminal_width = tigetnum("cols");
#ifdef DEBUG_TELNET
Trace( "Terminal width (from terminfo): %d\n", terminal_width);
#endif
}
if (terminal_height == 0)
{
! terminal_height = tigetnum("lines");
#ifdef DEBUG_TELNET
Trace( "Terminal height (from terminfo): %d\n", terminal_height);
#endif
--- 1875,1892 ----
if (terminal_width == 0)
{
! strcpy(tmpstring,"cols");
! terminal_width = tigetnum(tmpstring);
! //terminal_width = tigetnum("cols");
#ifdef DEBUG_TELNET
Trace( "Terminal width (from terminfo): %d\n", terminal_width);
#endif
}
if (terminal_height == 0)
{
! strcpy(tmpstring,"lines");
! terminal_height = tigetnum(tmpstring);
! //terminal_height = tigetnum("lines");
#ifdef DEBUG_TELNET
Trace( "Terminal height (from terminfo): %d\n", terminal_height);
#endif
***************
*** 1897,1903 ****
* }
*/
! const char *const bold = tigetstr("bold");
if (bold != (char *)-1)
{
if (termcap.bold_on)
--- 1909,1917 ----
* }
*/
! strcpy(tmpstring,"bold");
! const char *const bold = tigetstr(tmpstring);
! //const char *const bold = tigetstr("bold");
if (bold != (char *)-1)
{
if (termcap.bold_on)
***************
*** 1905,1911 ****
termcap.bold_on = safe_strdup(bold);
}
! const char *const bold_off = tigetstr("sgr0");
if (bold_off != (char *)-1)
{
if (termcap.bold_off)
--- 1919,1927 ----
termcap.bold_on = safe_strdup(bold);
}
! strcpy(tmpstring,"sgr0");
! const char *const bold_off = tigetstr(tmpstring);
! //const char *const bold_off = tigetstr("sgr0");
if (bold_off != (char *)-1)
{
if (termcap.bold_off)
***************
*** 1913,1919 ****
termcap.bold_off = safe_strdup(bold_off);
}
! const char *const underline = tigetstr("smul");
if (underline != (char *)-1)
{
if (termcap.underscore_on)
--- 1929,1937 ----
termcap.bold_off = safe_strdup(bold_off);
}
! strcpy(tmpstring,"smul");
! const char *const underline = tigetstr(tmpstring);
! //const char *const underline = tigetstr("smul");
if (underline != (char *)-1)
{
if (termcap.underscore_on)
***************
*** 1921,1927 ****
termcap.underscore_on = safe_strdup(underline);
}
! const char *const underscore_off = tigetstr("rmul");
if (underscore_off != (char *)-1)
{
if (termcap.underscore_off)
--- 1939,1947 ----
termcap.underscore_on = safe_strdup(underline);
}
! strcpy(tmpstring,"rmul");
! const char *const underscore_off = tigetstr(tmpstring);
! //const char *const underscore_off = tigetstr("rmul");
if (underscore_off != (char *)-1)
{
if (termcap.underscore_off)
|
|
From: Adrian S. J. <AS...@pa...> - 2001-12-11 16:56:46
|
Ok, I've made a couple of releases, mainly cos I had a flash
of inspiration about a minute after I tagged release um1_009.
um1_009 has the following changes:
* Julian's code updates
* DONTANNOUNCE flag
Don't announce a player connection/disconnection.
Wizard-settable, mortal unsettable.
* chat #<privatechannel> =3D force
Wizard-only, allow a wizard to join a private chat channel
even if they're not invited.
This is to avoid screwups like we had with #chat recently.
PLEASE DO NOT ABUSE THIS. IF I GET COMPLAINTS, I'LL UPDATE
THE CODE TO LOG THE USE OF IT.
um1_010 has the following changes:
* @version now reports the Release tag correctly (see below)
* 'what' under Solaris will tell you the version string.
In addition to this, tag_list has been updated so that the first
line is $Name: <release_tag>$. DO NOT MODIFY THIS LINE, PUT ANYTHING
ELSE ON IT, OR ANY LINES ABOVE IT.
The comment a few lines below is bogus. You do not have to manually
update this line, as CVS will do it for you.
Adrian.
--
Adrian St. John
Software Engineer
Pan Security International Ltd.
T 0121 780 0619
as...@pa...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
Pan Security International Limited, Vienna House, International Square, =
Birmingham International Park, Bickenhill Lane, Solihull B37 7GN United =
Kingdom. Registered company number 3965174=20
This message may contain information which is confidential and subject =
to legal privilege. If you are not the intended recipient, you may not =
peruse, use, disseminate, distribute or copy this message. If you have =
received this message in error, please notify the sender immediately by =
e-mail, facsimile or telephone and return and/or destroy the original =
message. Pan Security International Limited accept no responsibility for =
any changes made to this message after it has been sent by the original =
author.
|
|
From: J.P. K. <jp...@he...> - 2001-12-11 10:42:34
|
Ok, done my small updates, I do hope that I haven't fucked up too much. Code should compile almost cleanly on multiple platforms Julian |
|
From: J.P. K. <jp...@he...> - 2001-12-10 13:32:52
|
> I'll hit Solaris now, and see if that still compiles correctly.
Ok, apart from:
g++ -c -g -Wall -Wcast-qual -Wparentheses -Wwrite-strings -Wconversion interface
.c
In file included from /usr/include/curses.h:23,
from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include
/curses.h:5,
from interface.c:48:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous definition
interface.c: In method `int descriptor_data::set_terminal_type(const char *)':
interface.c:1870: warning: deprecated conversion from string constant to `char *'
interface.c:1877: warning: deprecated conversion from string constant to `char *'
interface.c:1900: warning: deprecated conversion from string constant to `char *'
interface.c:1908: warning: deprecated conversion from string constant to `char *'
interface.c:1916: warning: deprecated conversion from string constant to `char *'
interface.c:1924: warning: deprecated conversion from string constant to `char *'
and
g++ -c -g -Wall -Wcast-qual -Wparentheses -Wwrite-strings -Wconversion variable.c
variable.c: In function `enum Command_status full_parse_expression(context &, const char *, char *, unsigned int)':
variable.c:1324: warning: comparison between signed and unsigned
variable.c:1364: warning: comparison between signed and unsigned
variable.c:1418: warning: comparison between signed and unsigned
(which is a warning on all platforms)
Solaris compiled the code happily enough. Anyone have any objections
if this code is committed? (can I actually commit code?) I can put
the code somewhere useful, or mail context diffs if people want?
Julian
|
|
From: J.P. K. <jp...@he...> - 2001-12-10 13:15:28
|
Ok, fixed up the FreeBSD problems too - I think without exception they were time related - the code was inconsistant about using time_t rather than long. Also, some OSes define time_t as a long int, and some as an int. This made the sprintf's interesting. My chosen method of fudging it was to cast the variables to a long int where used in a sprintf. I believe that casting an int to a long is safe where it is only being used in a sprintf? Don't you love C? I'll hit Solaris now, and see if that still compiles correctly. Julian |
|
From: J.P. K. <jp...@he...> - 2001-12-10 09:55:26
|
> > What's libsocket? When/where/why did it crrep into the make? It is Solaris specific, if you look at the Makefile, as ugly as it is this should be clear. The makefile as it stands will not cope with any platform without modification. > Is it a (linux) library that I should have, and don't, or a Sun Special? It is a LIB line you should comment out and select the correct one instead. Also you'll need to change the WHOAMI line, and the CFLAGS line (I have started tidying the Makefile up a bit, but it is by no means perfect.) > Chiz Julian |
|
From: Adrian S. J. <AS...@pa...> - 2001-12-10 09:29:33
|
> From: Chisel Wright [mailto:ch...@he...] >=20 >=20 > What's libsocket? When/where/why did it crrep into the make? It is for Solaris. Take it out of your Makefile. >=20 > Chiz Adrian. |
|
From: Chisel W. <ch...@he...> - 2001-12-09 23:31:33
|
What's libsocket? When/where/why did it crrep into the make? I 'googled' for libsocket, and found http://www.phekda.freeserve.co.uk/richdawe/lsck/lsck_dl.htm which seems to imply that development has ceased and nothing has been done since Feb 2001. Is it a (linux) library that I should have, and don't, or a Sun Special? Chiz -- Chisel Wright (ch...@he...) Typer of code; tearer of hair. |
|
From: J.P. K. <jp...@he...> - 2001-12-09 22:22:05
|
> Aah, joy; now we've away from linux a little, again, I've having problems compiling Bah, and loads of warnings. Took me ages to get the warnings down to a manageable level too. I'll talk to Adrian and Keith about when they think the code will be reasonably stable from their point of view. > Any clues on what this error actually *means*? I think the error is the previous one rather than that one.. rm -f interface.o g++ -c -g -Wall -Wcast-qual -Wparentheses -Wwrite-strings -Wconversion interface.c interface.c: In function `void bailout(int)': interface.c:3599: type mismatch with previous external decl /usr/include/signal.h:279: previous external decl of `const char *const sys_siglist[64]' make: *** [interface.o] Error 1 mudstring.h \ make: mudstring.h: Command not found make: *** [stringutil.o] Error 127 > Solutions accepted, but if I understand the error I might be able to chase it further... > > make: *** [stringutil.o] Error 127 > rm -f netmud.o > g++ -c -g -Wall -Wcast-qual -Wparentheses -Wwrite-strings -Wconversion netmud.c > make: Target `by_default_just_make' not remade because of errors. > uglyadm@chisel:~/src/UglyCODE$ > > > Also, I've had to doctor interface.c and netmud.c: > > uglyadm@chisel:~/src/UglyCODE$ cvs diff > chi...@cv...'s password: > ? version.h > cvs server: Diffing . > Index: interface.c > =================================================================== > RCS file: /cvsroot/uglycode/UglyCODE/interface.c,v > retrieving revision 1.30 > diff -r1.30 interface.c > 3599c3599 > < extern const char * const sys_siglist[]; > --- > > //extern const char * const sys_siglist[]; > Index: netmud.c > =================================================================== > RCS file: /cvsroot/uglycode/UglyCODE/netmud.c,v > retrieving revision 1.7 > diff -r1.7 netmud.c > 21a22 > > #ifndef linux > 22a24 > > #endif > uglyadm@chisel:~/src/UglyCODE$ > > > I've heard rumours that autoconf, etc are hard work. Is it likely to > make things like this happen less? They have bad habits more than anything else. Better still would be to doctor the Makefile to have accept parameters, or work out its OS vaguely. Pretty much the code was at the state where it would cope with BSD, sysV or Linux. > The code seems to be full of "#if[n]def <OS type>", and it still > doesn't seem to compile properly. Would auto* alleviate this? You'd end up with the same style of code, only more so. The best thing would be to write portable code, but this isn't always possible. I worked on making the code compile with (almost) no errors on multiple platforms - so as to make tracking at least some of the other errors stand out. I hope to get back to that state - at least now I've dealt with the current project so I have a bit of time. > Chisel Wright (ch...@he...) Julian |
