• NRJ-BASIC v1

    From nrjbasic@nrjbasic.xx.uk@21:1/5 to All on Wed Feb 17 09:45:39 2016
    XPost: comp.unix.programmer

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gamo@21:1/5 to All on Wed Feb 17 14:45:52 2016
    XPost: comp.unix.programmer

    El 17/02/16 a las 10:45, nrjbasic@nrjbasic.xx.uk escribió:
    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.


    --
    http://gamo.eu.pn/
    The generation of random numbers is too important to be left to chance

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nrjbasic@nrjbasic.xx.uk@21:1/5 to gamo on Wed Feb 17 15:08:59 2016
    XPost: comp.unix.programmer

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nrjbasic@nrjbasic.xx.uk@21:1/5 to gamo on Wed Feb 17 17:01:35 2016
    XPost: comp.unix.programmer

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gamo@21:1/5 to All on Wed Feb 17 17:17:40 2016
    XPost: comp.unix.programmer

    El 17/02/16 a las 16:08, nrjbasic@nrjbasic.xx.uk escribió:
    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?


    :~/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


    --
    http://gamo.eu.pn/
    The generation of random numbers is too important to be left to chance

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cholo Lennon@21:1/5 to gamo on Wed Feb 17 13:55:31 2016
    XPost: comp.unix.programmer

    On 02/17/2016 01:17 PM, gamo wrote:
    El 17/02/16 a las 16:08, nrjbasic@nrjbasic.xx.uk escribió:
    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?


    :~/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



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

    Regards

    --
    Cholo Lennon
    Bs.As.
    ARG

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nrjbasic@nrjbasic.xx.uk@21:1/5 to Scott Lurndal on Thu Feb 18 09:45:31 2016
    XPost: comp.unix.programmer

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to nrjbasic@nrjbasic.xx.uk on Thu Feb 18 14:24:41 2016
    XPost: comp.unix.programmer

    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.

    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"



    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gamo@21:1/5 to All on Wed Feb 17 18:29:42 2016
    XPost: comp.unix.programmer

    El 17/02/16 a las 18:01, nrjbasic@nrjbasic.xx.uk escribió:
    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.




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

    --
    http://gamo.eu.pn/
    The generation of random numbers is too important to be left to chance

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nrjbasic@nrjbasic.xx.uk@21:1/5 to Scott Lurndal on Thu Feb 18 14:36:49 2016
    XPost: comp.unix.programmer

    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. You might as well make the order of the lib paths and object files matter too if you go down that road.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary R. Schmidt@21:1/5 to nrjbasic@nrjbasic.xx.uk on Fri Feb 19 01:55:08 2016
    XPost: comp.unix.programmer

    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 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.
    [SNIP]
    Not really, it still applies on AIX, HP-UX, and Solaris, which are all
    very much standard UNIX.

    Cheers,
    Gary B-)


    --
    When men talk to their friends, they insult each other.
    They don't really mean it.
    When women talk to their friends, they compliment each other.
    They don't mean it either.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to nrjbasic@nrjbasic.xx.uk on Thu Feb 18 15:14:28 2016
    XPost: comp.unix.programmer

    nrjbasic@nrjbasic.xx.uk writes:
    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.

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

    [...]

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nrjbasic@nrjbasic.xx.uk@21:1/5 to Rainer Weikusat on Thu Feb 18 15:23:35 2016
    XPost: comp.unix.programmer

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to nrjbasic@nrjbasic.xx.uk on Thu Feb 18 15:53:01 2016
    XPost: comp.unix.programmer

    ["Followup-To:" header set to comp.unix.programmer.]
    On 2016-02-18, nrjbasic@nrjbasic.xx.uk <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 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,

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

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

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to nrjbasic@nrjbasic.xx.uk on Wed Feb 17 18:24:32 2016
    XPost: comp.unix.programmer

    nrjbasic@nrjbasic.xx.uk writes:
    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?


    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jens Thoms Toerring@21:1/5 to Gary R. Schmidt on Thu Feb 18 20:00:25 2016
    XPost: comp.unix.programmer

    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
    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.
    [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
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Baeuerle@21:1/5 to nrjbasic@nrjbasic.xx.uk on Thu Feb 18 17:35:56 2016
    XPost: comp.unix.programmer

    nrjbasic@nrjbasic.xx.uk wrote:
    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).

    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]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to nrjbasic@nrjbasic.xx.uk on Thu Feb 18 16:01:45 2016
    XPost: comp.unix.programmer

    nrjbasic@nrjbasic.xx.uk writes:
    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.

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

    If you want portability, follow the POSIX recommendation.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to Scott Lurndal on Fri Feb 19 11:28:25 2016
    XPost: comp.unix.programmer

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Noob on Fri Feb 19 14:04:32 2016
    XPost: comp.unix.programmer

    Noob <root@127.0.0.1> writes:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Noob on Fri Feb 19 14:00:38 2016
    XPost: comp.unix.programmer

    Noob <root@127.0.0.1> writes:
    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to Scott Lurndal on Fri Feb 19 16:03:25 2016
    XPost: comp.unix.programmer

    On 19/02/2016 15:04, Scott Lurndal wrote:

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jens Thoms Toerring@21:1/5 to Rainer Weikusat on Sat Feb 20 21:39:54 2016
    XPost: comp.unix.programmer

    In comp.unix.programmer Rainer Weikusat <rweikusat@talktalk.net> wrote:
    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.

    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.

    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Jens Thoms Toerring on Sat Feb 20 14:44:10 2016
    XPost: comp.unix.programmer

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jens Thoms Toerring@21:1/5 to nrjbasic@nrjbasic.xx.uk on Sat Feb 20 14:11:33 2016
    XPost: comp.unix.programmer

    In comp.unix.programmer 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 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.

    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
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Huibert Bol@21:1/5 to Jens Thoms Toerring on Sun Feb 21 00:09:13 2016
    XPost: comp.unix.programmer

    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.

    --
    Huibert
    "Okay... really not something I needed to see." --Raven

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Jens Thoms Toerring on Sun Feb 21 04:25:03 2016
    XPost: comp.unix.programmer

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Huibert Bol on Sun Feb 21 08:49:36 2016
    XPost: comp.unix.programmer

    Huibert Bol <huibert.bol@vodafonethuis.nl> writes:
    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.

    The alternative view is DO NOT DEFINE NDEBUG.

    --
    http://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to 330-706-9395@kylheku.com on Mon Feb 22 01:11:40 2016
    XPost: comp.unix.programmer

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

    Love it!

    --
    Both the leader of the Mormon Church and the leader of the Catholic
    church claim infallibility. Is it any surprise that these two orgs
    revile each other? Anybody with any sense knows that 80-yr old codgers
    are hardly infallible. Some codgers this age do well to find the crapper
    in time and remember to zip-up.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From spud@potato.field@21:1/5 to Jens Thoms Toerring on Mon Feb 22 09:38:15 2016
    XPost: comp.unix.programmer

    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.

    --
    Spud

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Kenny McCormack on Mon Feb 22 17:00:52 2016
    XPost: comp.unix.programmer

    On 2016-02-22, Kenny McCormack <gazelle@shell.xmission.com> wrote:
    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).

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jens Thoms Toerring@21:1/5 to spud@potato.field on Mon Feb 22 17:04:12 2016
    XPost: comp.unix.programmer

    In comp.unix.programmer spud@potato.field wrote:
    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?

    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.

    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
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Jens Thoms Toerring on Wed Feb 24 12:47:20 2016
    XPost: comp.unix.programmer

    jt@toerring.de (Jens Thoms Toerring) writes:
    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
    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.
    [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.

    --
    Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)