2009-04-13 43 views

Respuesta

11

Esto depende completamente de la implementación.

Esto depende tanto del hardware como de cualquier cosa, pero también de la antigüedad del compilador. Para cualquier persona con un compilador razonablemente moderno (es decir, cualquier cosa basada en un estándar de principios de los 90 o posterior), el argumento de tamaño es size_t. Esto puede ser razonablemente el mayor sin firmar de 16 bits, el más grande de 32 bits sin firmar, o el más grande sin firma de 64 bits, dependiendo del modelo de memoria compilado por el compilador. En este caso, solo tiene que averiguar qué tamaño tiene size_t en su implementación. Sin embargo, para muy compiladores antiguos (es decir, antes de ANSI-C y perhaps for some early versions of ANSI C), todas las apuestas están desactivadas.

Por el lado de las normas, mirando a cygwin y Solaris 7, por ejemplo, el argumento de tamaño es size_t. Al mirar un sistema integrado que tengo disponible, el argumento de tamaño es unsigned (lo que significa que no tiene 16 bits). (El compilador de este sistema integrado se escribió en los años 80.) Encontré una referencia web a algunos ANSI C where the size parameter is an int.

es posible que desee ver en this articlesize_t así como la follow-up article sobre un mal aspecto de algunas versiones anteriores del CCG donde se firmó erróneamente size_t.

En resumen, para casi todo el mundo, size_t será la referencia correcta para su uso. Para aquellos que usan sistemas embebidos o sistemas heredados con compiladores muy antiguos, sin embargo, debe verificar su página de manual.

+0

Quien haya votado negativamente esto no debe haber estado programando C el tiempo suficiente para estar cerca cuando esto no estaba tan estandarizado. – Eddie

+0

¿Los compiladores anteriores a C89 todavía son comunes? Creo que es bastante seguro depender de size_t, exceptuando el trabajo en sistemas heredados. –

+0

Bajé la votación porque parecías decir que esta cosa size_t no está bien estandarizada, lo que por supuesto es falso. –

0

Toman un argumento size_t; por lo que depende de la plataforma.

0

Depende de la implementación, pero puede buscar en el archivo de encabezado (.h) que necesita incluir antes de poder usar memcpy. La declaración le dirá (busque size_t u otro).

Y luego preguntas qué size_t es, bueno, esa es la parte dependiente de la implementación.

1

Las funciones normalmente usan un size_t para pasar un tamaño como parámetro. Digo normalmente porque fgets() usa un parámetro int, que en mi opinión es un defecto en el estándar C.

size_t se define como un tipo que puede contener el tamaño (en bytes) de cualquier objeto al que pueda acceder. En general, es un typedef de unsigned int o unsigned long.
Es por eso que los valores retornados por el operador sizeof son del tipo size_t.

Así que 2 ** (sizeof(size_t) * CHAR_BIT) le proporciona la cantidad máxima de memoria que su programa podría manejar, pero ciertamente no es la más precisa.
(CHAR_BIT se define en limits.h y proporciona el número de bits contenidos en un char).

+0

¿No está definido CHAR_BIT como 8? ¿O solo se define char para ser de 1 byte? –

+0

char = 1 byte, el número de bits puede cambiar – aib

+0

Para citar el estándar, CHAR_BIT es el "número de bits para el objeto más pequeño que no es un campo de bits (byte)", y debe ser al menos 8. Un interesante enlace: http://c-faq.com/charstring/wchar.html. –

0

Derecho, no puede copiar áreas que son mayores que 2^(sizeof (size_t) * 8) bytes.Pero eso no es nada de lo que preocuparse, porque tampoco puede asignar más espacio, porque malloc también toma el tamaño como un parámetro size_t.

+0

Creo que quieres decir "2^(sizeof (size_t) * 8)". –

+0

Bueno, puede llamar a malloc() varias veces :) – aib

+0

@aib, claro, pero no se le garantizarán buffers contiguos. –

0

También hay un problema relacionado con lo que size_t puede representar en relación a lo que su plataforma permitirá que un proceso aborde realmente.

Incluso con la memoria virtual en una plataforma de 64 bits, es poco probable que pueda llamar al memcpy() con tamaños de más de unos pocos TB más o menos esta semana, y aun así esa es una máquina bastante caliente .... es difícil imaginar cómo se vería una máquina sobre la que sería posible instalar un espacio de direcciones de 64 bits totalmente cubierto.

No importa los sistemas integrados con solo unos pocos KB de memoria total grabable, donde no tiene sentido intentar memcpy() más información que la RAM independientemente de la definición de size_t. ¿Piensas en lo que acaba de pasar con la pila que contiene la dirección de devolución de esa llamada si lo hiciste?

O sistemas donde el espacio de direcciones virtual visto por un proceso es más pequeño que la memoria física instalada. Este es realmente el caso con un proceso Win32 que se ejecuta en una plataforma Win64, por ejemplo. (La primera vez que me encontré con esto fue compartir el tiempo compartido OS TSX-11 ejecutando en un PDP-11 con 4MB de memoria física y 64KB de dirección virtual en cada proceso. 4MB de RAM era mucha memoria entonces, y el PC de IBM no existe aún.)

Cuestiones relacionadas