This is a much better name for it.
Time permitting.
Isn't alloca how local variables are allocated on the stack? I've always used (variable length) arrays of chars for buffers, ex:
char temp[1000] = {0}; // should be the same with alloca & setting everything to 0char temp[n] = {0}; // same thing
Yes.
Depends on the operational parameters of the system. In production, our old pattern used to be: identify problem -> triage -> if urgently needed, hackfix -> schedule improvement -> develop improvement -> test. The "quick fix" branch of logic will be logically proportionate to the impact of the issue. Duct tape may stop a minor leak until you can turn the water system off to fix a problem, or maybe not if the leaky pipe is pressured.
Generally well-intentioned. The question with a "temporary string buffer" is "just how much do I actually need?". You can blow your stack limit rather quickly trying to mangle a 1MB string in certain ways. OTOH, maybe you're dealing with filenames so you know PATH_MAX, and you only need ~4K.
I'm naming my kid SELECT * FROM Main WHERE Name=""; DROP TABLE *; -- "
I ended up looking into it more after I first posted and yeah, the only difference I guess is that you're less likely to try and return the pointer?
For me it's usually when I'm trying to format my own structs as strings or whatever, there are times snprintf or strncat on an existing buffer just aren't enough
I can't imagine how much pain this guy goes through on the regular. He must have all kinds of trouble with banks.
It reminds me of this story from a few years ago: https://www.wired.com/story/null-license-plate-landed-one-hacker-ticket-hell/, https://archive.is/R1FMz
C headers are just interface declarations. You can split your code over however many files you want in C, so long as the declaration order makes sense to the compiler. You can even put each function into its own file, its encouraged for library type code if not all functions are expected to be used, like glibc, resulting in the linker only pulling in the object it needs without requiring LTO analysis. In Java, the compiler scans the class files for how a method is declared in a class. In C, that information comes from header files. Same for C++, which chromium is infamous for because its a big fat piece of shit code.
Its fast but the danger is that there is no way to communicate a failure, like running out of stack space and colliding with other data. It NEVER returns NULL, especially dangerous if you use recursive calls.
If you know the size of an array ahead of time and you're not doing any multithreading, you can just declare the array outside the function scope to avoid stack problems completely. Be sure to memset it as necessary, or just use static if you're using it just once.
I always get worried with variable length arrays in the stack, since its the prime candidate for stack spraying and smashing attacks. It can result in program control being passed to arbitrary functions.
def generate_map():
#This creates a map filled with walls to be carved later
game_map = [[TILES["WALL"] for _ in range(MAP_WIDTH)] for _ in range(MAP_HEIGHT)]
# this stores the rooms
all_rooms = []
num_random_rooms = random.randint(10, 20) # Adjust as needed
# generates the rooms
for _ in range(num_random_rooms): #sets the ammount of rooms per floor may make random later but for now we move
width = random.randint(4,8)
height = random.randint(4,8)
x = random.randint(1, MAP_WIDTH - width - 1)
y = random.randint(1, MAP_HEIGHT - height - 1)
new_room = {"x":x, "y":y, "width": width, "height": height}
#checks for any over laps before placing the rooms hence the omega long parameter
#the any parameter checks if all the conditions inside it to see if any are true or false
if not any(
(new_room["x"] < room["x"] + room["width"] and
new_room["x"] + new_room["width"] > room["x"] and
new_room["y"] < room["y"] + room["height"] and
new_room["y"] + new_room["height"] > room["y"])
for room in all_rooms
):
#this is wwhat carves/ places the rooms with athe help of the dreaded nested for loop (doctos)
for y in range(new_room["y"], new_room["y"] + new_room["height"]):
for x in range(new_room["x"], new_room["x"] + new_room["width"]):
game_map[y][x] = TILES["FLOOR"]
all_rooms.append(new_room)
#this is what connects the rooms wth corridors
for i in range (1, len(all_rooms)):
# is i-1 because its the previous room, could also have made it so the current room is i +1 and make prev room be i but that makes less sense intuitively
prev_room = all_rooms[i -1]
curr_room = all_rooms[i]
#grabs the centers of each room so we knwo where to put the corridors
#standard stuff getting middle by adding and then dividing by 2 really if you need this reminder comment you should n be programming and should consider killing yourself
prev_center = (prev_room["x"]+ prev_room["width"] // 2, prev_room["y"] +prev_room["height"] // 2)
curr_center = (curr_room["x"] + curr_room["width"] // 2, curr_room["y"] +curr_room["height"] // 2)
#magic that makes the horizontal corridor
for x in range (min(prev_center[0], curr_center[0]), max(prev_center[0], curr_center[0])+ 1):
game_map[prev_center[1]][x] = TILES["FLOOR"]
#^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ vertical corridor
for y in range (min(prev_center[1], curr_center[1]), max(prev_center[1], curr_center[1])+ 1):
game_map[y][curr_center[0]] = TILES["FLOOR"]
return game_map
This is the thread, until someone gets to work on KiwiOverflow...
#magic that makes the horizontal corridor
(+) has_put_door = False
for x in range (min(prev_center[0], curr_center[0]), max(prev_center[0], curr_center[0])+ 1):
(+) if game_map[prev_center[1]][x] == TILES["WALL"] and not has_put_door:
(+) has_put_door = True
(+) game_map[prev_center[1]][x] = TILES["DOOR"]
(+) else:
(~) game_map[prev_center[1]][x] = TILES["FLOOR"]################################################################################
################################################################################
################################################################################
############################################################# ###############
############################################################# ###############
################################## #################### ###############
################################## ########## ###############
################################## + ###############
################################## ####### ###### ###############
######### #################### ####### #### # ################
######### ################################## #### # ################
######### ################################## #### # ################
######### + ################
######### ########### ##################
######### ########### ################################ ##################
########### ############# ################# ########## ##################
########### ########### ############### ########## ##################
########### ########### ############### ################################
########### ################################
####################### + ################################
####################### ############### ################################
####################### ####################################################
####################### ####################################################
################################################################################I know that this isn't in Python and uses a different structure than what you're doing but here's what I'm using
fn door_possible(&self, build_data : &mut BuilderMap, idx : usize) -> bool {
let mut blocked = false;
for spawn in build_data.spawn_list.iter() {
if spawn.0 == idx { blocked = true; }
}
if blocked { return false; }
let x = (idx % build_data.map.width as usize) as i32;
let y = (idx / build_data.map.width as usize) as i32;
// Check for east-west door possibility
if build_data.map.tiles[idx] == TileType::Floor &&
(x > 1 && build_data.map.tiles[idx-1] == TileType::Floor) &&
(x < build_data.map.width-2 && build_data.map.tiles[idx+1] == TileType::Floor) &&
(y > 1 && build_data.map.tiles[idx - build_data.map.width as usize] == TileType::Wall) &&
(y < build_data.map.height-2 && build_data.map.tiles[idx + build_data.map.width as usize] == TileType::Wall)
{
return true;
}
// Check for north-south door possibility
if build_data.map.tiles[idx] == TileType::Floor &&
(x > 1 && build_data.map.tiles[idx-1] == TileType::Wall) &&
(x < build_data.map.width-2 && build_data.map.tiles[idx+1] == TileType::Wall) &&
(y > 1 && build_data.map.tiles[idx - build_data.map.width as usize] == TileType::Floor) &&
(y < build_data.map.height-2 && build_data.map.tiles[idx + build_data.map.width as usize] == TileType::Floor)
{
return true;
}
false
}
// Place the doors
// build_data is so I have access to the entities and tiles, it seems like you already have this
fn doors(&mut self, rng : &mut RandomNumberGenerator, build_data : &mut BuilderMap) {
if let Some(halls_original) = &build_data.corridors {
let halls = halls_original.clone(); // To avoid nested borrowing
for hall in halls.iter() {
if hall.len() > 2 { // We aren't interested in tiny corridors
// 1 in 2 chance
if self.door_possible(build_data, hall[0]) && rng.roll_dice(1,2)==1 {
// This is equivalent to setting the tile at the beginning of a hall in your program to a Door tile, although in this game Doors are entities (So that they can be opened and closed)
build_data.spawn_list.push((hall[0], "Door".to_string()));
}
}
}
} else {
// There are no corridors - scan for possible places
// 1 in 3 chance of placing a door
let tiles = build_data.map.tiles.clone();
for (i, tile) in tiles.iter().enumerate() {
if *tile == TileType::Floor && self.door_possible(build_data, i) && rng.roll_dice(1,3)==1 {
build_data.spawn_list.push((i, "Door".to_string()));
}
}
}
}
There's too much fiddly junk in assembly that adds complexity without enlightening. If you're learning, you shouldn't have to bother knowing about accumulators and juggling data around to get everything into place for a MUL or DIV, for example.
I still think BASIC was a good learning language. Could do more than assembly and do fun stuff but the concepts carry over. 6510 was my second language.
Yep. I started with QBASIC. It had such a great built-in help system. I learned more from Microsoft docs than anything else.