search

fpjohnston / TECO-64

Enhanced and portable version of TECO text editor in C.
24 stars 6 forks source link

Preprocessor bug #1

Closed polluks closed 2 years ago

polluks commented 2 years ago

obvious...

fpjohnston commented 2 years ago

Thanks for the feedback. I will take a look at this. Sorry for the delay in my response; I have been offline for several weeks.

On Sat, Jan 8, 2022 at 8:25 PM Stefan @.***> wrote:

obvious...

You can view, comment on, or merge this pull request online at:

https://github.com/fpjohnston/TECO-64/pull/1 Commit Summary

File Changes

(1 file https://github.com/fpjohnston/TECO-64/pull/1/files)

Patch Links:

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7EXYQYJE67WJA4BN6TUVDPZDANCNFSM5LRH7Y2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

fpjohnston commented 2 years ago

Okay. I've fixed this and will upload new code later today.

You're right that it's obvious, but I haven't had much opportunity to test with other compilers. Out of curiosity, what are you compiling with, and in what environment?

On Wed, Feb 9, 2022 at 12:33 PM Franklin Johnston @.***> wrote:

Thanks for the feedback. I will take a look at this. Sorry for the delay in my response; I have been offline for several weeks.

On Sat, Jan 8, 2022 at 8:25 PM Stefan @.***> wrote:

obvious...

You can view, comment on, or merge this pull request online at:

https://github.com/fpjohnston/TECO-64/pull/1 Commit Summary

File Changes

(1 file https://github.com/fpjohnston/TECO-64/pull/1/files)

Patch Links:

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7EXYQYJE67WJA4BN6TUVDPZDANCNFSM5LRH7Y2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

polluks commented 2 years ago

I suppose you don't know it http://aminet.net/package/text/edit/TECO-64

fpjohnston commented 2 years ago

So you're using a compiler for an Amiga? Well, I certainly wouldn't have expected that.

In any case, the code fixes are in version 200.22.3, which I just uploaded.

So have you been able to run TECO on an Amiga? And if you've had any difficulty, is there anything I can do to help?

Franklin

On Wed, Feb 9, 2022 at 1:05 PM Stefan @.***> wrote:

I suppose you don't know it http://aminet.net/package/text/edit/TECO-64

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1034047267, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7ATTPMAU73W7PZXIMTU2KUF3ANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

polluks commented 2 years ago

Well, it's not an Amiga, just an Amiga-like sandbox. However I can try a real port :-)

fpjohnston commented 2 years ago

Well, if you don't mind my asking, what interested you in TECO? Which is to say, why choose it for your sandbox?

And to reiterate what I said before, I'm happy to make any reasonable enhancements or changes to facilitate your port.

On Thu, Feb 10, 2022 at 3:41 AM Stefan @.***> wrote:

Well, it's not an Amiga, just an Amiga-like sandbox. However I can try a real port :-)

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1034640732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7GCOJD7QLQ2HVFGTK3U2N22DANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

fpjohnston commented 2 years ago

Just FYI. Nothing critical in the version (200.23.0) I just posted, but I found a few things I thought needed to be changed or fixed.

Also, I belatedly realized that I'd never assigned a version to the code I posted in December. Oops.

FPJ

On Thu, Feb 10, 2022 at 3:41 AM Stefan @.***> wrote:

Well, it's not an Amiga, just an Amiga-like sandbox. However I can try a real port :-)

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1034640732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7GCOJD7QLQ2HVFGTK3U2N22DANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

fpjohnston commented 2 years ago

I should have said 200.23.1. I ran into some problems pushing new code to GitHub. Not sure what I did wrong, but I'm pretty sure everything is current now.

On Wed, Feb 16, 2022 at 9:56 AM Franklin Johnston @.***> wrote:

Just FYI. Nothing critical in the version (200.23.0) I just posted, but I found a few things I thought needed to be changed or fixed.

Also, I belatedly realized that I'd never assigned a version to the code I posted in December. Oops.

FPJ

On Thu, Feb 10, 2022 at 3:41 AM Stefan @.***> wrote:

Well, it's not an Amiga, just an Amiga-like sandbox. However I can try a real port :-)

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1034640732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7GCOJD7QLQ2HVFGTK3U2N22DANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

polluks commented 2 years ago

Hi Franklin!

My gcc 9.3.0 and 10.2.0 don't define "ulong".

Making errors.o ../src/errors.c: In function 'print_error': ../src/errors.c:253:21: error: 'ulong' undeclared (first use in this function); did you mean 'u_long'? 253 | (ulong)cmd_line); | ^~~~~ | u_long ../src/errors.c:253:21: note: each undeclared identifier is reported only once for each function it appears in ../src/errors.c:253:27: error: expected ')' before 'cmd_line' 253 | (ulong)cmd_line); | ^~~~ | ) ../src/errors.c: In function 'throw': ../src/errors.c:458:1: warning: 'noreturn' function does return 458 | } | ^ make: *** [Makefile:420: errors.o] Error 1

--- src/teco.c.bak 2022-02-16 17:17:52 +0100 +++ src/teco.c 2022-02-20 00:46:28 +0100 @@ -91,7 +91,7 @@

 .e3.smart = true,               // Enable smart line detection

-#if defined(linux) || defined(APPLE) +#if defined(linux) || defined(APPLE) || defined(AMIGA)

 .e3.CR_in   = false,            // Use LF for input lines
 .e3.CR_out  = false,            // Use LF for output lines
fpjohnston commented 2 years ago

It should be defined in sys/types.h, and I thought it had been there a while. In any case, there is a conditional definition of it in teco.h that I used when using a clang compiler on VMS; you could make that unconditional for your own builds. In the meantime, I'll see if I can figure out when this was added to gcc in hopes of modifying the conditional check. For what it's worth, I'm presently using version 11.2.0 .

On Sat, Feb 19, 2022 at 7:00 PM Stefan @.***> wrote:

Hi Franklin!

My gcc 9.3.0 and 10.2.0 don't define "ulong".

Making errors.o ../src/errors.c: In function 'print_error': ../src/errors.c:253:21: error: 'ulong' undeclared (first use in this function); did you mean 'u_long'? 253 | (ulong)cmd_line); | ^~~~~ | u_long ../src/errors.c:253:21: note: each undeclared identifier is reported only once for each function it appears in ../src/errors.c:253:27: error: expected ')' before 'cmd_line' 253 | (ulong)cmd_line); | ^~~~ | ) ../src/errors.c: In function 'throw': ../src/errors.c:458:1: warning: 'noreturn' function does return 458 | } | ^ make: *** [Makefile:420: errors.o] Error 1

--- src/teco.c.bak 2022-02-16 17:17:52 +0100 +++ src/teco.c 2022-02-20 00:46:28 +0100 @@ -91,7 +91,7 @@

.e3.smart = true, // Enable smart line detection

-#if defined(linux) || defined(APPLE) +#if defined(linux) || defined(APPLE) || defined(AMIGA)

.e3.CR_in = false, // Use LF for input lines .e3.CR_out = false, // Use LF for output lines

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1046127130, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7E5CV7TXSOR44JO7UTU4AVJFANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

polluks commented 2 years ago

VMS, pretty cool. If you select gnu11 you should not take care of the compiler version IMHO

fpjohnston commented 2 years ago

Understood. Have you confirmed that the ulong definition does not appear in sys/types.h for versions 9 and 10?

On Sun, Feb 20, 2022 at 8:17 AM Stefan @.***> wrote:

VMS, pretty cool. If you select gnu11 you should not take care of the compiler version IMHO

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1046236118, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7G6LFDVOCWY5RZSWTTU4DSW7ANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

polluks commented 2 years ago 
> grep -r ulong gg:include/
gg:include/GMP/gmp.h:#define mpz_fits_ulong_p __gmpz_fits_ulong_p
gg:include/GMP/gmp.h:#if __GMP_INLINE_PROTOTYPES || defined (__GMP_FORCE_mpz_fits_ulong_p)
gg:include/GMP/gmp.h:__GMP_DECLSPEC int mpz_fits_ulong_p (mpz_srcptr) __GMP_NOTHROW __GMP_ATTRIBUTE_PURE;
gg:include/GMP/gmp.h:#define mpf_fits_ulong_p __gmpf_fits_ulong_p
gg:include/GMP/gmp.h:__GMP_DECLSPEC int mpf_fits_ulong_p (mpf_srcptr) __GMP_NOTHROW __GMP_ATTRIBUTE_PURE;
gg:include/GMP/gmp.h:#if defined (__GMP_EXTERN_INLINE) || defined (__GMP_FORCE_mpz_fits_ulong_p)
gg:include/GMP/gmp.h:#if ! defined (__GMP_FORCE_mpz_fits_ulong_p)
gg:include/GMP/gmp.h:mpz_fits_ulong_p (mpz_srcptr __gmp_z) __GMP_NOTHROW
gg:include/llvm/Support/SwapByteOrder.h:  return _byteswap_ulong(value);
gg:include/openssl/x509v3.h:int SXNET_add_id_ulong(SXNET **psx, unsigned long lzone, const char *user,
gg:include/openssl/x509v3.h:ASN1_OCTET_STRING *SXNET_get_id_ulong(SXNET *sx, unsigned long lzone);

My sys/types.h: [...]

#if !defined _POSIX_SOURCE || defined __MORPHOS__
typedef unsigned char   u_char;
typedef unsigned short  u_short;
typedef unsigned int    u_int;
typedef unsigned long   u_long;
typedef unsigned short  ushort;         /* Sys V compatibility */
typedef unsigned int    uint;           /* Sys V compatibility */
#endif
fpjohnston commented 2 years ago

Can you give me the results of the following command?

find gg:include/ -name "types.h"

On Sun, Feb 20, 2022 at 12:34 PM Stefan @.***> wrote:

grep -r ulong gg:include/ gg:include/GMP/gmp.h:#define mpz_fits_ulong_p gmpz_fits_ulong_p gg:include/GMP/gmp.h:#if GMP_INLINE_PROTOTYPES || defined (GMP_FORCE_mpz_fits_ulong_p) gg:include/GMP/gmp.h:GMP_DECLSPEC int mpz_fits_ulong_p (mpz_srcptr) GMP_NOTHROW __GMP_ATTRIBUTE_PURE; gg:include/GMP/gmp.h:#define mpf_fits_ulong_p gmpf_fits_ulong_p gg:include/GMP/gmp.h:GMP_DECLSPEC int mpf_fits_ulong_p (mpf_srcptr) __GMP_NOTHROW GMP_ATTRIBUTE_PURE; gg:include/GMP/gmp.h:#if defined (GMP_EXTERN_INLINE) || defined (GMP_FORCE_mpz_fits_ulong_p) gg:include/GMP/gmp.h:#if ! defined (GMP_FORCE_mpz_fits_ulong_p) gg:include/GMP/gmp.h:mpz_fits_ulong_p (mpz_srcptr __gmp_z) GMP_NOTHROW gg:include/llvm/Support/SwapByteOrder.h: return _byteswap_ulong(value); gg:include/openssl/x509v3.h:int SXNET_add_id_ulong(SXNET *psx, unsigned long lzone, const char user, gg:include/openssl/x509v3.h:ASN1_OCTET_STRING SXNET_get_id_ulong(SXNET sx, unsigned long lzone);

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1046285920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7BIJD4B7FFKACUZUD3U4EQZNANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

polluks commented 2 years ago

find gg:include/ -name "types.h" gg:include/sys/types.h gg:include/rpc/types.h gg:include/machine/types.h

fpjohnston commented 2 years ago

Okay, so you've got sys/types.h, but it does not include ulong. That seems a bit odd, but maybe I missed something. Are you compiling for a 68000 instead of x86? That might explain it.

In any case, I think I have a simple solution: make the ulong definition in teco.h unconditional. I didn't think I could do this, but as I learned today, gcc allows duplicate typedefs without giving an error. So as long as my definition matches the one in sys/types.h, there'd be no problem.

I'll check this change this evening, and that should take care of it for you.

On Sun, Feb 20, 2022 at 5:14 PM Stefan @.***> wrote:

find gg:include/ -name "types.h" gg:include/sys/types.h gg:include/rpc/types.h gg:include/machine/types.h

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1046332107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7CM2ZWY4MVNEJURH4TU4FRTHANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

fpjohnston commented 2 years ago

I think maybe I should have done a Reply All in order for you to have seen this:

Okay, so you've got sys/types.h, but it does not include ulong. That seems a bit odd, but maybe I missed something. Are you compiling for a 68000 instead of x86? That might explain it.

In any case, I think I have a simple solution: make the ulong definition in teco.h unconditional. I didn't think I could do this, but as I learned today, gcc allows duplicate typedefs without giving an error. So as long as my definition matches the one in sys/types.h, there'd be no problem.

I'll check this change this evening, and that should take care of it for you.

Update: version 200.23.2 is now available on github.

On Sun, Feb 20, 2022 at 5:14 PM Stefan @.***> wrote:

find gg:include/ -name "types.h" gg:include/sys/types.h gg:include/rpc/types.h gg:include/machine/types.h

— Reply to this email directly, view it on GitHub https://github.com/fpjohnston/TECO-64/pull/1#issuecomment-1046332107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK73X7CM2ZWY4MVNEJURH4TU4FRTHANCNFSM5LRH7Y2Q . You are receiving this because you commented.Message ID: @.***>

polluks commented 2 years ago

FYI https://stackoverflow.com/questions/8594954/repeated-typedefs-invalid-in-c-but-valid-in-c