Changeset 3b93a2de in rtems
- Timestamp:
- 09/23/98 16:34:23 (24 years ago)
- Branches:
- 4.10, 4.11, 4.8, 4.9, 5, master
- Children:
- ecc3fe3
- Parents:
- 87c857a9
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
c/src/exec/libcsupport/src/malloc.c
r87c857a9 r3b93a2de 37 37 size_t RTEMS_Malloc_Sbrk_amount; 38 38 39 extern rtems_cpu_table Cpu_table; 39 40 #ifdef RTEMS_DEBUG 40 41 #define MALLOC_STATS … … 101 102 starting_address = (void *)u32_address; 102 103 } 104 105 /* 106 * If the BSP is not clearing out the workspace, then it is most likely 107 * not clearing out the initial memory for the heap. There is no 108 * standard supporting zeroing out the heap memory. But much code 109 * with UNIX history seems to assume that memory malloc'ed during 110 * initialization (before any free's) is zero'ed. This is true most 111 * of the time under UNIX because zero'ing memory when it is first 112 * given to a process eliminates the chance of a process seeing data 113 * left over from another process. This would be a security violation. 114 */ 115 116 if ( Cpu_table.do_zero_of_workspace ) 117 memset( starting_address, 0, length ); 103 118 104 119 /* -
c/src/lib/libc/malloc.c
r87c857a9 r3b93a2de 37 37 size_t RTEMS_Malloc_Sbrk_amount; 38 38 39 extern rtems_cpu_table Cpu_table; 39 40 #ifdef RTEMS_DEBUG 40 41 #define MALLOC_STATS … … 101 102 starting_address = (void *)u32_address; 102 103 } 104 105 /* 106 * If the BSP is not clearing out the workspace, then it is most likely 107 * not clearing out the initial memory for the heap. There is no 108 * standard supporting zeroing out the heap memory. But much code 109 * with UNIX history seems to assume that memory malloc'ed during 110 * initialization (before any free's) is zero'ed. This is true most 111 * of the time under UNIX because zero'ing memory when it is first 112 * given to a process eliminates the chance of a process seeing data 113 * left over from another process. This would be a security violation. 114 */ 115 116 if ( Cpu_table.do_zero_of_workspace ) 117 memset( starting_address, 0, length ); 103 118 104 119 /* -
cpukit/libcsupport/src/malloc.c
r87c857a9 r3b93a2de 37 37 size_t RTEMS_Malloc_Sbrk_amount; 38 38 39 extern rtems_cpu_table Cpu_table; 39 40 #ifdef RTEMS_DEBUG 40 41 #define MALLOC_STATS … … 101 102 starting_address = (void *)u32_address; 102 103 } 104 105 /* 106 * If the BSP is not clearing out the workspace, then it is most likely 107 * not clearing out the initial memory for the heap. There is no 108 * standard supporting zeroing out the heap memory. But much code 109 * with UNIX history seems to assume that memory malloc'ed during 110 * initialization (before any free's) is zero'ed. This is true most 111 * of the time under UNIX because zero'ing memory when it is first 112 * given to a process eliminates the chance of a process seeing data 113 * left over from another process. This would be a security violation. 114 */ 115 116 if ( Cpu_table.do_zero_of_workspace ) 117 memset( starting_address, 0, length ); 103 118 104 119 /*
Note: See TracChangeset
for help on using the changeset viewer.