NRJ-BASIC v1

[n***@nrjbasic.xx.uk]

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.

[gamo]

Post by n***@nrjbasic.xx.uk
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.
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.

[n***@nrjbasic.xx.uk]

On Wed, 17 Feb 2016 14:45:52 +0100

Post by gamo
Does not compile in Linux.

Did you follow the instructions in the README and uncomment the correct
line in the Makefile for linux?

[gamo]

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 14:45:52 +0100

Post by gamo
Does not compile in Linux.

Did you follow the instructions in the README and uncomment the correct
line in the Makefile for linux?

:~/src/BASIC/basic/src$ make
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

[Cholo Lennon]

Post by gamo

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 14:45:52 +0100

Post by gamo
Does not compile in Linux.

Did you follow the instructions in the README and uncomment the correct
line in the Makefile for linux?

:~/src/BASIC/basic/src$ make
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: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: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
/home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
/home/jesus/src/BASIC/basic/src/functions.c:182: referencia a `floor'
sin definir
/home/jesus/src/BASIC/basic/src/functions.c:191: referencia a `ceil' sin
definir
/home/jesus/src/BASIC/basic/src/functions.c:200: referencia a `sqrt' sin
definir
/home/jesus/src/BASIC/basic/src/functions.c:209: referencia a `pow' sin
definir
/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
/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
/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
/home/jesus/src/BASIC/basic/src/functions.c:305: referencia a `hypot'
sin definir
/home/jesus/src/BASIC/basic/src/functions.c:1947: referencia a `crypt'
sin definir
/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

In my computer, it compiles ok (openSUSE 13.1 x86_64, gcc 4.8.1)

Regards

[n***@nrjbasic.xx.uk]

On Wed, 17 Feb 2016 17:17:40 +0100

Post by gamo
program.o disk.o draw.o misc.o -o basic
/home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
/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.

[gamo]

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 17:17:40 +0100

Post by gamo
program.o disk.o draw.o misc.o -o basic
/home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
/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.

That's it. $(LIBS) need to be moved to the end of line in the Makefile.
Thanks.

[Scott Lurndal]

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 17:17:40 +0100

Post by gamo
program.o disk.o draw.o misc.o -o basic
/home/jesus/src/BASIC/basic/src/functions.c:173: referencia a `round'
sin definir
/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?

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.

[n***@nrjbasic.xx.uk]

On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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.

Post by Scott Lurndal
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.

Post by Scott Lurndal
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.

It was actually developed on 64 bit, but your point is noted. I'll probably
update the code to use map() at some point.

[Scott Lurndal]

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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.

POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

" library shall be searched when its name is encountered, so the placement
of a -l option is significant"

Post by n***@nrjbasic.xx.uk

Post by Scott Lurndal
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.

ANSI C defines memset. It doesn't define bzero. I've used systems
where bzero wasn't available.

[n***@nrjbasic.xx.uk]

On Thu, 18 Feb 2016 14:24:41 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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. You might as well make the order of the lib paths and object files
matter too if you go down that road.

Post by Scott Lurndal
ANSI C defines memset. It doesn't define bzero. I've used systems
where bzero wasn't available.

Posix defines bzero. Since this program was written specifically for unix, not
windows or any other OS, so I don't particularly care about strict ansi C.
Also ITYF ANSI C doesn't define quite a few posix specific functions I've used
in the code.

[Rainer Weikusat]

Post by n***@nrjbasic.xx.uk
On Thu, 18 Feb 2016 14:24:41 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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.

That's besides the point: Existing tools behave in this way. It's easy
to support.

[...]

Post by n***@nrjbasic.xx.uk

Post by Scott Lurndal
ANSI C defines memset. It doesn't define bzero. I've used systems
where bzero wasn't available.

Posix defines bzero.

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().

[n***@nrjbasic.xx.uk]

On Thu, 18 Feb 2016 15:14:28 +0000

Post by Rainer Weikusat

Post by n***@nrjbasic.xx.uk
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.

Post by Rainer Weikusat
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).

[Scott Lurndal]

Post by n***@nrjbasic.xx.uk
On Thu, 18 Feb 2016 15:14:28 +0000

Post by Rainer Weikusat

Post by n***@nrjbasic.xx.uk
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.

There are many compilers other than GCC/Binutils in widespread use.

If you want portability, follow the POSIX recommendation.

Post by n***@nrjbasic.xx.uk

Post by Rainer Weikusat
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).

Nonsense. At worse you may add a cycle to the loop, but more likely
it will be subsumed by load-to-use penalties, dual issue and/or out-of order
execution. These parameters would
be passed in registers on most architectures (x86, x86_64, mips, sparc,
arm/arm64) and most of them have a simple way of generating a register containing
zero (xor %reg,%reg on x86, xzr on arm64, r0 on 88100, et alia).

[Noob]

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.

[Scott Lurndal]

Post by Noob

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.

[Scott Lurndal]

Post by Noob

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.

[Noob]

Post by Noob

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.

You wrote "x86, x86_64, [...]" so you're aware that, in this context,
x86 (aka i386, aka IA-32) refers to the 32-bit ISA.

Also, I'm not sure which psABI you have in mind, but the "System V
AMD64 ABI" passes the first 6 parameters in registers (RDI, RSI,
RDX, RCX, R8, R9).

Regards.

[Michael Baeuerle]

Post by n***@nrjbasic.xx.uk

Post by Rainer Weikusat
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).

As stated in the Linux man page: It is already gone and was removed from
POSIX.1:
<http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap03.html#tag_22_03_01_04>
Expect that the "strings.h" header file don't expose it anymore on
compliant systems if "_POSIX_C_SOURCE" is defined to 200809L.

The former LEGACY definition specified it as part of the X/Open XSI
extension (not POSIX.1 base):
<http://pubs.opengroup.org/onlinepubs/009695399/functions/bzero.html>
and announced that it will be withdrawn.

For portability 'memset()' really should be the better option.


[Xpost and Fup2 comp.unix.misc]

[Gary R. Schmidt]

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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.

Cheers,
Gary B-)

[Jens Thoms Toerring]

Post by Gary R. Schmidt

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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.

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.

Regards, Jens

[Keith Thompson]

Post by Jens Thoms Toerring

Post by Gary R. Schmidt

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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.

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.

On my Ubuntu 14.04.4 system, gcc 4.8.4 (the default version) requires
the "-lm" to follow the source or object that uses it, but gcc 5.3.0
(which I installed from source) does not.

Allowing libraries to be specified in any order is probably a great
idea, but since the default gcc provided by the latest long-term support
release of Ubuntu doesn't support it, it's probably not a good idea to
depend on it -- especially since it's so easy to specify an order that
works with both older and newer implementations.

[Kaz Kylheku]

["Followup-To:" header set to comp.unix.programmer.]

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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,

The rule is required so that once a library archive is processed,
its symbolic information can be freed. Effectively, the linker needs to
load the symbol tables of each library just one at a time.

Read next lib and its symbols. Patch earlier references to the lib.
Discard symbols. Repeat.

This helps with large link jobs, which is probably why the Linux kernel
switched to building and linking archives.

Note that .o object files are all considered together; the rule applies
to libraries only.

If you have huge link job of thousands of .o files, you can reduce its
memory use and speed it up by arranging the .o files into .a archives,
and presenting them to the linker in the proper anti-dependency order
(uses first, definitons later).

Post by n***@nrjbasic.xx.uk
it should parse the entire command line first before linking.

The GNU linker has special options with which you can bracket a group of
archives on the command line so that they are considered all together.
It's for situations when there are circular references:

ld ... --start-group foo.a bar.a --end-group

These grouping options are also spelled -( ... -) (dash paren).

Post by n***@nrjbasic.xx.uk
Yes the bzero is a bug, but its old code that should have been removed. If

C has had memset since ANSI C in 1989.

[Jens Thoms Toerring]

Post by n***@nrjbasic.xx.uk
On Wed, 17 Feb 2016 18:24:32 GMT

Post by Scott Lurndal

Post by n***@nrjbasic.xx.uk
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.

Post by n***@nrjbasic.xx.uk
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.

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
own library with the replacement function and the linker will
pick that up if you specify your library before the library
that contains the original function. But for that to work it
is necessary that the order the libraries are listed does
matter. If the linker would go through the libraries in some
random or unspecified order you could never be sure which
version of the function gets picked.

BTW, you could make your Makefile a lot simpler if you replace
all those lines like

keyboard.o: keyboard.c globals.h Makefile
$(CC) $(ARGS) keyboard.c

by

%.o: %.c globals.h Makefile
$(CC) $(ARGS) $^

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.
The only reason sometimes given for casting the return value
of malloc() etc. is to allow compilation with a C++ compiler
since C++ doesn't do implicit conversions from void *, but
when you use C++ you probably better use the new operator. And
then your code can't be compiled with a C++ compiler anyway,
see below.

Another point: In globals.h you actually define (not just
declare) a lot of variables, starting at line 1437, and then
include that header file in several source files. This re-
sults in independent definitions of variables of the same
names in all the source files that include globals.h. This
is something C lets you get away with (as long as the
variables defined that way aren't also initialized) but,
should you ever move to C++, it won't work at all since
there's a hard rule in C++ that each variable may only have
a single definition.

Oh, and finally: Declaring a function as e.g.

void init();

does not declare it to not accept any argunents. It tells the
compiler that init() takes an unspecified number of arguments
and keeps it from warning you if you try to call such a func-
tion with arguments (that's another difference to C++). So
better always use "void" in the argument list of a function
declaration/definition if the function isn't supposed to
accept arguments.
Regards, Jens

[Rainer Weikusat]

***@toerring.de (Jens Thoms Toerring) writes:

[...]

Post by Jens Thoms Toerring
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.

[Jens Thoms Toerring]

Post by Rainer Weikusat
[...]

Post by Jens Thoms Toerring
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.

Yup, that's another way it can go wrong... The problem on systems
with dedicated address and data registers got stuck in my mind
because I had a lot of "fun" tracking down such a bug on a m68k
system many moons ago.

[Huibert Bol]

Post by Jens Thoms Toerring
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.

[Richard Kettlewell]

Post by Huibert Bol

Post by Jens Thoms Toerring
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.

The alternative view is DO NOT DEFINE NDEBUG.

[Kaz Kylheku]

Post by Jens Thoms Toerring
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.

[Kenny McCormack]

Post by Kaz Kylheku

Post by Jens Thoms Toerring
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).

Love it!

[Kaz Kylheku]

Post by Kenny McCormack

Post by Kaz Kylheku

Post by Jens Thoms Toerring
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).

The only thing that can remotely be interesting about BASIC is how a C
implementation of it builds. :)

I quit BASIC while still in puberty.

I don't want to discuss BASIC, do you?

[s***@potato.field]

On 20 Feb 2016 14:11:33 GMT

Post by Jens Thoms Toerring

Post by n***@nrjbasic.xx.uk
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.

--
Spud

[Kenny McCormack]

In article <naeku7$1hot$***@gioia.aioe.org>, <***@potato.field> wrote:
...

Post by s***@potato.field
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.

Don't you think it would be better to start your own thread to discuss
arcane subjects like this? What does any of this have to do with BASIC?

[s***@potato.field]

On Mon, 22 Feb 2016 10:11:13 +0000 (UTC)

Post by Kenny McCormack
....

Post by s***@potato.field
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.

Don't you think it would be better to start your own thread to discuss
arcane subjects like this? What does any of this have to do with BASIC?

You must be new to usenet.

--
Spud

[Jens Thoms Toerring]

Post by s***@potato.field
On 20 Feb 2016 14:11:33 GMT

Post by Jens Thoms Toerring

Post by n***@nrjbasic.xx.uk
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?

I can't say since I have no encyclopedic knowledge of all
programs in existence;-) But, in my experience, if there's
a feature that can be used for difficult cases it's going to
be used.

Post by s***@potato.field
If there are rare situations where library
order matters then it would be simple to implement a command line switch to
enable it.

And break all existing Makefiles etc. that rely on this behaviour
which stayed the same for a couple of decades? Another problem is
that this would require two rather different "linker modes". Is
all that work (including now having to maintain two banches of
the linker code) really justified just to allow having the li-
braries at a random position in the command line instead of the
end, with the more "fundamental" ones further back? I don't think
it's really rocket science - you get bitten by it once and then
you know where the libraries have to go...

Regards, Jens