djw-zr/zr

ZR : a GNU/OpenGL Train Simulator : Based on OpenRails and MSTS

zr's Issues

fcaseopen.c buffer overflow

Hi!

Whilst trying to open a file case-insensitively I came across a codebase that seemed to do the job. But clang's address sanitizer was having none of it! It turns out that there is an off by one error in the buffer size allocation of fcaseopen causing a null terminator to be strcpy'd into unmanaged memory. I reported the problem to the original project but I decided I'd also let everyone I could find who still had the vulnerability floating around copies of it know as well.

You can find more information about it here: OneSadCookie/fcaseopen#2

p.s. cool project I like trains

Thanks,
Aaron.

Generating Forests

The problem is to add forests to the ZR version of the OpenRails train simulator. ZR is written in C whereas OpenRails, one of the most developed train simulators, bit it is written in C# and so cannot be easily transported to other operating systems.

The project will require learning about the way information about the position of shapes (houses, bridges, etc.) is stored in linked lists within ZR. It will also require generating the random position of trees and placing the corresponding tree shapes within the landscape.

Generating Forests

1. Forests

Forests are rectangular regions specified by an origin, width and height (probably the easterly and northerly extents). The number of trees (population) is also defined these should be placed randomly within the forest area but not impinge on any rail or road tracks.

The shape associated with each forest is the shape of the tree within the forest (unfortunately these all seem to be of the same type and size).

In program ZR, all the basic data files are read in a series of subroutine calls collected within routine 'init_data_structures()' in file 'data.c'.  At the end of this process, all the data on scenary objects are collected in a linked list of Worlditem structures (world.d).

The whole of the region modelled is split into tiles (size often 1024m by 1024m).  Each tile has its own WorldNode (world.h).  This contains a pointer to the first node in the linked list of WorldItems for that tile.

2. Requirement

   A routine to cycle over all the world nodes and world items looking for world items with worldtype equal to FOREST (defined in enum.h).

   It then needs to randomly generate the trees within the forest and check that they are not too near each other, or near to roads and tracks.

   The random distribution could be done using a good random number generator but the quasi-random generator in Chapter 7 of Numerical Recipies by Press, Teukilsky, Vetterling and Flannery (Cambridge University Press) has some interesting properties.

   Each tree position should then be used to add a new world item to the list. This should have the same shape as the forest but with a new position and possible a new random orientation.

   A possible complication is that the trees may need to be raised or lowed to follow the topography.

3. Possible work plan

   You should first try compiling ZR and trying it out on the zig-zag route and if possible, some of the standard MSTS routes.

   I would the suggest adding a routine call around line 520 of file data.c, to process forest objects and develop the rest of teh code from this routine, The routine should initially scan through the tiles and items, (see the code following "Loop over tiles" in display.c) looking for items of type 'FOREST'.

   Routine 'list_wfile_item()' can then be used to list some of the data for each forest. Additional print statements will be needed for data in the ForestObj section of the WorldItem structure. From then on it is a matter of using the data to construct the forest.

lex.yy.c compilation errors

Context: Linux Mint 21.1, gcc 11.3.0, ld 2.38, make 4.3; ZR version 0.6.

When compiling the code, I receive 3 error messages, all directly or indirectly referring to lex.yy.c:

/usr/bin/ld: lex.yy.o:/home/mmg/Documents/projects/C_projects/ZeroRails/ZR/lex.yy.c:326: multiple definition of `yyin'; sigscr.o:/home/mmg/Documents/projects/C_projects/ZeroRails/ZR/src/input/sigscr.c:92: first defined here
/usr/bin/ld: lex.yy.o:/home/mmg/Documents/projects/C_projects/ZeroRails/ZR/lex.yy.c:326: multiple definition of `yyout'; sigscr.o:/home/mmg/Documents/projects/C_projects/ZeroRails/ZR/src/input/sigscr.c:92: first defined here
/usr/bin/ld: lex.yy.o:/home/mmg/Documents/projects/C_projects/ZeroRails/ZR/bas.l:57: multiple definition of `string'; zr.o:/home/mmg/Documents/projects/C_projects/ZeroRails/ZR/src/input/load_wagon_file.c:26: first defined here`

As last time I dealt with Lex/Yacc was 30+ years ago, I no longer have an idea of what it is actually happening.

The first two errors seem clear: yyin and yyout are actually defined in both files (input/lex.yy.c and input/sigscr.c); as in input/sigscr.c yyin and yyout are only used in the int read_sigscr_file(char*, char*) function, the two variables could be moved there from the global position and those two errors would go away.

But the third is quite unclear to me: I tried renaming the variable defined in input/load_wagon_file.c, but whatever I put there, it also pops up in input/lex.yy.c (which it then presumably generated by some compilation pass not obvious from the makefile). So there must be something else going on I don't understand, potentially relating to the first two errors too.

Any suggestion to reach a successful compilation is welcome!