In the MapRenderer we are using "maprows" being defined as 
> typedef unsigned short maprow[256];
So a layer consists of an array of maprows. This allows addressing via row index and within the row as column index like 
> maplayer[x][y]
But knowing the y are always 256 ( a power of 2) the access can be made very fast by the compiler using bit masking
So the access internally by the compiler is something like
> maplayer [ x<<8 + y & 0xff] 
which may be faster than the multiplication with a yet to look up map_width.

Of course this wastes some memory if the map is not as wide as 256 tiles.
So in the worst case having a huge map in height but small in width we could waste:
> 256 rows * 250 columns wasted * sizeof(integer) == 250 kiloBytes

250kB are not very much, we are more concerned about cpu cycles than memory in the big picture (at least up to now we were).
Also to have an impression whether this is reasonable, have a look at this image.
![memory_consumption_peak1](https://f.cloud.github.com/assets/455868/620803/4763e32a-ceee-11e2-83c6-5c59269812f3.png)
This image was generated via massif, a tool to visualize memory impact of running programs. It's part of the valgrind suite to check for all kinds of memory related stuff (memory leaks, access patterns, usage).
You'll notice that 160 out of 170 MegaBytes are images (pixel bitmaps), then there are some MegaBytes for sound and only a fraction of memory for the actual data holding the game state, such as stats, entities, maplayers and such.
However that image is quite dated (half a year), so I'll try to get a recent image. But I do not expect large changes there.

Also you could use short or unsigned char data types, which would cut the 250kB by half or even reducing ti to a quarter (64kB).