Hello
I've written an old style interactive line BASIC written in C for Unix, specifically Linux, OS/X and FreeBSD but hopefully it'll compile on others with
little or no changes as it only uses standard libraries.
On top of the normal line BASIC functionality it also supports simple key-value
maps (dictionaries), multiprocess support + control and ANSI terminal graphics
and colour.
I'm not going to pretend its an advanced programming enviroment that breaks new ground, its very retro which was the whole point, but if you just want to write a quick program or teach your kids coding then I hope it will be of some
use.
Download the source code from:
http://www.ogham.demon.co.uk/zips/basic100.tgz
My email is in the README so if you have any questions feel free to use it.
Does not compile in Linux.
El 17/02/16 a las 16:08, nrjbasic@nrjbasic.xx.uk escribió:
program.o disk.o draw.o misc.o -o basic
functions.o: En la función `funcRound': >/home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
functions.o: En la función `funcFloor': >/home/jesus/src/BASIC/basic/src/functions.c:182: referencia a `floor'
sin definir
On Wed, 17 Feb 2016 14:45:52 +0100
gamo <gamo@telecable.es> wrote:
Does not compile in Linux.
Did you follow the instructions in the README and uncomment the correct
line in the Makefile for linux?
El 17/02/16 a las 16:08, nrjbasic@nrjbasic.xx.uk escribió:
On Wed, 17 Feb 2016 14:45:52 +0100:~/src/BASIC/basic/src$ make
gamo <gamo@telecable.es> wrote:
Does not compile in Linux.
Did you follow the instructions in the README and uncomment the correct
line in the Makefile for linux?
echo "#define BUILD_DATE \"`date +'%Y-%m-%d %T %Z'`\"" > build_date.h
cc -D CRYPT_HDR -Wall -pedantic -c -g main.c
main.c: In function ‘init’:
main.c:163:24: warning: argument to ‘sizeof’ in ‘bzero’ call is the same expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
bzero(keyb_line,sizeof(keyb_line));
^
cc -D CRYPT_HDR -Wall -pedantic -c -g keyboard.c
cc -D CRYPT_HDR -Wall -pedantic -c -g tokeniser.c
cc -D CRYPT_HDR -Wall -pedantic -c -g execute.c
cc -D CRYPT_HDR -Wall -pedantic -c -g commands.c
cc -D CRYPT_HDR -Wall -pedantic -c -g functions.c
cc -D CRYPT_HDR -Wall -pedantic -c -g variables.c
cc -D CRYPT_HDR -Wall -pedantic -c -g expressions.c
cc -D CRYPT_HDR -Wall -pedantic -c -g defexp.c
cc -D CRYPT_HDR -Wall -pedantic -c -g values.c
values.c: In function ‘initMemValue’:
values.c:27:27: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if ((val->shmid = shmget((key_t)val,size+1,IPC_CREAT | 0666)) < 0)
^
cc -D CRYPT_HDR -Wall -pedantic -c -g program.c
cc -D CRYPT_HDR -Wall -pedantic -c -g disk.c
cc -D CRYPT_HDR -Wall -pedantic -c -g draw.c
cc -D CRYPT_HDR -Wall -pedantic -c -g misc.c
cc -D CRYPT_HDR -lm -lcrypt main.o keyboard.o tokeniser.o execute.o commands.o functions.o variables.o expressions.o defexp.o values.o
program.o disk.o draw.o misc.o -o basic
functions.o: En la función `funcRound': /home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
functions.o: En la función `funcFloor': /home/jesus/src/BASIC/basic/src/functions.c:182: referencia a `floor'
sin definir
functions.o: En la función `funcCeil': /home/jesus/src/BASIC/basic/src/functions.c:191: referencia a `ceil' sin definir
functions.o: En la función `funcSqrt': /home/jesus/src/BASIC/basic/src/functions.c:200: referencia a `sqrt' sin definir
functions.o: En la función `funcPow': /home/jesus/src/BASIC/basic/src/functions.c:209: referencia a `pow' sin definir
functions.o: En la función `funcTrig1': /home/jesus/src/BASIC/basic/src/functions.c:225: referencia a `sin' sin definir
/home/jesus/src/BASIC/basic/src/functions.c:226: referencia a `cos' sin definir
/home/jesus/src/BASIC/basic/src/functions.c:227: referencia a `tan' sin definir
functions.o: En la función `funcTrig2': /home/jesus/src/BASIC/basic/src/functions.c:247: referencia a `asin' sin definir
/home/jesus/src/BASIC/basic/src/functions.c:253: referencia a `acos' sin definir
/home/jesus/src/BASIC/basic/src/functions.c:257: referencia a `atan' sin definir
functions.o: En la función `funcLog': /home/jesus/src/BASIC/basic/src/functions.c:281: referencia a `log2' sin definir
/home/jesus/src/BASIC/basic/src/functions.c:286: referencia a `log10'
sin definir
/home/jesus/src/BASIC/basic/src/functions.c:290: referencia a `log' sin definir
functions.o: En la función `funcHypot': /home/jesus/src/BASIC/basic/src/functions.c:305: referencia a `hypot'
sin definir
functions.o: En la función `funcCrypt': /home/jesus/src/BASIC/basic/src/functions.c:1947: referencia a `crypt'
sin definir
draw.o: En la función `drawCircle': /home/jesus/src/BASIC/basic/src/draw.c:135: referencia a `sin' sin definir /home/jesus/src/BASIC/basic/src/draw.c:136: referencia a `cos' sin definir collect2: error: ld returned 1 exit status
make: *** [basic] Error 1
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I
can only assume you don't have libm installed or its not in a standard >>location or another alternative is you have an old buggy version of gcc. >>Older versions of the compiler cared where the -l options went on the link >line.
If they were in the wrong place the object files wouldn't link properly. >>Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that >reference the math library functions. That's a bug in your makefile.
The other warnings should be noted, particuarly the bzero warning (you're >probably not zeroing as much as you expect). I'd use memset instead of >bzero anyway for better portability.
The shmget warning implies that you build on a 32-bit system, but gamo >compiled on a 64-bit system. I'd use mmap (MAP_PUBLIC) instead of shmat >myself if possible.
On Wed, 17 Feb 2016 18:24:32 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I >>>can only assume you don't have libm installed or its not in a standard >>>location or another alternative is you have an old buggy version of gcc. >>>Older versions of the compiler cared where the -l options went on the link >>line.
If they were in the wrong place the object files wouldn't link properly. >>>Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that >>reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago. A
decent compiler should not care about the order the libraries are listed in, >it should parse the entire command line first before linking.
The other warnings should be noted, particuarly the bzero warning (you're >>probably not zeroing as much as you expect). I'd use memset instead of >>bzero anyway for better portability.
Yes the bzero is a bug, but its old code that should have been removed. If >you look a few lines up you'll see its already being zeroed correctly. As
for portability - bzero() isn't going anywhere. Any system that didn't have it >would break a boatload of code. Its also shorter and more obvious what its >doing.
On Wed, 17 Feb 2016 17:17:40 +0100
gamo <gamo@telecable.es> wrote:
El 17/02/16 a las 16:08, nrjbasic@nrjbasic.xx.uk escribió:
program.o disk.o draw.o misc.o -o basic
functions.o: En la función `funcRound':
/home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
functions.o: En la función `funcFloor':
/home/jesus/src/BASIC/basic/src/functions.c:182: referencia a `floor'
sin definir
etc.
These are all standard maths functions so if they're not defined then I
can only assume you don't have libm installed or its not in a standard location or another alternative is you have an old buggy version of gcc. Older versions of the compiler cared where the -l options went on the link line.
If they were in the wrong place the object files wouldn't link properly. Perhaps trying putting -lm at the end?
Whatever the issue is, this code has been compiled on 3 seperate Linux systems
of varying ages and distros and this problem has not occured.
Sorry I can't be more help.
nrjbasic@nrjbasic.xx.uk writes:
On Wed, 17 Feb 2016 18:24:32 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I >>>>can only assume you don't have libm installed or its not in a standard >>>>location or another alternative is you have an old buggy version of gcc. >>>>Older versions of the compiler cared where the -l options went on the link >>>line.
If they were in the wrong place the object files wouldn't link properly. >>>>Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that >>>reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago. A
decent compiler should not care about the order the libraries are listed in, >>it should parse the entire command line first before linking.
Obviously, that rule still exists, or there wouldn't have been a
link error by someone using a different compiler than you are.
ANSI C defines memset. It doesn't define bzero. I've used systems
where bzero wasn't available.
On Wed, 17 Feb 2016 18:24:32 GMT[SNIP]
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I
can only assume you don't have libm installed or its not in a standard
location or another alternative is you have an old buggy version of gcc. >>> Older versions of the compiler cared where the -l options went on the link >> line.
If they were in the wrong place the object files wouldn't link properly. >>> Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that
reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago.
On Thu, 18 Feb 2016 14:24:41 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
On Wed, 17 Feb 2016 18:24:32 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I >>>>>can only assume you don't have libm installed or its not in a standard >>>>>location or another alternative is you have an old buggy version of gcc. >>>>>Older versions of the compiler cared where the -l options went on the link >>>>line.
If they were in the wrong place the object files wouldn't link properly. >>>>>Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that >>>>reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago. A >>>decent compiler should not care about the order the libraries are listed in, >>>it should parse the entire command line first before linking.
Obviously, that rule still exists, or there wouldn't have been a
link error by someone using a different compiler than you are.
Last time I encountered that error was in gcc 3.x. We're a bit past that version now. Since both gcc and clang have dumped that restriction I think its fair to say its now been realised that it was a stupid idea with little merit.
ANSI C defines memset. It doesn't define bzero. I've used systems
where bzero wasn't available.
Posix defines bzero.
nrjbasic@nrjbasic.xx.uk writes:
Last time I encountered that error was in gcc 3.x. We're a bit past that
version now. Since both gcc and clang have dumped that restriction I think >> its fair to say its now been realised that it was a stupid idea with little >> merit.
That's besides the point: Existing tools behave in this way. It's easy
to support.
That's a BSD-originated function some POSIX versions reportedly
defined. According to the Linux bzero(3) manpage,
4.3BSD. This function is deprecated (marked as LEGACY in
POSIX.1-2001): use memset(3) in new programs. POSIX.1-2008
removes the specification of bzero().
On Wed, 17 Feb 2016 18:24:32 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I >>>can only assume you don't have libm installed or its not in a standard >>>location or another alternative is you have an old buggy version of gcc. >>>Older versions of the compiler cared where the -l options went on the link >>line.
If they were in the wrong place the object files wouldn't link properly. >>>Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that >>reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago. A
decent compiler should not care about the order the libraries are listed in,
it should parse the entire command line first before linking.
Yes the bzero is a bug, but its old code that should have been removed. If
On Wed, 17 Feb 2016 17:17:40 +0100
gamo <gamo@telecable.es> wrote:
El 17/02/16 a las 16:08, nrjbasic@nrjbasic.xx.uk escribió:
program.o disk.o draw.o misc.o -o basic
functions.o: En la función `funcRound': >>/home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
functions.o: En la función `funcFloor': >>/home/jesus/src/BASIC/basic/src/functions.c:182: referencia a `floor'
sin definir
etc.
These are all standard maths functions so if they're not defined then I
can only assume you don't have libm installed or its not in a standard >location or another alternative is you have an old buggy version of gcc. >Older versions of the compiler cared where the -l options went on the link line.
If they were in the wrong place the object files wouldn't link properly. >Perhaps trying putting -lm at the end?
On 18/02/2016 8:45 PM, nrjbasic@nrjbasic.xx.uk wrote:
On Wed, 17 Feb 2016 18:24:32 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I >>> can only assume you don't have libm installed or its not in a standard >>> location or another alternative is you have an old buggy version of gcc. >>> Older versions of the compiler cared where the -l options went on the linkline.
If they were in the wrong place the object files wouldn't link properly. >>> Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that
reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago.[SNIP]
Not really, it still applies on AIX, HP-UX, and Solaris, which are all
very much standard UNIX.
Rainer Weikusat <rweikusat@talktalk.net> wrote:
That's a BSD-originated function some POSIX versions reportedly
defined. According to the Linux bzero(3) manpage,
4.3BSD. This function is deprecated (marked as LEGACY in
POSIX.1-2001): use memset(3) in new programs. POSIX.1-2008
removes the specification of bzero().
Well, deprecated or not, it won't be going away for a long time. Also passing 2 arguments instead of 3 is more efficient in time critical loops (which doesn't apply to my program but just saying).
On Thu, 18 Feb 2016 15:14:28 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
nrjbasic@nrjbasic.xx.uk writes:
Last time I encountered that error was in gcc 3.x. We're a bit past that >>> version now. Since both gcc and clang have dumped that restriction I think >>> its fair to say its now been realised that it was a stupid idea with little >>> merit.
That's besides the point: Existing tools behave in this way. It's easy
to support.
Since its no effort I'll modify the Makefile on the next release but its
an annoying gotcha which really should be done away with.
That's a BSD-originated function some POSIX versions reportedly
defined. According to the Linux bzero(3) manpage,
4.3BSD. This function is deprecated (marked as LEGACY in
POSIX.1-2001): use memset(3) in new programs. POSIX.1-2008
removes the specification of bzero().
Well, deprecated or not, it won't be going away for a long time. Also passing >2 arguments instead of 3 is more efficient in time critical loops (which >doesn't apply to my program but just saying).
These parameters would be passed in registers on most architectures
(x86, x86_64, mips, sparc, arm/arm64)
On 18/02/2016 17:01, Scott Lurndal wrote:
These parameters would be passed in registers on most architectures
(x86, x86_64, mips, sparc, arm/arm64)
May I pick a nit? :-)
Unless one uses a distribution which allows building *everything*
from source with custom flags (-mregparm=num), the x86 ABI requires
passing parameters through the stack.
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/i386-and-x86-64-Options.html#index-mregparm-1604
https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions
On 18/02/2016 17:01, Scott Lurndal wrote:
These parameters would be passed in registers on most architectures
(x86, x86_64, mips, sparc, arm/arm64)
May I pick a nit? :-)
Unless one uses a distribution which allows building *everything*
from source with custom flags (-mregparm=num), the x86 ABI requires
passing parameters through the stack.
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/i386-and-x86-64-Options.html#index-mregparm-1604
https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions
Regards.
Noob wrote:
On 18/02/2016 17:01, Scott Lurndal wrote:
These parameters would be passed in registers on most architectures
(x86, x86_64, mips, sparc, arm/arm64)
May I pick a nit? :-)
Unless one uses a distribution which allows building *everything*
from source with custom flags (-mregparm=num), the x86 ABI requires
passing parameters through the stack.
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/i386-and-x86-64-Options.html#index-mregparm-1604
https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions
The 64-bit x86 psABI passes the first five parameters in registers.
jt@toerring.de (Jens Thoms Toerring) writes:
[...]
Note also that casting the return value of malloc() (or
calloc() or realloc()) can be a bad idea - if you forget to
include <stdlib.h> and you're on a machine with dedicated
data and address registers it introduces a hard to find bug.
The more common problem would be sizeof(int) != sizeof(void *), the
former being 4 and the latter 8.
Note also that casting the return value of malloc() (or
calloc() or realloc()) can be a bad idea - if you forget to
include <stdlib.h> and you're on a machine with dedicated
data and address registers it introduces a hard to find bug.
On Wed, 17 Feb 2016 18:24:32 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I >>can only assume you don't have libm installed or its not in a standard >>location or another alternative is you have an old buggy version of gcc. >>Older versions of the compiler cared where the -l options went on the link >line.
If they were in the wrong place the object files wouldn't link properly. >>Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that >reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago. A
decent compiler should not care about the order the libraries are listed in, it should parse the entire command line first before linking.
In main.c() in the init() function you can replace all of
int size;
size = sizeof(st_keybline) * num_keyb_lines;
assert((keyb_line = (st_keybline *)malloc(size)));
bzero(keyb_line,size);
by just
assert(keyb_line = calloc(num_keyb_lines, sizeof *keyb_line);
Note also that casting the return value of malloc() (or
calloc() or realloc()) can be a bad idea - if you forget to
include <stdlib.h> and you're on a machine with dedicated
data and address registers it introduces a hard to find bug.
Jens Thoms Toerring wrote:
In main.c() in the init() function you can replace all of
int size;
size = sizeof(st_keybline) * num_keyb_lines;
assert((keyb_line = (st_keybline *)malloc(size)));
bzero(keyb_line,size);
by just
assert(keyb_line = calloc(num_keyb_lines, sizeof *keyb_line);
DO NOT PUT CODE IN ASSERT STATEMENTS, as these will be removed when de program is compiled with -DNDEBUG.
On 2016-02-20, Jens Thoms Toerring <jt@toerring.de> wrote:
Note also that casting the return value of malloc() (or
calloc() or realloc()) can be a bad idea - if you forget to
include <stdlib.h> and you're on a machine with dedicated
data and address registers it introduces a hard to find bug.
This reasoning is years obsolete.
The situation you describe indicates that the compiler isn't diagnosing
calls to functions that have not been declared with a prototype, or at
all.
The fact that this is caught when the return value of a function
is assigned to a pointer is a lucky coincidence which doesn't
generalize.
In comp.unix.programmer nrjbasic@nrjbasic.xx.uk wrote:
On Wed, 17 Feb 2016 18:24:32 GMT
I think that particular rule went out the window a long time ago. A
decent compiler should not care about the order the libraries are listed in, >> it should parse the entire command line first before linking.
That rule never "went out of the window", it still holds on
the Linux systems I have. By the way it's the linker and not
the compiler that's doing the work here - if you use gcc it's
just a front end that first invokes the compiler on your source
files and/or the linker, depending on how gcc was invoked.
If the order of the libraries wouldn't matter sometimes im-
portant tricks wouldn't be possible anymore. E.g. if you need
to "overload" a function from a library you can create your
In article <20160220100434.506@kylheku.com>,
Kaz Kylheku <330-706-9395@kylheku.com> wrote:
On 2016-02-20, Jens Thoms Toerring <jt@toerring.de> wrote:
Note also that casting the return value of malloc() (or
calloc() or realloc()) can be a bad idea - if you forget to
include <stdlib.h> and you're on a machine with dedicated
data and address registers it introduces a hard to find bug.
This reasoning is years obsolete.
The situation you describe indicates that the compiler isn't diagnosing >>calls to functions that have not been declared with a prototype, or at
all.
The fact that this is caught when the return value of a function
is assigned to a pointer is a lucky coincidence which doesn't
generalize.
You just gotta love this thread. Usenet at its finest.
30+ responses and not one single post having anything to do with the BASIC language (which is what this thread is supposed to be about).
On 20 Feb 2016 14:11:33 GMT
jt@toerring.de (Jens Thoms Toerring) wrote:
In comp.unix.programmer nrjbasic@nrjbasic.xx.uk wrote:
On Wed, 17 Feb 2016 18:24:32 GMT
I think that particular rule went out the window a long time ago. A
decent compiler should not care about the order the libraries are listed in,
it should parse the entire command line first before linking.
That rule never "went out of the window", it still holds on
the Linux systems I have. By the way it's the linker and not
the compiler that's doing the work here - if you use gcc it's
just a front end that first invokes the compiler on your source
files and/or the linker, depending on how gcc was invoked.
If the order of the libraries wouldn't matter sometimes im-
portant tricks wouldn't be possible anymore. E.g. if you need
to "overload" a function from a library you can create your
And how often do people want to do tricks like that compared to just
wanting their programs to link?
If there are rare situations where library
order matters then it would be simple to implement a command line switch to enable it.
In comp.unix.programmer Gary R. Schmidt <grschmidt@acm.org> wrote:
On 18/02/2016 8:45 PM, nrjbasic@nrjbasic.xx.uk wrote:
On Wed, 17 Feb 2016 18:24:32 GMT[SNIP]
scott@slp53.sl.home (Scott Lurndal) wrote:
nrjbasic@nrjbasic.xx.uk writes:
These are all standard maths functions so if they're not defined then I >> >>> can only assume you don't have libm installed or its not in a standard >> >>> location or another alternative is you have an old buggy version of gcc. >> >>> Older versions of the compiler cared where the -l options went on the linkline.
If they were in the wrong place the object files wouldn't link properly. >> >>> Perhaps trying putting -lm at the end?
Yes. With all standard unix linkers, -lm should follow any objects that >> >> reference the math library functions. That's a bug in your makefile.
I think that particular rule went out the window a long time ago.
Not really, it still applies on AIX, HP-UX, and Solaris, which are all
very much standard UNIX.
And I got the same problem when linking on Ubuntu 14.04 with gcc
version 4.8. So it hasn't "gone out of the window a long time ago",
it's well alive on not too ancient Linux systems.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 68:02:35 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,268 |