Difference between revisions of "Absurd texture name in error message"

From DoomWiki.org

[checked revision][checked revision]
(some more info (hope i got it right))
m
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
When a map has a missing flat or texture, the game aborts with an error message, either [[Error message#R_FlatNumForName: %s not found|R_FlatNumForName: %s not found]] or [[Error message#R_TextureNumForName: %s not found|R_TextureNumForName: %s not found]].
+
When a map has a missing texture, the game aborts with an error message, [[Error message#R_TextureNumForName: %s not found|R_TextureNumForName: %s not found]].
  
 
In their data structures in memory, [[sidedef]]s pack the upper, middle, and lower [[texture]] names (in that order) in arrays of eight characters, without using a separator:
 
In their data structures in memory, [[sidedef]]s pack the upper, middle, and lower [[texture]] names (in that order) in arrays of eight characters, without using a separator:
Line 12: Line 12:
 
  } mapsidedef_t;
 
  } mapsidedef_t;
  
[[Sector]]s pack floor and ceiling [[flat]] names in a similar way:
+
When a texture is missing, the error string is printed using the offending texture's name to be inserted as the <tt>%s</tt> token. Since {{wp|C (programming_language)|C}} uses {{wp|null-terminated string}}s, if the texture name is full (it uses all eight characters available) then the formatting function will keep adding the next characters in memory until it finds a null byte.
typedef struct
 
{
 
    short    floorheight;
 
    short    ceilingheight;
 
    char    floorpic[8];
 
    char    ceilingpic[8];
 
    short    lightlevel;
 
    short    special;
 
    short    tag;
 
} mapsector_t;
 
  
When a texture or flat is missing, the error string is printed using the offending texture's name to be inserted as the <tt>%s</tt> token. Since {{wp|C (programming_language)|C}} uses {{wp|null-terminated string}}s, if the texture or flat name is full (it uses all eight characters available) then the formatting function will keep adding the next characters in memory until it finds a null byte.
+
For example, if a sidedef is given a non-existent upper texture with a name using all eight characters, then the name of the next texture in order (middle texture) will be appended (regardless of whether it is missing or not). If that one is also full, the lower texture name will be appended too. And if the lower texture name is full, garbage characters will be added as the sidedef's sector number is processed, followed by the offsets, texture names, and sector number of the next sidedef, and so on, until a null byte is finally encountered, preferably before a {{wp|segmentation fault}} happens.
  
For example, if a sidedef is given a non-existent upper texture with a name using all eight characters, then the name of the next texture in order (middle texture) will be appended (regardless of whether it is missing or not). If that one is also full, the lower texture name will be appended too. And if the lower texture name is full, garbage characters will be added as the sidedef's sector number is processed, followed by the offsets, texture names, and sector number of the next sidedef, and so on, until a null byte is finally encountered, preferably before a {{wp|buffer overflow}} happens.
+
The related function "R_FlatNumForName" displays a similar error if a sector has a nonexistent flat on its floor or ceiling, but copies the name of the offending flat into a temporary buffer to ensure it is printed correctly. The oversight in R_TextureNumForName exists in all versions of the game, including the [[Doom source code|source code]] release, but is fixed in virtually all source ports.
  
 
[[Category:Errors and bugs]]
 
[[Category:Errors and bugs]]

Latest revision as of 23:02, 19 May 2018

When a map has a missing texture, the game aborts with an error message, R_TextureNumForName: %s not found.

In their data structures in memory, sidedefs pack the upper, middle, and lower texture names (in that order) in arrays of eight characters, without using a separator:

typedef struct
{
    short    textureoffset;
    short    rowoffset;
    char     toptexture[8];
    char     bottomtexture[8];
    char     midtexture[8];
    short    sector;
} mapsidedef_t;

When a texture is missing, the error string is printed using the offending texture's name to be inserted as the %s token. Since C uses null-terminated strings, if the texture name is full (it uses all eight characters available) then the formatting function will keep adding the next characters in memory until it finds a null byte.

For example, if a sidedef is given a non-existent upper texture with a name using all eight characters, then the name of the next texture in order (middle texture) will be appended (regardless of whether it is missing or not). If that one is also full, the lower texture name will be appended too. And if the lower texture name is full, garbage characters will be added as the sidedef's sector number is processed, followed by the offsets, texture names, and sector number of the next sidedef, and so on, until a null byte is finally encountered, preferably before a segmentation fault happens.

The related function "R_FlatNumForName" displays a similar error if a sector has a nonexistent flat on its floor or ceiling, but copies the name of the offending flat into a temporary buffer to ensure it is printed correctly. The oversight in R_TextureNumForName exists in all versions of the game, including the source code release, but is fixed in virtually all source ports.